When Dubbo 's cluster environment is used in our system , when the cluster call fails due to various reasons, Dubbo provides a variety of fault tolerance schemes, the default is failover retry.
Dubbo 's cluster fault tolerance is here because of such problems in our actual project , because the dependent third-party project is abnormal , causing dubbo to call timeout . At this time, the default cluster fault tolerance method is used , and The configured reties='3', so that the front-end system has used three services in a row , and the result can be imagined .
Let's talk about the relationship between each node:
The Invoker here is an abstraction of a callable Service of the Provider, and the Invoker encapsulates the Provider address and Service interface information.
Directory represents multiple Invokers, which can be regarded as List<Invoker>, but unlike List, its value may change dynamically, such as registry push changes.
Cluster disguises multiple Invokers in the Directory as one Invoker, which is transparent to the upper layer. The disguise process includes fault-tolerant logic. After the call fails, another Invoker is retried.
Router is responsible for selecting subsets from multiple Invokers according to routing rules, such as read-write separation, application isolation, etc.
LoadBalance is responsible for selecting a specific one from multiple Invokers for this call. The selection process includes the load balancing algorithm. After the call fails, it needs to be reselected.
Cluster fault tolerance mode:
Failover Cluster
Automatically switch on failure, when a failure occurs, retry other servers. (default)
Typically used for read operations, but retries incur longer delays.
The number of retries (excluding the first time) can be set by retries="2". Exactly what the article said at the beginning .
Failfast Cluster
Fast failure, only one call is made, and an error is reported immediately upon failure.
Usually used for non-idempotent write operations, such as adding new records.
Failsafe Cluster
Fail safe, when an exception occurs, ignore it directly.
Typically used for operations such as writing to the audit log.
Failback Cluster
The failure is automatically recovered, and the failed request is recorded in the background and retransmitted regularly.
Typically used for message notification operations.
Forking Cluster
Call multiple servers in parallel and return as long as one succeeds.
It is usually used for read operations with high real-time requirements, but it needs to waste more service resources.
The maximum number of parallels can be set by forks="2".
Broadcast Cluster
Broadcast to call all providers, call them one by one, and report an error if any one reports an error. (2.1.0 started to support)
Typically used to notify all providers to update local resource information such as caches or logs.
The number of retries is configured as: (failover cluster mode takes effect)
<dubbo:serviceretries="2"/>
or:
<dubbo:referenceretries="2"/>
or:
<dubbo:reference>
<dubbo:methodname="findFoo"retries="2"/>
</dubbo:reference>
Cluster mode configuration such as:
<dubbo:servicecluster="failsafe"/>
or:
<dubbo:referencecluster="failsafe"/>
以上是Dubbo集群的容错方式,接下来是在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。
Random LoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
Dubbo的集群容错和负载均衡同样也是Dubbo本身的高级特性.正如我们在说自定义扩展的时候一样,这两个特征同样也可以进行自定义扩展,用户可以根据自己实际的需求来扩展他们从而满足项目的实际需求.
http://blog.csdn.net/jnqqls/article/details/46702103