负载均衡有哪些常见算法？如何选择？
简化版
负载均衡是把请求分发到多个后端节点，提升吞吐、可用性和扩展能力。常见算法有轮询、加权轮询、随机、加权随机、最少连接、一致性哈希、响应时间优先。选择时要看节点性能是否一致、请求耗时是否差异大、是否需要会话粘滞、是否要减少扩缩容时的数据迁移。
详细版
| 算法 | 思路 | 适合场景 | 注意点 |
|---|---|---|---|
| 轮询 | 请求按顺序分给节点 | 节点性能接近、请求耗时接近 | 慢节点会被打爆 |
| 加权轮询 | 性能强的节点分更多请求 | 节点配置不同 | 权重要动态调整更好 |
| 随机 | 随机挑一个节点 | 节点多、请求均匀 | 小流量可能不均 |
| 最少连接 | 分给当前连接数最少节点 | 长连接、请求耗时差异大 | 需要统计连接数 |
| 一致性哈希 | 同一 key 落到固定节点 | 缓存、分片、会话粘滞 | 要用虚拟节点缓解倾斜 |
| 响应时间优先 | 优先选延迟低的节点 | 服务节点性能波动 | 要防止短期抖动误判 |
负载均衡还要配合健康检查、故障摘除、慢启动、限流、熔断。算法只是分流规则，真正的高可用来自“发现坏节点、少打坏节点、恢复时慢慢放量”。
完整版教学
一、负载均衡解决的不只是平均分配
很多人把负载均衡理解成“把流量平均打到多台机器”。这只是最表层。真正的目标有三个：第一，提高吞吐，多台机器一起处理请求；第二，提高可用性，某台挂了还能把流量切走；第三，提高扩展性，加机器后能自然接流量。
如果没有负载均衡，客户端要知道所有服务实例，扩缩容和故障切换都会很痛苦。负载均衡把这些复杂性收在统一入口里。
二、轮询和随机为什么还不够
轮询简单，但默认每台机器能力一样、每个请求成本一样。现实里机器配置不同，请求也不同：一个导出报表请求可能跑 10 秒，一个查询请求只要 10 毫秒。如果仍然机械轮询，慢请求堆在某台机器上，会让它越来越慢。
加权轮询能解决机器性能不同的问题，比如 8 核机器权重 8，4 核机器权重 4。但权重最好不是静态写死，而是结合 CPU、负载、错误率、延迟动态调整。
三、最少连接适合长连接和耗时差异大的请求
最少连接不是看总请求数，而是看当前活跃连接或活跃请求。对 WebSocket、数据库代理、RPC 长连接、文件下载这类场景，它比轮询更合理。因为一个节点虽然过去接得少，但如果现在挂着很多长连接，就不应该继续给它压流量。
缺点是统计成本更高，而且连接数不完全等于负载。有些连接空闲，有些连接很忙，所以更成熟的策略会结合连接数、响应时间、错误率一起判断。
四、一致性哈希解决“按 key 稳定路由”
缓存和分片场景经常希望同一个 key 落到同一台机器。普通取模 hash(key) % N 在扩容时会导致大量 key 重新映射，缓存大面积失效。一致性哈希把节点和 key 都映射到一个哈希环上，key 顺时针找到第一个节点。新增或删除节点时，只影响环上一小段 key。
不过真实系统一定要加虚拟节点。否则节点少时，哈希环分布不均，某台机器可能负责很大一段范围，形成热点。虚拟节点把一个真实节点拆成多个点放到环上，让分布更平滑。
五、健康检查比算法更重要
负载均衡如果还把请求打到坏节点，再好的算法也没用。健康检查要区分存活和可服务：端口能连上不代表服务健康，可能线程池满了、数据库连不上、错误率飙升。生产上常用主动探测、被动错误统计、熔断摘除结合。
恢复也不能瞬间打满。刚启动的节点缓存冷、JIT 未热、连接池未满，应该慢启动逐步放量，否则新节点会被流量压垮。
六、四层和七层负载均衡怎么区分
四层负载均衡工作在 TCP/UDP 层，按 IP、端口、连接转发，性能高，感知不到 HTTP 路径和 Header。七层负载均衡理解 HTTP/gRPC 等应用协议，可以按域名、路径、Header、Cookie 路由，也能做灰度、鉴权、限流，但性能开销更高。
面试里如果问 Nginx、LVS、网关，可以从四层/七层、性能/灵活性、连接级/请求级三个角度回答。
七、常见误区与追问
这道题不能只背概念，要把「负载均衡」放回真实分布式系统里解释：谁发起、谁协调、状态如何变化、失败后怎么兜底，以及它和性能、可用性、一致性的取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 负载均衡是在多个实例中选择一个处理请求，目标是分摊流量、提升可用性并避开异常节点 | 不要停在名词解释 |
| 流程机制 | 获取实例列表 -> 过滤不健康节点 -> 按轮询随机权重最少连接等策略选择 -> 发起调用 -> 根据失败和指标更新节点状态 | 说明触发方、参与方、状态变化和兜底 |
| 工程取舍 | 3 个实例权重 1:2:3 时，长期流量期望接近 16.7%、33.3%、50% | 分布式基础题不能只背概念，必须落到网络不可靠、节点会故障、数据有副本这些前提 |
负载均衡 面试拆解：
1. 获取实例列表
2. 过滤不健康节点
3. 按轮询随机权重最少连接等策略选择
4. 发起调用
5. 根据失败和指标更新节点状态记忆钩子：先定义问题，再说明一致性、可用性、分区、复制、时钟和故障模型的取舍；回答时要紧扣「负载均衡」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：轮询一定最公平。 实例性能和请求耗时不同，轮询可能让慢节点积压。
- 误区：负载均衡只看流量平均。 还要看可用性、延迟、错误率和实例权重。
- 误区：客户端和服务端负载均衡没有区别。 客户端本地选节点，服务端由代理统一转发，治理位置不同。
- 追问：常见算法有哪些？ 轮询、随机、加权、最少连接、一致性哈希、最小响应时间。
- 追问：一致性哈希适合什么场景？ 需要请求粘到同一节点、本地缓存命中率重要的场景。
- 追问：如何处理坏节点？ 健康检查、熔断、摘除、慢启动和重试。
八、加强记忆
负载均衡不是简单平均分流，而是让系统更高吞吐、更高可用、更易扩展。节点差不多用轮询/随机，性能不同用加权，请求耗时差异大用最少连接，需要同 key 稳定路由用一致性哈希。真正上线还要健康检查、故障摘除、慢启动和熔断，算法只是开始，治理才是关键。