02｜负载均衡：调用结果、缓存机制是怎么影响负载均衡的？
前置知识
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了微服务架构下的负载均衡算法及其影响因素。首先介绍了负载均衡的基本概念，包括静态负载均衡算法和动态负载均衡算法。接着详细解释了常见的负载均衡算法，包括轮询与加权轮询、随机与加权随机、哈希与一致性哈希、最少连接数、最少活跃数以及最快响应时间。一致性哈希负载均衡算法被强调为面试热点，通过生动的比喻向读者解释了其工作原理。此外，文章还提到了各种算法的优缺点和适用场景，以及对应的改进算法。文章还提到了负载均衡算法的面试准备和亮点方案，包括对常见算法的记忆和理解、实际工作中的应用情况、以及根据业务设计独特的负载均衡算法。最后，文章介绍了负载均衡算法的面试思路总结和思考题。整体而言，本文系统地介绍了负载均衡算法的原理和实际应用，对于想要深入了解微服务架构下负载均衡的读者具有很高的参考价值。
《后端工程师的高阶面经》，新⼈⾸单¥59
全部留言(19)
- 最新
- 精选
penbox1. 如果单纯从算法效果看，随机和轮询其实差不多。而现在据我观察，使用轮询要比使用随机多得多，你觉得这是为什么？ 轮询算法和随机算法，从统计学角度来看，最终效果是一样的。但是轮询算法天然的就会比随机算法更平滑，可以避免连读多次请求打到一个节点上。 2. 在基本算法总结里面我用最少连接数算法举一个反面例子，但是同样的算法用在网关负载均衡上，就没有类似的问题，为什么？ 客户端统计的连接数只是客户端自己与服务端之间的连接数，并不能代表服务端上所有的连接数，所以不具备参考性。而网关是服务端所有连接的入口，网关上统计的连接数实际上就是服务端的所有连接数，所以这个指标是有参考性的。作者回复: 赞！非常准确！
2023-07-01归属地：四川213
程序员花卷为什么轮询比随机使用得多？ 随机其实是不均衡的，可能会出现多次命中同一个服务端节点的情况，导致该服务端节点负载过高，严重的还有可能会产生服务雪崩。轮询可以将请求均衡的分发到每个服务端节点，一个个轮流着来，这样可以避免所有请求打到一个服务端节点的情况。但是轮询也有缺点，比如每个节点的处理能力可能并不一样，一个个轮流着命中的话，一些大请求也有可能会打到处理能力比较弱的节点上，显然不太合理。作者回复: 对的，随机的问题就是这个，尤其是特别倒霉的时候，你连续几次都命中同一个节点。当然，这也可以看做是可控性不强。 后面你对轮询的讨论也很对。一些简单的做法就是用权重来代表节点的处理能力，于是有了加权轮询。但是大请求的问题是非常难以解决，这也是不管选择什么负载均衡算法都有可能遇到偶发性的负载不均衡的根本原因。 之前我见过别人的骚操作，就是在负载均衡里面会检测一下是不是大请求。这个检测非常简单，就是每天计算一批大用户，然后负载均衡器会全量加载这些用户的 ID，在调用特定服务的时候，如果请求的用户 ID 就是这些大用户的 ID，就判定为大请求，而后发送到几台专门的机器上。 不过从本质上来说，它只是避开了大请求的问题，也没有根治。
2023-06-22归属地：云南11
雨落～紫竹我想到一个场景 对于大数据场景 数据都是从kafka来的 数据从kafka拉取后 要去获取一些其他数据 而对于一些热点数据 虽然放在redis 但是请求太频繁 网络成为瓶颈 所以放在本地缓存 但是过一段时间 可能导致所以机器 本地缓存的数据基本一致 可以根据对kafka消息进行一定维度的hash发送到指定分区 这样每台机器本地缓存 存的数据都不一样作者回复: 对的！这种根据哈希来选择对应分区的思路可以用于解决缓存、有序性。我之前还用过这个方式来优化过分布式锁。因为同一个业务的都分到了同一个分区上，所以只有一个消费者，也就不需要分布式锁了，差不多都是这个思路
2023-06-26归属地：北京5
特修斯之船没说到一致哈希的重点啊，这样一问就知道是半桶水，死记硬背。 普通哈希会面临一个问题，就是当增加或删除节点时，哈希值会重新落在不同的节点上，违背使用哈希算法的本意。 一致性的意思是保证当服务集群某个真实服务器出现故障，只影响该服务器的哈希，而不会导致整个服务集群的哈希键值重新分布。作者回复: 嘿嘿，我是觉得哈希的这个特性应该不需要我特意提，算是计算机非常基础的知识了，所以我并没有怎么说这个问题。后面我是觉得，哈希值均匀性和哈希环上节点的均匀性反而是比较少人讨论的，所以我提了一下。就好比随机，一个明显的缺点就是运气不太好的时候全部在一个节点上，这个也应该是比较容易想到的。
2023-07-20归属地：广东23
peterQ1：“客户端”并不是指终端，对吗？ 本课中用到的“客户端”，我理解并不是通常意义上的网页或APP，而是相对于“服务端”的客户端；从后面的内容来看，也不是指Nginx或网关。那在微服务架构中，具体是指什么？ Q2：哈希算法怎么保证均匀吗？ 文中“所以要尽可能保证哈希值计算出来的结果是均匀的”，有什么具体方法来保证哈希的均匀性？ Q3:99线是什么意思？ 文中“可以是平均响应时间，也可以是 99 线之类的”，此处的99线是指什么？ Q4：负载均衡有多种算法，对于一个公司来说，是确定用其中的某一种吗？或者是不同的子系统可能采用不同的算法？或者有多种算法，会根据情况动态选用其中的某一种？ Q5：“响应+元数据”这种，消息是怎么发送的？ 响应是给用户的，通常就是HTTP消息，元数据是内部用的，这两种怎么处理？定义一个内部消息，包含这两种，Nginx收到后取出元数据然后将响应发给用户吗？ Q6：Nginx与网关重复吗？ 用了Nginx，还会用网关吗？或者反过来，用了微服务网关，还需要用Nginx吗？网关数量一般很少吧，一般就两台作为主备，不能直接接收用户消息吗？网关外面还需要用Nginx吗？作者回复: 1. 这里要区分不同作用的网关。nginx是一种网关，还有一种微服务网关，比如说小伙伴搞的shenyu 就可以充当微服务网关，现在也叫做API网关，类似的还有APISIX之类的。 大公司网关会有多个，用于不同场景。正常来说nginx肯定会有，作为最外层的Web网关。
2023-06-20归属地：北京63
sheep平滑的加权轮询算法里面，这里的weight和currentWeight值都是多少呢，另外每一个节点的weight和currentWeight也应该会不一样吧作者回复: 初始的时候你随便设置一个就可以，运行过程中它们可能一样，可能不一样，说不准。
2023-08-27归属地：广东2
Nordlicht将目标节点的 currrentWeight 修改为 currrentWeight= currrentWeight - sum(weight)。 这里减去sum(weight)会不会出现负数情况作者回复: 会，而且几乎一定会。就是因为出现负数之后，下一次你就肯定不会选中它
2023-06-27归属地：江苏2- Geek_6806321.轮询相较于随机来说更加稳定，在最坏的情况下，随机可能导致一个节点分配到了大量请求；2.网关和应用服务所承载的职责不同，应用服务需要消耗大量资源，所以一定范围内的请求增长影响更大。
作者回复: 2. 有道理。同时还是要考虑网关的一个特性，就是网关是知道所有服务端节点的情况的，所以它可以选出全局最优解。
2023-10-11归属地：浙江1 
风清扬平滑的加权轮训算法，查阅了下，最早是在Nginx中出现，https://github.com/phusion/nginx/commit/27e94984486058d73157038f7950a0a36ecc6e35作者回复: 赞！ 不过现在面试，单纯回答加权轮询，已经无法赢得竞争优势了。所以你要搞花活，就是各种 SAO 操作，调整权重。比如说超时了，我下调一点点；触发熔断、限流了，我唰一下调到很低。 这样面试就比较有亮点。
2023-08-30归属地：广东1
不吃辣👾为什么业界没有服务端上报自己状态给客户端的负载均衡算法呢？ 感觉挺合理的。为什么呢作者回复: 因为用不上……就是这些花里胡哨的负载均衡算法在面试的时候很有价值，但是实践中很少应用。 大多数场景下，简单的轮询就足够了。 不过近两年有一些微服务框架允许在响应头里面带上一些元数据，这一类的负载均衡才开始多了起来。
2023-08-13归属地：浙江21
