使用Dubbo，我们可以非常方便地做服务的水平扩展，集群部署。

那么问题来了，Dubbo的负载均衡策略是怎么样的？

Dubbo为我们提供了4种策略，默认是随机策略。

4种策略分别如下：

Random LoadBalance

随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

轮询，按公约后的权重设置轮询比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
缺省只对个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

实验步骤：

1，服务提供方开启多个实例

2，消费方通过设置负载均衡策略，重复调用服务接口，观察其执行结果。

3，注意要将服务提供方部署在多个服务器，不同的ip，才可以看到正确的效果

调用方程序：

/**
 * @author huangguizhao
 */
@Controller
@RequestMapping("user")
public class UserController {
    @Reference(loadbalance="roundrobin")
    private IUserService userService;

    @RequestMapping("hello")
    @ResponseBody
    public String hello(){
        return userService.hello();
    }

}

通过多次访问接口测试接口：

也可以在配置文件统一配置

dubbo：
  provider:
    loadbalance: roundrobin

之前配置文件的配置方式：

<dubbo:referenceinterface="..."loadbalance="roundrobin" />