负载均衡算法是什么，一句话能说清：来一个请求，它负责决定往后端哪台机器送。可这 4 种调度策略怎么分工，问的人多，答得明白的少。四台机器摆在那儿，请求却全压在最先回话的一台上——这跟机器性能没多大关系，跟分流没人管有关系。
算法这层干的事很窄。给一个请求挑一台机器，挑法不同名字就不同，剩下全靠周边配置兜着。
负载均衡算法是4种调度策略分工的底子，先弄清它在决定什么
挑之前还有一层：四层还是七层。四层看 IP 和端口，七层能看 URL、Header、Cookie。七层能按路径分流，灵活，但多吃一点性能。具体支持到什么程度，以你手上那套负载均衡器的文档为准，各家实现差别不小。
真正影响体验的往往不是挑的那一下，是挑错之后慢慢积压的那几天。刚上线看不出来，跑了半个月后端一台越来越慢，你才回头找原因，那时候日志早滚没了。
轮询：最省事，机器不一样的时候翻车最快
轮询就是排队点名，一二三四转一圈再来一遍。机器配置一致、请求耗时差不多，这个最省心，配置也简单，出问题好查。
坑在机器不一样的时候。老机器和新买的混在一起，轮询照样一人一份。老机器队列越拉越长，它先顶不住，剩下的机器接盘后被一起压垮——雪崩常常从最弱的那台开始，不是从最强的。
另外还有个随机调度，实现同样简单，小流量下跟轮询差别不大，不值得专门追着换。
加权轮询：权重不是照着 CPU 核数随手填
很多人进后台看到权重字段，八核填 8、四核填 4。听着有道理。可你的业务要不是 CPU 密集型，这权重就白填了；磁盘 IO 慢的机器，核数再高也扛不住。
权重得靠观察调。先按大概比例给一版，跑几天看后端各自的连接数、响应时间，再往回修。调完别当一劳永逸，机器换了、业务涨了，比例就得跟着动。
最少连接：慢请求堆起来时，它比轮询聪明
最少连接看的是谁手上活少，新请求给最闲的那台。长连接、上传下载、接口里有慢查询的场景，它明显比轮询稳，不会让一台硬扛着几十个没结束的连接还在接新活。
前提是负载均衡器知道真实连接数。有些实现只算自己这层的连接，后端真实压力看不见，那就不准了。还有一种请求来得快、结束也快，连接数一直抖，它会来回横跳，效果跟轮询差不多。
哈希：会话和缓存靠它，扩容那一下最要命
源地址哈希，同一个 IP 固定落到同一台。会话存在本机内存的老系统靠这个能少掉一堆登录态，用户不会刷一下就得重新登录。
一致性哈希是为了扩容时少搬数据。普通取模哈希，加一台机器几乎所有的 key 都要重新映射，缓存一下全灭，请求全砸到数据库上。一致性哈希只搬一小段，代价小得多。细节各家实现不一，还是看文档。
哈希的毛病是倾斜。少数热门 IP 段或者几个大客户，能把一台压满，其余闲着。得上虚拟节点，或者换个维度做哈希。会话这块其实还有另一条路：把 session 挪到 Redis 这类共享存储，后端就不必绑在一台机器上，哈希的压力一下小很多。
健康检查不算算法，少了它前面全白搭
算法选得再对，一台机器挂了却不知道，请求照样往上送，用户看到的就是 502。健康检查常见两种：探端口通不通，探业务接口返回对不对。前者省资源，后者准。数据库断了但 web 进程还在，端口探测是探不出来的。
间隔也别设太密。几十台机器每秒探一次，后端自己先被探出问题。
怎么挑：看业务最怕哪一段抖
静态资源、无状态接口，轮询加上权重就够用，别上复杂的，配置越绕越难查。
长连接、上传下载、接口里有慢查询，最少连接。
会话在本地内存、缓存命中率要紧，哈希。
拿不准就先轮询，把监控挂上，看后端连接数和响应时间怎么分布，再换。
还有句得说在前头：算法治不了代码里的病。一个接口自己拖三秒，换十种调度它还是三秒，只是把排队的位置换了个地方。
真要落地，顺序大概是：先把健康检查配对，再摸清后端机器差多少，然后把连接数、响应时间、错误率三条监控曲线挂上，跑一周基本能看出该选哪个。选完别锁死，业务量一变，原来的权重和策略大概率就得重调，这套东西本来就不是一次配完就不管的。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
