【原创】【算法之旅】实现简单负载均衡模型

负载均衡见字识意，即实现压力的平衡，一般认为是指平衡分配网络请求，减缓服务器压力或者最大利用服务器效率的方案 Talk is cheap, show me the code. 话不多说，本文接下来就简述几种简单实现负载均衡的方案，作者水平有限，只能提供简单实现 : ） ❤️严格轮询【图一】【图二】【图三】 这种方案很直接：既然你要每个请求平均分配，那我就主动进行记录，并且下一次轮换就行了 此处考虑的是理想的情况（单线程），如果是多线程，还需要加个锁，并且还需要维护ip索引，这些都需要额外的性能开销 ❤️听天由命 【图四】 如果不想主动维护索引或者加锁，那么随机也不失为一种好方法，这种方案将允许请求的服务器插入一个列表，然后通过随机数索引的方式实现 🧡但是这种实现的缺陷也很明显：随机是不可控的，也就是说不能完全做到平均 并且，我们忽略了一个现实的问题：如果每个服务器性能不一样，上述方案都无法进行合理分配 ❤️加权轮询【图五】 上面提出的两种方法都是基于【性能相同】的前提，但实际情况不会这么美好 比如说 10.0251.38.2 这个服务器能承受其他服务器两倍的开销，这时就可以采样本方案，给每个服务器对应的 权重 这样我们就可以根据不同服务器的性能分配不同的访问量但这种方式的缺点和严格轮询一样，需要花费额外开销去维护索引（当然这个可以再抽象来避免），并且多线程还要考虑线程安全最遭的情况是权重相差过大 例如权重为[5, 200, 10, 100]，如果是按顺序下来，当只有200个请求的时候，末尾的两个服务器压根不处理任何请求；并且用来均衡的tempServerList也会变大，占用额外的内存，由此可见这并不是特别合理的算法 有的读者可能会说，那还不简单，我保障最大的服务器一定在末尾就行了，[5, 10, 100, 200]，这样不就合理了吗，但是你看看，这样面对大请求时，承载能力弱的服务器就永远处于满载，而高性能的服务器也不能发挥自己的优势，我们还需要进一步完善 ❤️随机加权【图六】 这种方案其实就是二、三的结合，在加权的前提下随机访问可以看出权重高的访问次数也会更高，只不过不是绝对平均然而理想很丰满，现实很骨感，现在我们看似有了一个相对完美的解决方案 🧡但随着思考的深入，我们会意识到一个新问题： session（服务端缓存）如何处理呢？ 假设一个账号在10.251.38.1进行了登录，留下了session缓存，结果下一次请求却被分配到了另一个服务器10.251.38.2，这个服务器可没有该用户的session缓存，于是又要【重新登录】，这是很致命的 ❤️哈希分配【图七】 这种方案会根据用户的ip哈希值进行分配，也就是说同一个ip的请求会被分配到固定的服务器 这样只要用户ip不变，就会被分配到固定的服务器，而缺陷也很明显，就是负载均衡的颗粒度过大，即不能按照服务器性能分配，而是根据ip的哈希来计算，同一个哈希永远会请求相同的服务器 如果恰好高频地区的ip的哈希计算值都为1，那么依旧会导致索引为1服务器压力过大，即便其他服务器非常悠闲，也爱莫能助 ❤️加权哈希分配【图八】 我们可以通过权重来尽量保证性能高的服务器承载更多的请求，同时又兼顾session 虽然本质上同一个ip还是会分配到同一个服务器，但我们可以让权重更高的服务器获得更多请求，当然，只是治标不治本的权宜之计 ❤️灵活加权【图九】【图十】【图十一】【图十二】【图十三】【图十四】 🧡文章放不下的图参考评论区 上面方案的问题主要是当ip定死后就无法再改变请求的服务器，这很明显违背了负载均衡的初衷，我们可以稍作处理，例如记录当前ip时间戳，如果已经过半小时了（或者session过期）那么就重新分配在保障session的同时尽可能的均衡服务器压力 不过我上面的实现还是有点问题，目前还在寻找解决方案。。。 ❤️长路漫漫 本文总结了几种简单的负载均衡模型，实际业务环境要复杂的多，考虑的因素也很多 本文负载均衡成立的前提是“每个请求体量一致”，然而实际情况中请求一张图片和请求一个文本会有很明显的差距 限于作者水平，暂时无法提供成型的负载均衡算法模型，本篇仅供学习参考，长路漫漫，学海无涯，唯有保持学习的热情，才能翻过一座又一座困难的山头，与诸位共勉 [彩虹]pluie [彩虹]2023/04/12