负载均衡与路由

microservice 📚 learning load-balancing · microservice · load-balancing · round-robin · consistent-hash · nginx · ribbon · service-mesh

TL;DR（30 秒扫完）

  • 位置 3 层：网络层（LVS/F5）+ 应用层（Nginx/HAProxy）+ 客户端（Ribbon/LoadBalancer/Dubbo Consumer）
  • 7 大算法：轮询 / 加权轮询 / 随机 / 加权随机 / 一致性哈希 / 最短响应时间 / 最少活跃连接
  • 取模死穴：节点扩缩容导致几乎所有 key 重分，缓存全失效——不适合缓存场景
  • 一致性哈希：哈希环 + 虚拟节点，扩缩容只影响 N/K 请求，避免缓存击穿

关键结论

结论 A客户端 LB 和 服务端 LB 是不同位置，各有优劣——不是替代关系
结论 B轮询（Round Robin）和加权轮询是默认算法，简单且均衡
结论 C一致性哈希 + 虚拟节点是缓存分片场景的关键，取模不适合扩缩容频繁的系统
结论 D一致性哈希本质是"哈希环 + 顺时针取第一个节点 + 虚拟节点解决数据倾斜"

完整讲解（费曼四步）

STEP 1 · 概念

负载均衡（Load Balancing）是把网络流量分发到多个后端实例的机制，目的是提高吞吐、隐藏单点故障、支持水平扩展。

STEP 2 · 大白话

类比餐厅排队：多开几台窗口（后端实例），叫号员（负载均衡器）按策略分客人（请求）——保证每个窗口都不空转、客人平均等待时间最短。

STEP 3 · 底层

3 层位置：
层级代表特点
网络层（L4）LVS、F5快但只看 IP+端口，不支持 HTTP 特性
应用层（L7）Nginx、HAProxy支持 HTTP/gRPC，可看请求头/路径
客户端Ribbon、Spring Cloud LoadBalancer、Dubbo Consumer无第三方、性能高，但每个客户端要实现
7 大经典算法：
算法特点适用场景
轮询（Round Robin）最简单、默认算法同构机器
加权轮询按权重分配异构机器（8C16G vs 4C8G）
随机 / 加权随机统计上均衡，短期有波动简单场景
一致性哈希扩缩容只影响 N/K 请求缓存分片、会话保持
最短响应时间按历史响应时间选后端性能差异大
最少活跃连接按并发数选长连接后端（MQ Consumer）
取模的死穴：假设有 N 台机器，取模 N 分配；扩容到 N+1 后，几乎所有 key 的取模结果都变了，导致所有缓存失效、请求雪崩到后端。 一致性哈希原理：
  • 哈希环（0~2^32）
  • 所有节点映射到环上（顺时针）
  • 请求也映射到环上，顺时针取第一个节点
  • 扩容时新节点抢占原有虚拟节点的数据范围
  • 虚拟节点（一般 150 个/节点）避免数据倾斜：每真实节点在环上生成 100-200 个虚拟节点，让数据分布更均匀
典型场景选型：
  • 无状态 API 服务 → 轮询/随机最简单
  • 会话保持（登录后一直走同一台）→ 一致性哈希 + IP hash
  • 缓存场景（Redis 分片、Memcached）→ 一致性哈希，避免扩缩容全量失效
  • 机器性能差异大 → 加权轮询或最短响应时间
  • 有长连接后端（如 MQ Consumer）→ 最少活跃连接
Nginx upstream 配置常见算法：
  • ip_hash：同一 IP 命中同一后端（会话保持）
  • least_conn：最少连接
  • hash $uri：一致性哈希（Nginx 1.9.0+）
  • balance：阿里云自研的一致性哈希

STEP 4 · 简化

口诀：3 层位置（网络/应用/客户端）+ 7 种算法；缓存场景用一致性哈希+虚拟节点；取模不适合扩缩容。

常见误区

只列"取模、范围、随机、一致性哈希"，没明确轮询/加权轮询
轮询和加权轮询是默认算法，所有 LB 都支持
把"性能最佳、响应最佳、负载均衡"当算法名
这些是描述词，不是具体算法
没区分客户端 LB 和服务端 LB
客户端 LB（Ribbon）无第三方但每个客户端要实现；服务端 LB（Nginx）集中但多一跳

延伸追问

一致性哈希如何解决数据倾斜？
要点：引入虚拟节点，每个真实节点在环上生成 100-200 个虚拟节点，让数据分布更均匀。扩容时新节点抢占原有虚拟节点的数据范围。
取模在节点扩缩容时有什么问题？
要点：节点数变了几乎所有 key 都要重分，缓存全失效，所以缓存场景不用取模。
客户端 LB 和服务端 LB 有什么区别？
要点：客户端 LB 无第三方，性能高，但每个客户端都要实现；服务端 LB 集中在网关/LB，运维简单，但多一跳。Service Mesh（Istio）把客户端 LB 下沉到 sidecar。
Nginx 配置 upstream 时如何选算法？
要点：ip_hash 让同一 IP 命中同一后端（会话保持）；least_conn 最少连接；hash $uri 一致性哈希（Nginx 1.9.0+）；balance 是阿里云自研的一致性哈希。

速查表

3 层位置：网络层（LVS/F5）/ 应用层（Nginx/HAProxy）/ 客户端（Ribbon/LoadBalancer/Dubbo）
7 大算法：轮询 / 加权轮询 / 随机 / 加权随机 / 一致性哈希 / 最短响应时间 / 最少活跃连接
一致性哈希：哈希环 + 顺时针 + 虚拟节点（150/节点）
取模死穴：扩缩容导致所有 key 重分，缓存全失效
典型场景：无状态→轮询；会话保持→一致性哈希+IP hash；缓存→一致性哈希；异构→加权；长连接→最少活跃连接
Nginx upstream：ip_hash / least_conn / hash $uri / balance

Anki 候选卡片

Q: 负载均衡 3 层位置？
A: 网络层（LVS/F5）+ 应用层（Nginx/HAProxy）+ 客户端（Ribbon/Spring Cloud LoadBalancer/Dubbo Consumer）
Q: 负载均衡 7 大经典算法？
A: 轮询 / 加权轮询 / 随机 / 加权随机 / 一致性哈希 / 最短响应时间 / 最少活跃连接
Q: 取模在扩缩容时的问题？
A: 节点数变了几乎所有 key 都要重分，导致缓存全失效，不适合缓存场景
Q: 一致性哈希原理？
A: 哈希环（0~2^32）+ 节点映射到环 + 请求顺时针取第一个节点；扩缩容只影响 N/K 请求
Q: 一致性哈希如何解决数据倾斜？
A: 引入虚拟节点，每个真实节点在环上生成 100-200 个虚拟节点，让数据分布更均匀
Q: 客户端 LB 和服务端 LB 区别？
A: 客户端 LB 无第三方但每个客户端要实现；服务端 LB 集中但多一跳；Service Mesh 把客户端 LB 下沉到 sidecar

关联题目

  • [x] 《什么是负载均衡，有哪些常见算法？》—— 2026-09-27 Round 1 Q7, 评分 ⭐⭐⭐

    • 关联知识

    3 层位置 + 7 大算法；一致性哈希+虚拟节点解决数据倾斜
    ✦ 记 忆 口 诀 ✦
    3 层位置 / 7 算法 / 一致性哈希避雪崩
    关键可视化
    暂无可视化
    知识关系

    ⬆️ 前置（Prerequisite）

    暂无

    🔄 延伸（Extends）

    暂无

    ⚡ 对比（Contrast）

    暂无
    🎯 概念 📏 规则 ⚠️ 误区 🔍 追问 ✨ 口诀 共 0 张卡，点击翻面