说句实话，搞了这么多年后端，每次看到有人把负载均衡当成“多放几台服务器然后轮询”的时候，我就想摔杯子。真的，这玩意儿没那么简单，但也绝对不难。今天咱们不聊那些虚头巴脑的概念，直接拆开看核心算法。
核心算法拆解：轮询、哈希和“聪明”的懒惰
轮询是最老实的。按顺序一个一个来，就像排队打饭。但问题在于，它压根不管每台机器的真实负载。有的机器已经快被压垮了，轮询还是照样给它派活儿。这时候就有了加权轮询——给机器配置权重，大的多接点，小的少接点。这有点人性化了，但权重怎么定？拍脑袋还是看监控？都不靠谱。
再说最少连接。听名字就知道，谁当前连接数少就发给谁。这个算法在长连接场景下很管用，比如数据库连接池。但它有个毛病——如果请求处理时间差异极大，一个快速请求可能刚被分配就结束了，导致某些机器一直被“饱和式攻击”。
然后，重点来了，一致性哈希。这玩意儿就像给钥匙配锁。传统的哈希取模，一旦节点数量变化，几乎所有映射都乱了套。一致性哈希把节点放到一个环上（想象成一个10米长的环形跑道），每个请求按哈希值落在某段弧线上，然后顺时针找最近的节点。这样新增或删除节点，只有相邻的节点受影响，其他区域纹丝不动。
压测数据说话：一致性哈希凭什么赢了？
光说理论没用，得看数据。我们之前做过一个实验：模拟1000个请求打散到5个缓存节点。用普通取模（hash(key) % 5）和一致性哈希对比。先看缓存命中率。忽然加一个节点（从5台变6台），取模的命中率直接从92%暴跌到45%——一半的缓存全失效了。而一致性哈希只跌到88%。这差距是致命的。对于缓存系统，失效意味着穿透，后端数据库直接被打爆。
再看CPU开销。因为取模失效后大量请求打到数据库，整个系统CPU瞬间飙到95%以上，而一致性哈希保持在35%左右。你可能会说，这是缓存场景，那纯负载均衡呢？我们测试了长连接场景下，最少连接和一致性哈希的对比。在10000个并发连接下，最少连接的单机连接数波动在±20%，而一致性哈希的波动只有±5%，而且连接建立时延平均低12ms。
这些数字背后是数学上的必然。一致性哈希的“局部敏感”特性，决定了它天然适合缓存、会话亲和这些需要稳定映射的场景。但注意，它也不是银弹。
落地三个大坑：我踩过，你别再踩了
第一个坑是会话保持。一致性哈希能保住一些session，但如果节点挂了，之前落在它上面的会话全得重建。那怎么办？解决方案：在应用层做session复制，或者把session外置到Redis。负载均衡层面别瞎折腾，把session剥离出来才是正道。
第二个坑是健康检查的误判。很多人只检查端口通不通，结果节点已经死了一半还在接流量。我用过一次最烂的配置——每5秒探一次TCP，端口活着就以为一切正常。结果那台机器GC已经卡死了几百次。要我说，健康检查必须做成HTTP探测，返回码非200就摘掉，而且超时时间要短，比如500ms，连续3次失败才判定宕机。别问为什么，这是用血泪换来的。
第三个坑是连接复用。在HTTP/2或gRPC下，连接是复用的，但负载均衡器如果只看连接数，很容易让一个本来很闲的节点被一堆长连接占满。你可能会说用最少连接啊，但最少连接只计数，不看流量。解决办法是加一层应用层指标，比如当前请求处理中的QPS、网络吞吐，或者用自适应算法，像gRPC的客户端侧负载均衡那样。别老捧着老掉牙的算法不放手。
说白了，负载均衡不是选一个算法就完事。你得理解每个算法背后的数学和业务场景。选型的时候多问自己几个为什么，别拿“默认轮询”糊弄事。
