dubbo工做原理,集群容错,负载均衡

dubbo主要核心部件

Remoting:网络通讯框架,实现了sync-over-async和request-response消息机制。算法

RPC:一个远程过程调用的抽象,支持负载均衡、容灾和集群功能。缓存

Registry:服务目录框架用于服务的注册和服务事件发布和订阅。(相似第一篇文章中的点菜宝)tomcat

dubbo架构安全

Provider: 暴露服务的提供方。服务器

Consumer:调用远程服务的服务消费方。网络

Registry: 服务注册中心和发现中心。架构

Monitor: 统计服务和调用次数,调用时间监控中心。(dubbo的控制台页面中能够显示)负载均衡

Container:服务运行的容器。框架

 调用关系:dom

       0、服务器负责启动,加载,运行提供者(例如在tomcat容器中,启动dubbo服务端)。

        一、提供者在启动时,向注册中心注册本身提供的服务。

        二、消费者启动时,向注册中心订阅本身所需的服务。

        三、注册中心返回提供者地址列表给消费者,若是有变动,注册中心将基于长链接推送变动数据给消费者。

        四、消费者,从远程接口列表中,调用远程接口,dubbo会基于负载均衡算法,选一台提供者进行调用,若是调用失败则选择另外一台。

        五、消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。(能够在dubbo的可视化界面看到)

 

dubbo的容错方案

当咱们的系统中用到Dubbo的集群环境,由于各类缘由在集群调用失败时,Dubbo提供了多种容错方案,缺省为failover重试。

       Dubbo的集群容错在这里想说说他是由于咱们实际的项目中出现了此类的问题,由于依赖的第三方项目出现异常,致使dubbo调用超时,此时使用的是默认的集群容错方式,而配置的reties='3',这样前段系统连续掉用了三次服务,结果可想而知.

     先说一下各节点关系:

       这里的Invoker是Provider的一个可调用Service的抽象,Invoker封装了Provider地址及Service接口信息。

        Directory表明多个Invoker,能够把它当作List<Invoker>,但与List不一样的是,它的值多是动态变化的,好比注册中心推送变动。

         Cluster将Directory中的多个Invoker假装成一个Invoker,对上层透明,假装过程包含了容错逻辑,调用失败后,重试另外一个。

         Router负责从多个Invoker中按路由规则选出子集,好比读写分离,应用隔离等。

         LoadBalance负责从多个Invoker中选出具体的一个用于本次调用,选的过程包含了负载均衡算法,调用失败后,须要重选。

  集群容错模式:

  Failover Cluster

失败自动切换,当出现失败,重试其它服务器。(缺省)

一般用于读操做,但重试会带来更长延迟。

可经过retries="2"来设置重试次数(不含第一次)。正是文章刚开始说的那种状况.

  Failfast Cluster

快速失败,只发起一次调用,失败当即报错。

一般用于非幂等性的写操做,好比新增记录。

  Failsafe Cluster

失败安全,出现异常时,直接忽略。

一般用于写入审计日志等操做。

  Failback Cluster

失败自动恢复,后台记录失败请求,定时重发。

一般用于消息通知操做。

  Forking Cluster

并行调用多个服务器,只要一个成功即返回。

一般用于实时性要求较高的读操做,但须要浪费更多服务资源。

可经过forks="2"来设置最大并行数。

  Broadcast Cluster

广播调用全部提供者,逐个调用,任意一台报错则报错。(2.1.0开始支持)

一般用于通知全部提供者更新缓存或日志等本地资源信息。

重试次数配置如:(failover集群模式生效)

<dubbo:serviceretries="2"/>

或:<dubbo:referenceretries="2"/>

或:<dubbo:reference>

             <dubbo:methodname="findFoo"retries="2"/>

     </dubbo:reference>

集群模式配置如:

<dubbo:servicecluster="failsafe"/>

或:<dubbo:referencecluster="failsafe"/>

dubbo负载均衡策略:

        在集群负载均衡时,Dubbo提供了多种均衡策略,缺省为random随机调用。

    RandomLoadBalance

随机,按权重设置随机几率。

在一个截面上碰撞的几率高,但调用量越大分布越均匀,并且按几率使用权重后也比较均匀,有利于动态调整提供者权重。

    RoundRobin LoadBalance

轮循,按公约后的权重设置轮循比率。

存在慢的提供者累积请求问题,好比:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,长此以往,全部请求都卡在调到第二台上。

    LeastActive LoadBalance

最少活跃调用数,相同活跃数的随机,活跃数指调用先后计数差。

使慢的提供者收到更少请求,由于越慢的提供者的调用先后计数差会越大。

   ConsistentHashLoadBalance

一致性Hash,相同参数的请求老是发到同一提供者。

当某一台提供者挂时,本来发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引发剧烈变更。

 

       Dubbo的集群容错和负载均衡一样也是Dubbo自己的高级特性.正如咱们在说自定义扩展的时候同样,这两个特征一样也能够进行自定义扩展,用户能够根据本身实际的需求来扩展他们从而知足项目的实际需求.

参考出处: http://blog.csdn.net/lovesummerforever/article/details/48180957

http://blog.csdn.net/jnqqls/article/details/46702103

相关文章
相关标签/搜索