背景
部署了两台服务器,每台上都有相同的dubbo的提供者。但是发现,A挂了后,请求报错,不会自动去请求另一台正常运行的提供者。
处理方法
修改前的dubbo配置(yml):
dubbo:
application:
name: provider-serviceName
registry:
timeout: '60000'
address: zookeeper://ip:2181
username: username
password: password
protocol:
name: dubbo
port: '-1'
monitor:
protocol: registry
consumer:
check: false
修改后配置:
dubbo:
application:
name: provider-serviceName
registry:
timeout: '60000'
address: zookeeper://ip:2181
username: username
password: password
protocol:
name: dubbo
port: '-1'
monitor:
protocol: registry
consumer:
check: false
provider:
timeout: '60000'
#负载均衡策略:加权轮询
loadbalance: roundrobin
即增加了对提供者的负载均衡配置,负载均衡使用的策略为加权轮询。
provider:
timeout: '60000'
#负载均衡策略:加权轮询
loadbalance: roundrobin
修改后,则可实现,2个privider中某个挂掉后,会自动转向请求另外一个。
原理
dubbo的负载均衡算法一共有5中,默认是随机算法:
奇怪的是,我实验的过程中,某台提供者挂掉后,始终没有去请求另一台,感觉也不随啊,不知道为什么。
本来优先考虑使用一致性hash,但是部署后,仍然没有自动请求正常运行的提供者。待后面再研究吧。。。
原文地址:http://www.cnblogs.com/zjfblog/p/16790999.html
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,请务用于商业用途!
3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需!
7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员!
8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载
声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性