背景

部署了两台服务器,每台上都有相同的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. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性