有同事问dubbo的负载均衡是zookeeper做的吗,我也不知道,尴尬不,但是猜着是dubbo内部做的,实时负载均衡是由dubbo-admin处理的,那么在dubbo-admin的界面上修改weight参数就好了
那么这个参数的具体体现是到了哪里呢?
com.xxxx.xxx.common.service.basic.IAuditJoursService=override\://192.168.247.9/com.xxxx.xxx.common.service.basic.IAuditJoursService?category\=configurators&dynamic\=false&enabled\=true&weight\=400
可以看到在dubbo.registry里面插入了一条内容,weight改为了400,那么这个服务的权重就是400,客户端在调用的时候会根据weight以及策略决定调用哪一个服务提供者
protected int getWeight(Invoker<?> invoker, Invocation invocation) {
// 根据url获取weight
int weight = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.WEIGHT_KEY, Constants.DEFAULT_WEIGHT);
if (weight > 0) {
long timestamp = invoker.getUrl().getParameter(Constants.TIMESTAMP_KEY, 0L);
if (timestamp > 0L) {
// 计算服务的启动时间
int uptime = (int) (System.currentTimeMillis() - timestamp);
int warmup = invoker.getUrl().getParameter(Constants.WARMUP_KEY, Constants.DEFAULT_WARMUP);
// 如果启动时间小于预热时间的话,默认60s
if (uptime > 0 && uptime < warmup) {
weight = calculateWarmupWeight(uptime, warmup, weight);
}
}
}
return weight;
}
/**
* 启动时间 / 预热时间 * 权重 说明还没有预热完的服务被选取的几率比较小,
* 预热可能加载一些数据字典等基础内容
*/
static int calculateWarmupWeight(int uptime, int warmup, int weight) {
int ww = (int) ( (float) uptime / ( (float) warmup / (float) weight ) );
return ww < 1 ? 1 : (ww > weight ? weight : ww);
}
AbstractLoadBalance.java
protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);
所有的负载均衡策略集成此类,并自己实现选择的算法,dubbo默认选择random算法
- Random LoadBalance
随机,按权重设置随机概率。
在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。 - RoundRobin LoadBalance
轮循,按公约后的权重设置轮循比率。
存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。 - LeastActive LoadBalance
最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance - 一致性 Hash,相同参数的请求总是发到同一提供者。
当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
算法参见:http://en.wikipedia.org/wiki/Consistent_hashing
缺省只对第一个参数 Hash,如果要修改,请配置
缺省用 160 份虚拟节点,如果要修改,请配置