负载均衡策略
random loadbalance
随机负载均衡,默认情况下,dubbo 是 random load balance ,即随机调用实现负载均衡,可以对 provider 不同实例设置不同的权重,会按照权重来负载均衡,权重越大分配流量越高,一般就用这个默认的就可以了。
roundrobin loadbalance
轮询负载均衡,这个的话默认就是均匀地将流量打到各个机器上去,但是如果各个机器的性能不一样,容易导致性能差的机器负载过高。所以此时需要调整权重,让性能差的机器承载权重小一些,流量少一些。
leastactive loadbalance
最少活跃负载均衡,这个就是自动感知一下,如果某个机器性能越差,那么接收的请求越少,越不活跃,此时就会给不活跃的性能差的机器更少的请求。
consistanthash loadbalance
一致性 Hash 负载均衡,相同参数的请求一定分发到一个 provider 上去,provider 挂掉的时候,会基于虚拟节点均匀分配剩余的流量,抖动不会太大。如果你需要的不是随机负载均衡,是要一类请求都到一个节点,那就走这个一致性 Hash 策略。
集群容错策略
failover cluster 模式
失败自动切换,自动重试其他机器,默认就是这个,常见于读操作。(失败重试其它机器)
可以通过以下几种方式配置重试次数:
<dubbo:service retries="2" />
或者
<dubbo:reference retries="2" />
或者
<dubbo:reference> <dubbo:method name="findFoo" retries="2" /></dubbo:reference>
failfast cluster 模式
一次调用失败就立即失败,常见于非幂等性的写操作,比如新增一条记录(调用失败就立即失败)
failsafe cluster 模式
出现异常时忽略掉,常用于不重要的接口调用,比如记录日志。
配置示例如下:
<dubbo:service cluster="failsafe" />
或者
<dubbo:reference cluster="failsafe" />
failback cluster 模式
失败了后台自动记录请求,然后定时重发,比较适合于写消息队列这种。
forking cluster 模式
并行调用多个 provider,只要一个成功就立即返回。常用于实时性要求比较高的读操作,但是会浪费更多的服务资源,可通过 forks="2"
来设置最大并行数。
broadcacst cluster
逐个调用所有的 provider。任何一个 provider 出错则报错(从2.1.0
版本开始支持)。通常用于通知所有提供者更新缓存或日志等本地资源信息。
动态代理策略
默认使用 javassist 动态字节码生成,创建代理类。但是可以通过 spi 扩展机制配置自己的动态代理策略。
启动时检查
Dubbo 缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止 Spring 初始化完成,以便上线时,能及早发现问题,默认 check="true"。
可以通过 check="false" 关闭检查,比如,测试时,有些服务不关心,或者出现了循环依赖,必须有一方先启动。
另外,如果你的 Spring 容器是懒加载的,或者通过 API 编程延迟引用服务,请关闭 check,否则服务临时不可用时,会抛出异常,拿到 null 引用,如果 check="false",总是会返回引用,当服务恢复时,能自动连上。
失败重试和超时重试:
所谓失败重试,就是 consumer 调用 provider 要是失败了,比如抛异常了,此时应该是可以重试的,或者调用超时了也可以重试。配置如下:
<dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="3" timeout="2000"/>
举个栗子。
某个服务的接口,要耗费 5s,你这边不能干等着,你这边配置了 timeout 之后,我等待 2s,还没返回,我直接就撤了,不能干等你。
可以结合你们公司具体的场景来说说你是怎么设置这些参数的:
timeout
:一般设置为200ms
,我们认为不能超过200ms
还没返回。retries
:设置 retries,一般是在读请求的时候,比如你要查询个数据,你可以设置个 retries,如果第一次没读到,报错,重试指定的次数,尝试再次读取。默认为2,也就是说,加上首次调用一共会调用3次