4. Fault Tolerance and load balancing for Dubbo2.5.3 clusters and fault tolerance for dubbo Clusters

4. Fault Tolerance and load balancing for Dubbo2.5.3 clusters and fault tolerance for dubbo Clusters

Reprint please from the source: http://www.cnblogs.com/hd3013779515/

1. Cluster fault tolerance and Load Balancing principles

Node relationship:

• Invoker is an abstraction of the callable Service of Provider. Invoker encapsulates the Provider address and Service interface information.
• Directory represents multiple Invoker and can be viewed as List <Invoker>. However, unlike List, its value may change dynamically, for example, the Registration Center pushes changes.
• The Cluster disguise multiple Invoker in Directory as one Invoker, which is transparent to the upper layer. The disguised process contains the fault-tolerant logic. After the call fails, retry the other one.
• The Router selects a subset from multiple Invoker Based on routing rules, such as read/write splitting and application isolation.
• LoadBalance is responsible for selecting a specific Invoker from multiple Invoker for this call. The selection process includes the load balancing algorithm. After the call fails, you need to reselect it.

2. Server Load balancer

(1) configuration instructions

Dubbo provides multiple balancing policies for Cluster load balancing. By default, Dubbo performs random calls.

Random LoadBalance

• Random: Set the random probability by weight.
• The probability of collision on a cross section is high, but the larger the call volume, the more even the distribution, and the more even the weight is based on the probability, which is conducive to dynamic adjustment of the provider weight.

RoundRobin LoadBalance

• Round robin: set the round robin rate based on the weight after the convention.
• Slow requests are accumulated by the provider. For example, if the second server is slow but the server is not suspended, the request is stuck there when it is transferred to the second server. Over time, all requests are routed to the second server.

LeastActive LoadBalance

• The minimum number of active calls, the same number of active calls is random, and the number of active calls indicates the Count difference before and after the call.
• This causes the provider to receive fewer requests, because the difference in the count before and after the provider's calls will increase.

ConsistentHash LoadBalance

• Consistent Hash. requests with the same parameters are always sent to the same provider.
• When a provider fails, requests originally sent to the provider are distributed to other providers based on virtual nodes without causing drastic changes.
• For the algorithm, see http://en.wikipedia.org/wiki/consistent_hashing.
• By default, only the first parameter is Hash. If you want to modify it, configure <dubbo: parameter key = "hash. arguments" value = ""/>
• By default, 160 virtual nodes are used. If you want to modify them, configure <dubbo: parameter key = "hash. nodes" value = "320"/>

Configuration example:

<dubbo:service interface="..." loadbalance="roundrobin" />

Or:

<dubbo:reference interface="..." loadbalance="roundrobin" />

Or:

<dubbo:service interface="...">     <dubbo:method name="..." loadbalance="roundrobin"/></dubbo:service>

Or:

<dubbo:reference interface="...">      <dubbo:method name="..." loadbalance="roundrobin"/></dubbo:reference>

 

(2) Use Cases

Add a service provider on the basis of 3. Dubbo2.5.3 Quick Start of Hello World. The differences with dubbo-hello-provider are as follows.

The service consumer HelloServiceConsumerTest. java is added to call the service provider cyclically.

Package cn. lstrap. dubbo. service; import java. io. IOException; import org. springframework. context. support. classPathXmlApplicationContext; public class HelloServiceConsumerTest {public static void main (String [] args) {ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext (new String [] {"applicationConsumer. xml "}); context. start (); for (int I = 0; I <100; I ++) {HelloService providerService = (HelloService) context. getBean ("helloService"); System. out. println (providerService. sayHello ("Tom");} try {System. in. read (); // keep this program running} catch (IOException e) {e. printStackTrace ();}}}

1) When Random LoadBalance is used by default

At the beginning, the weights of the two providers of HelloService are both 100, and the distribution ratio after the service consumer executes is 54: 46.

Then, the weight of the provider 20880 is added to 400 through the monitoring center. Then, the distribution ratio of the service consumer after execution is 83: 17.

2) when it is set to RoundRobin LoadBalance

When the weights of the two providers of HelloService are both 100, the round robin method is strictly installed.

When you add the provider's weight of 20880 to 400, the weights are used for Round Robin.

3. Cluster Fault Tolerance

(1) configuration instructions

Cluster Fault Tolerance mode: Failover Cluster

• If the switch fails, retry other servers. (Default)
• It is usually used for read operations, but retry may lead to a longer delay.
• You can use retries = "2" to set the number of retries (excluding the first retries ).

Failfast Cluster

• Quick failure: Only one call is initiated. If the call fails, an error is reported immediately.
• It is usually used for non-idempotent write operations, such as adding new records.

Failsafe Cluster

• Failure security. If an exception occurs, ignore it directly.
• It is usually used for writing audit logs.

Failback Cluster

• Automatic Recovery upon failure, failure request recorded in the background, and timed resend.
• It is usually used for Message notification operations.

Forking Cluster

• If multiple servers are called in parallel, a success is returned.
• It is usually used for read operations with high real-time requirements, but more service resources need to be wasted.
• You can use forks = "2" to set the maximum number of parallel rows.

Broadcast Cluster

• Broadcast calls are called by all providers one by one. If any provider reports an error, an error is returned. (Supported starting from 2.1.0)
• It is usually used to notify all providers to update local resource information such as cache or log.

The number of retries is configured as follows: (failover cluster mode takes effect)

<dubbo:service retries="2" />

Or:

<dubbo:reference retries="2" />

Or:

<dubbo:reference>    <dubbo:method name="findFoo" retries="2" /></dubbo:reference>

The cluster mode configuration is as follows:

<dubbo:service cluster="failsafe" />

Or:

<dubbo:reference cluster="failsafe" />

(2) Use Cases

Code Transformation

Two service providers are simultaneously transformed

HelloServiceImpl. java

Increase the sleep time to stop the service provider when the service consumer calls it.

ApplicationProvider. xml

1) when the default Failover Cluster is used

During the execution of a service consumer, a service provider is disabled through the monitoring center. The execution result shows that the service provider can be correctly switched to the available service provider and no error or call is reported or lost.

2) when it is set to Failfast Cluster

When a service consumer calls a service provider, if the provider is stopped, an error will be reported immediately and the execution will not continue.

3) when it is set to Failsafe Cluster

When a service consumer calls a service provider, if the provider is stopped, ignore it and continue.

Reference

Http://dubbo.io/User+Guide-zh.htm