文章插图
这一部分代码的关键，就在上面框起来的部分 。而框起来的部分，最关键的地方，就在于第一行 。
文章插图
获取调用成功的平均时间 。
成功调用的平均时间怎么算的？
调用成功的请求数总数对应的总耗时 / 调用成功的请求数总数 = 成功调用的平均时间 。
所以，在下面这个方法中，首先获取到了调用成功的请求数总数：
文章插图
这个 succeeded 参数是怎么来的呢？
文章插图
答案就是：总的请求数减去请求失败的数量，就是请求成功的总数！
那么为什么不能直接获取请求成功的总数呢？
别问，问就是没有这个选项啊 。你看，在 RpcStatus 里面没有这个参数呀 。
文章插图
请求成功的总数我们有了，接下来成功总耗时怎么拿到的呢？
文章插图
答案就是：总的请求时间减去请求失败的总时间，就是请求成功的总耗时！
那么为什么不能直接获取请求成功的总耗时呢？
别问，问就是......我们看一下 RpcStatus 中的这几个参数是在哪里维护的：
org.apache.dubbo.rpc.RpcStatus#endCount(org.apache.dubbo.rpc.RpcStatus, long, boolean)
文章插图
其中的第二个入参是本次请求调用时长，第三个入参是本次调用是否成功 。
具体的方法不必细说了吧，已经显而易见了 。
再回去看框起来的那三行代码：
文章插图
- 第一行获取到了该服务提供者成功请求的平均耗时 。
- 第二行获取的是该服务提供者的活跃数，也就是堆积的请求数 。
- 第三行获取的就是如果当前这个请求发给这个服务提供者预计需要等待的时间 。乘以 active 的原因是因为它需要排在堆积的请求的后面嘛 。
后面的代码怎么写？
当然是出来一个更短的就把这个踢出去呀，或者出来一个一样长时间的就记录一下，接着去 pk 权重了 。
所以，接下来 shortestIndexes 参数和 weights 参数就排上用场了：
文章插图
另外，多说一句的，它里面有这样的一行注释：
文章插图
和 LeastActiveLoadBalance 负载均衡策略一致，我给你截图对比一下：
文章插图
可以看到，确实是非常的相似，只是一个是判断谁的响应时间短，一个是判断谁的活跃数低 。
标号为③的地方
标号为③的地方是这样的：
文章插图
里面参数的含义我们都知道了，所以，标号为③的地方的含义就很好解释了：经过选择后只有一个服务提供者满足条件 。所以，直接使用这个服务提供者 。
标号为④的地方
文章插图
这个地方我就不展开讲了（后面的加权随机负载均衡那一小节有详细说明），熟悉的朋友一眼就看出来这是加权随机负载均衡的写法了 。
不信？我给你对比一下：
文章插图
你看，是不是一模一样的 。
标号为⑤的地方
文章插图
一行代码，没啥说的 。就是从多个满足条件的且权重一样的服务提供者中随机选择一个 。
如果一定要多说一句的话，我截个图吧：
文章插图
推荐阅读
- 带你走进潮汕工夫茶,工夫茶点心
- 带你了解安徽四大名茶,安徽茶打四大品牌
- 带你去看美团架构
- 万字长文讲解编码知识，看这文就够了！| 原力计划
- 一文带你彻底理解Linux的各种终端类型及概念
- 一篇长文学懂入门推荐算法库：surprise
- 电力负荷怎么计算？几分钟带你了解清楚，好东西，赶紧收藏
- 最新百度信息流产品手册，带你全面了解百度产品
- 三分钟带你了解香槟产区另一面，谈香槟，你也是行家
- 没有人比我更懂电流，今天带你重新认识电流