天池练习赛：【中间件极客榜】自适应负载均衡的设计实现

• 比赛地址
  https://tianchi.aliyun.com/competition/entrance/231740/score
• 我的代码
  https://code.aliyun.com/harryhare/adaptive-loadbalance
• 最终成绩
  18 名 ，1295781/1295781/28385

由于这个比赛后期不在提供日志，所以比较郁闷

题目分析

请求并发连接数是1024， 几个provider 的最大线程数分别是200/450/650，虽然 provider 有另外的信号量限制并发量，但是从测试数据上看，他们的和比1000大一些，所以provider 应该是足够的。

很容易想到，如果我们确切的知道每个provider的并发量，那么按照rtt，先把请求都打到rtt最小的provider，直到打满，然后把请求打到rtt次小的provider，依此类推，简单的贪心策略就能得到最优解。
但是问题就在于我们并不确切知道每个provider的并发量，也就是provider中根据时间动态调整的那个信号量.
rtt 相对来说倒是容易得到，只要统计一段时间内的请求耗时，平均一下就可以了

各种做法

简单的动态策略

参考这篇：https://tianchi.aliyun.com/notebook-ai/detail?postId=66591
不要看文章里又是回压又是跳表的，其实他的策略非常简单，概括下就是：
如果rtt小于3ms，那么增加这个provider的权重，同时降低其他provider的权重，维持总的权重不变
所以完全用不着跳表这种复杂的数据结构，只要几个计数器就可以达到一样的效果。
我的成绩就是用计数器跑出来的。
另外说下，小于3ms的请求放入优先队列影响并不大。
这个策略的合理性在于，如果一个请求在很小的时间返回，那么现实这个provider 大概率没有过载，并且这个provider 的rtt 应该很小。
由于provider的rtt 是指数分布

cdf = 1 - Math.exp(-1.0D * 1 / currentConfig.avg_rtt * x);

$F(x)=1-e^{-\frac{x}{T}}$

我们把这个概率累加函数求导，得到概率密度函数
$f(x)=\frac{1}{T}{e}^{-\frac{x}{T}}$

$f(0)=\frac{1}{T}$
所以在rtt 小的请求出现的频率应该是和 平均返回时间T成反比的

通过建模判断有没有超过实际的并发量

参考：https://tianchi.aliyun.com/notebook-ai/detail?postId=77159
思路就是过载后，rtt会变长，整个曲线会向右移动，导致0点附近的请求减少，利用这点判断有没有超载，如果超载则降低provider权重

我本地跑了下帖子中提到的代码，但是在我本地测试，那个模型给出的overload 预测并不好，我怀疑只有使用和测评环境接近的环境，实际使用4个机器，才有可能有比较好的结果。由于我没有这个环境，就不研究下去了。

经验不足踩的坑

• 相同的代码提交分数也会差很多，好像每次的provider 并发量和rtt都是随机生成的，建议每次提交至少测两次
• 本地环境和提交环境的结果会差很多，所以即使在本地开发时分数很差，也最好提交试一下
• 把一些log中的关键数据可视化非常重要！！！
• 如果标准输出里面没有error，去找下 log 文件
• 如果用了两个数组分别存储开始时间和返回时间，那么在计算rtt时，有些已经开始的请求并没有结束，这些点只有开始时间，没有结束时间，处理这些数据时要注意
• java/dubbo 可以获得线程数，所以要学会查api
• atomic 类型实际开销很小，比ConcurrentLinkedQueue这种并发数据类型的开销小很多。
  下面是1e7 次每种操作的耗时

  integer++ cost:4ms
  getAndIncrement cost:74ms
  integer cost:7ms
  atomic get cost:12ms 
  concurrent queue add cost:7801ms
  linked list add cost:3212ms
  concurrent queue poll cost:14ms
  linked list poll cost:6ms