集群容错机制的原理
假如我们使用的单机模式的dubbo服务,消费者发出一次请求,恰好这次由于网络问题调用失败,我们可以配置重试策略,可能第二次调用时成功的。但是假如假如提供者发生故障,那么消费者再怎么重试调用都是失败的,所以我们采取集群容错模式,这样假如单个服务节点故障无法提供服务,则可以根据配置的集群容错模式,调用其他的服务节点。这样就提高了服务的可用性。
集群容错模式的配置方式
提供者配置
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie" cluster="failover"/>
消费者配置
<dubbo:reference id="testService" interface="com.yang.test.api.TestService" cluster="failover" />
6种集群容错模式
1、Failover
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie" cluster="failover" retries="2"/>
是dubbo默认的模式,在调用失败时,会自动切换尝试调用其他节点的服务,一些幂等操作可以使用该模式,例如读操作,因为每次调用的副作用是一样的,所以可以选择自动切换重新调用。可以通过retries属性设置重试次数(不包含第一次)
2、Failfase
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie" cluster="failfast"/>
又叫快速失败模式,调用只执行一次,若失败则立即报错,这种操作适用于非幂等操作,比如数据库的写操作,如果失败了就应该直接失败,不需要重试。
3、Failsafe
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie" cluster="failsafe"/>
又叫失败安全模式,如果调用失败,则直接忽略失败的调用,记录失败的调用到日志中,以便后续审计。
4、Failback
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie" cluster="failback"/>
失败后自动恢复,后台记录失败的请求,定时重发 通常用于消息通知的操作。
5、Forking
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie" cluster="forking/>
并行调用多个服务器,只要一个成功便返回,通常用于实时性要求高的操作,但需要浪费更多的服务资源,可以通过forks属性设置最大的并行数。例如(forks="2")
6、Broadcast
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie" cluster="broadcast" />
广播调用所有提供者,逐个调用,任意一台报错则报错,通常用于通知所有提供者更新缓存或日志等本地资源信息。
集群的负载均衡
Dubbo内置了4种负载均衡策略,随机(Random),轮循(RoundRobin),最少活跃数(LeastActive),一致性Hash(ConisitentHash)。
集群的负载均衡可以接口级别进行配置
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie" loadbalance="foundRobin" />
可以在方法级别上配置
<dubbo:service interface="com.yang.test.api.TestService" ref="testServcie">
<dubbo:method name="sayHello" loadbalance="roundrobin"/>
</dubbo:service>
四种负载均衡策略
随机模式:随机,指按照权重设计随机概率
轮询模式:即按照公约后的权重设置轮询比率,该模式存在响应慢的提供者会累积请求,比如两台服务器,第二台很慢,但是没挂掉。那请求就会卡在那里,久而久之,左右的请求就会卡在第二台上面。
最少活跃数调用:只相应慢 提供者收到更少 请求的一种调用方式,如果活跃数相同的则随机,活跃数指调动前后的计数差,而相应越慢的提供者调用前后的计数差越大。
一致性Hash:指带有相同参数的请求总会被发送到同一个提供者。在某台提供者挂掉时候,原本发往这台服务器的请求会平摊到其他的提供者上面。