1 introduction of Dubbo

Dubbo is a high-performance, lightweight, open source Java RPC framework that provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery.

As a lightweight RPC framework, Dubbo’s design architecture is simple and clear, and its main components include Provider (service Provider),Consumer (service Consumer) and Registry (Registry). There is also Monitor for service monitoring, and the relationship between them is shown below:

In a distributed system, load clusters need to be formed to ensure high availability of the system. If a node in the cluster does not return data in time, a cluster fault tolerance (retry) mechanism is required.

2 Dubbo load balancing

Dubbo provides the following five balancing policies for cluster load balancing. The default policy is random random call.

Random

Random calls

Random LoadBalance

Random, set random probability according to weight.

The probability of collision on a section is high, but the distribution is more uniform with the increase of adjustment dosage, and the distribution is more uniform after using weight according to the probability, which is conducive to dynamic adjustment of provider weight.

RoundRobin LoadBalance

Round-robin, the round-robin ratio is set according to the weight after the convention.

There is the problem of slow providers accumulating requests, for example: the second machine is slow but not hung up, gets stuck when the request is switched to the second machine, and over time all the requests get stuck to the second machine.

LeastActive LoadBalance

Minimum number of active calls, random number of the same active number, active number refers to the difference in count before and after the call.

Make slower providers receive fewer requests, because slower providers have a larger difference in the count before and after the invocation.

ConsistentHash LoadBalance

Consistent Hash, where requests with the same parameters are always sent to the same provider.

When a provider hangs, requests originally sent to that provider are spread over other providers based on virtual nodes without drastic changes.

3 Load balancing configuration

Service level of the server

interface=”…” loadbalance=”roundrobin” />;

Client service level

interface=”…” loadbalance=”roundrobin” />

Server method level

=”…”>

<dubbo:methodname=”…” loadbalance=”roundrobin”/>

dubbo:service>

Client method level

=”…”>

<dubbo:methodname=”…” loadbalance=”roundrobin”/>

dubbo:reference>

4 Dubbo Cluster fault tolerance (retry mechanism)

When a cluster invocation fails, Dubbo provides multiple fault tolerance schemes. By default, Failover retry is used.

Relationship of nodes:

Here, Invoker is a callable Service abstraction of Provider. The Invoker encapsulates the Provider address and Service interface information

Directory represents multiple invokers and can be thought of as a List, but unlike a List, its value can change dynamically, such as when the registry pushes changes

Cluster masquerade multiple Invokers in a Directory as one Invoker and is transparent to the upper layer. The masquerade process contains fault-tolerant logic, and when the call fails, another Invoker is retried

The Router is responsible for selecting subsets of invokers based on routing rules, such as read/write separation, application isolation, and so on

LoadBalance selects a specific Invoker from multiple invokers for this invocation. The selection process includes the load balancing algorithm. If the invocation fails, the Invoker must be selected again

5 Retry mode and its features

Failover Cluster(default)

Failure to switch automatically, when failure occurs, retry other servers [1]. Typically used for read operations, but retries introduce longer delays. Retries =”2″ can be used to set the number of retries (excluding the first).

The retry times are as follows:

<dubbo:serviceretries=”2″ />

or

<dubbo:referenceretries=”2″ />

or

<dubbo:reference>

<dubbo:methodname=”findFoo” retries=”2″ />

dubbo:reference>

Failfast Cluster

Fast failure, only one call, failure immediately error. Typically used for non-idempotent writes, such as new records.

Failsafe Cluster

Fail-safe, ignore exceptions when they occur. It is used to write audit logs.

Failback Cluster

The system automatically recovers the failure, records the failure request in the background, and periodically resends the failure request. Typically used for message notification operations.

Forking Cluster

Call multiple servers in parallel and return if one succeeds. It is usually used for read operations that require high real-time performance but waste more service resources. The maximum parallel number can be set by forks=”2″.

Broadcast Cluster

Broadcast calls all providers, one by one, and an error is reported on any one [2]. Typically used to notify all providers to update local resource information such as caches or logs.

6 Configure the cluster mode

Follow the following example to configure the cluster pattern on the service provider and consumer side

<dubbo:servicecluster=”failsafe” />

or

<dubbo:referencecluster=”failsafe” />