Dubbo is Alibaba open source distributed service framework, we can very easily to build distributed service through Dubbo, and according to their actual business scenarios to select the appropriate cluster fault-tolerant mode, the applications are eager for many, it is necessary only a simple configuration can be achieved distributed service calls, meaning that the service provider (Provider) services can be published is a natural cluster services, for example, at very high real-time requirements scenarios, it may be desirable from a consumer (consumer ) calls the shortest response time, selecting only the Forking Cluster Dubbo mode configuration, can be sent in parallel on multiple nodes peer provider (Provider) services where a call to request a return only select the fastest response and then calls the results are returned to service consumer (consumer), apparently in this way is a redundant service-based, need to consume more resources, but to meet the high demand for real-time applications.
A, Dubbo fault-tolerant cluster service
Suppose we are using the stand-alone mode Dubbo services, distribution services in the future if the service provider (Provider), the service consumer (Consumer) issued a call request, just the call fails due to network problems, then we can configure the service consumer retry strategy, a consumer may call the second retry is successful (retry strategy should be configured retry process is transparent); however, if the service provider node publishing service resides fails, then the consumer Fang then how are retried failure, so we need to adopt a cluster fault-tolerant mode, so that if a single service node due to failure can not provide services, but also according to the fault-tolerant cluster configuration mode, call the other available service node, which improves the availability of services.
Simply put Dubbo currently supported cluster fault tolerance modes, each adapted to specific application scenarios can be selected according to actual needs . Dubbo following six kinds of built-in support cluster mode:
1, Failover Cluster mode
Configuration is failover. This model is a fault-tolerant cluster Dubbo default mode is selected , the call fails, it will automatically switch back to try other nodes available on call service .
For some idempotent operations may use the pattern, such as a read operation , because each call side is the same, it can be selected automatically switched call and try again, completely transparent to the caller.
You can see, if the response is bound to bring retried end of the delay, if a large number of retried occurs, it may explain our service providers publish services in question, such as network delay serious, hardware needs to be upgraded, the program algorithm is very time-consuming , and so on, which requires careful testing of the investigation.
For example, it can be explicitly specified Failover mode, the default configuration is not turned on or Failover mode, a configuration example as follows:
<dubbo:service interface="org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService"
version="1.0.0" cluster="failover" retries="2" timeout="100"
ref="chatRoomOnlineUserCounterService" protocol="dubbo" >
<dubbo:method name="queryRoomUserCount" timeout="80" retries="2" />
</dubbo:service>
Failover Cluster mode using the above configuration, if the call fails once again be retried two times to call, service level call timeout to 100ms, call the method queryRoomUserCount timeout is 80ms, allow two times, the worst-case call spend time 160ms . If the service interface org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService there are other methods available to call, other methods are not explicitly configured will inherit use dubbo: property values service configuration.
2, Failfast Cluster mode
Configuration is failfast. This mode is called fail-fast mode, the call only once, immediately fails error .
This model is suitable for non-idempotent operation , side effects of each call is different, such as a write operation,
For example, the trading system we want to place an order, if a failure should it fail, usually controlled by a service consumer whether to re-initiate an order request under operation (another new orders).
3, Failsafe Cluster mode
Configuration is failsafe. Fail safe mode, if the call fails, simply ignore the call fails,
But fail to record the calls to the log files for subsequent audit .
4, Failback Cluster mode
Configuration is failback. Automatic recovery fails, background records failed request, the retransmission timer.
Typically a message notifying operation.
5, Forking Cluster mode
Configuration is forking. Call multiple servers in parallel, that is as long as a successful return .
Typically used for higher real-time requirements of a read operation, but more services need to waste resources.
6, Broadcast Cluster mode
Configuration is broadcast.
Calling all broadcast providers, one by one call, Renyiyitai error is an error (2.1.0 support).
Typically used to notify all providers such as cache or log updates the local resource information.
Above 6 modes can be used in the production environment, we can choose the appropriate mode according to the actual fault-tolerant cluster scenarios.
If we feel that several fault-tolerant cluster mode provides built-in Dubbo can not meet the application needs,
Can also be customized to achieve their cluster fault-tolerant mode, because the extended interface to Dubbo framework provided me, you only need to implement the interface com.alibaba.dubbo.rpc.cluster.Cluster.
Two, Dubbo load balancing service
Dubbo framework provides built-in load balancing capabilities, and expansion interface , we can transparently extend a service or service cluster, easily add / remove nodes as necessary, to improve the scalability of services .
Dubbo built framework provides four load balancing policy, as follows:
1, Random LoadBalance: random policy, configuration is Random . You can set the weight, help make full use of server resources, you can set right a number of major high with the low with may be slightly smaller
2, RoundRobin LoadBalance: polling policy, is arranged roundrobin.
3, LeastActive LoadBalance: configuration is leastactive. The count of the number of requests to call, slower processing request node requests will be less
4, ConsistentHash LoadBalance: Hash policy consistency, the specific configuration can refer to Dubbo documents. The same call parameters of the request will be sent to the same service provider nodes, if a node fails not to provide services, will be mapped consistency Hash algorithm based on virtual node (other service providers)
In actual use, only need to select the appropriate load balancing strategy values, can be arranged, the following is an example of the above-described four kinds of load balancing policy configuration:
<dubbo:service interface="org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService" version="1.0.0"
cluster="failover" retries="2" timeout="100" loadbalance="random"
ref="chatRoomOnlineUserCounterService" protocol="dubbo" >
<dubbo:method name="queryRoomUserCount" timeout="80" retries="2" loadbalance="leastactive" />
</dubbo:service>
The above configuration, also reflects the inherited characteristics of Dubbo configuration, which is dubbo: service element configured loadbalance = "random", the child elements of dubbo: method If no load balancing strategy, the default is loadbalance = "random "otherwise, if dubbo: method specified loadbalance =" leastactive ", using load balancing policy configuration covering a sub-element parent element specified policy (call here queryRoomUserCount method leastactive load balancing policy).