--- tags: [test/review, architecture, arch/microservice, load-balancing] create time: 2026-08-09 12:00 --- # 负载均衡算法 — 测试题 ## 概述 本测试覆盖客户端 vs 服务端负载均衡架构、轮询/随机/一致性哈希/最少连接等核心算法、Spring Cloud LoadBalancer 实现原理以及加权轮询的工程实现。共 10 道题目（6 选择 + 3 填空 + 1 简答）。 --- ## 一、选择题（6道，由浅入深） > **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景 ### Q1（基础）— 考察定义层面 以下关于客户端负载均衡与服务端负载均衡的说法中，正确的是： A. 客户端负载均衡延迟更高，因为多了一次网络跳 B. 服务端负载均衡的故障隔离更好——LB 单点故障不影响其他调用 C. 客户端负载均衡需要为每种语言实现 SDK，服务端 LB 协议无关 D. Nginx 是客户端负载均衡的典型代表 ### Q2（基础）→ 以下哪种负载均衡算法最适合 WebSocket 长连接场景？ A. 简单轮询（Round Robin） B. 随机法 C. 最少连接数（Least Connections） D. 一致性哈希 ### Q3（进阶）— 核心原理 传统哈希 `hash(instance) % n` 在实例增减时为什么会导致大量请求重新路由？ A. 因为 hash 函数的不均匀性 B. 因为 n 变化后所有 hash 结果对新的 n 取模都变了 C. 因为虚拟节点数量不足 D. 因为 MurmurHash 本身不适合负载均衡 ### Q4（进阶）— 比较/辨析 一致性哈希中虚拟节点的主要作用是什么？ A. 提高 hash 值的随机性 B. 解决数据倾斜问题，使物理实例在环上分布更均匀 C. 增加系统容错能力，某节点挂了可以立即接替 D. 减少 hash 冲突的概率 ### Q5（深入）— 场景推理 一个微服务有 5 个实例，权重分别为 A=5、B=3、C=2、D=1、E=1（总权重 12）。使用平滑加权轮询算法，第一个被选中的实例一定是： A. B（权重 3） B. C（权重 2） C. A（权重 5） D. 无法确定，取决于初始 current_weight ### Q6（深入）— 源码级/边界场景 关于 Spring Cloud LoadBalancer，以下说法哪个是正确的？ A. 它内置了重试和熔断能力 B. 基于 Reactor 响应式编程，返回 Flux C. 默认使用一致性哈希算法 D. 只支持 HTTP 协议的实例选择 --- ## 二、填空题（3道） ### F1 — 填空1 一致性哈希将 hash 值空间映射到环上（0 ~ _____），服务和请求都 hash 到环上的同一点，请求顺时针找到最近的实例。移除一个实例只影响其相邻的两个虚拟节点范围，而非全部数据。 > **提示**: 回忆原文中提到的一致性哈希环的范围上限。 ### F2 — 填空2 一致性哈希中，每个物理实例对应的虚拟节点数 k 通常取 _____~_____。如果实例频繁增删（每几分钟变一次），k 要调得更大（500+）才能维持稳定性，但会增加内存开销。 > **提示**: 原文中有一个具体的数值范围。 ### F3 — 填空3 Nginx 的 smooth weighted round robin 算法中，每次选出 current_weight 最大的实例后，执行 `selected.CurWeight -= _____`，保证长期均衡。 > **提示**: 减去的应该是总权重，这样每个实例的 CurWeight 会在一个周期内回到初始状态。 --- ## 三、简答题（1道） ### S1 某电商大促场景中，你有 10 个商品推荐服务实例，其中 3 台是高性能机器（容量大），7 台是普通机器（容量小）。流量高峰时要求充分利用高性能机器的资源。请说明你会选用哪种负载均衡算法，如何配置参数，并解释为什么不用简单轮询或随机法。 > **答题框架提示**: > 1. 分析场景的核心矛盾（规格差异） > 2. 推荐算法并说明理由 > 3. 给出具体配置思路 > 4. 讨论边界情况 --- ## 参考答案与解析 ### 选择题答案 | 题号 | 正确答案 | 解析 | |------|---------|------| | Q1 | C | A 错：客户端 LB 少一次网络跳所以延迟低；B 错：LB 单点故障影响全部请求，故障隔离差；D 错：Nginx 是服务端 LB。只有 C 正确——客户端 LB 需要各语言的 SDK（如 Spring Cloud LoadBalancer for Java）。 | | Q2 | C | WebSocket 长连接场景下不同连接的持续时间差异大，最少连接数能保证新请求发给当前活跃连接最少的实例，避免某个实例堆积大量长连接而其他实例闲置。 | | Q3 | B | 当实例数从 n 变为 n±1 时，几乎所有 key 的 hash(key) % new_n 都会不同于原来的结果，导致约 (n-1)/n 的数据需要迁移。这就是一致性哈希要解决的问题。 | | Q4 | B | 如果不使用虚拟节点，少数几个物理实例在环上的分布会很不均匀，造成严重的数据倾斜。K=100~200 个虚拟节点让分布趋近均匀。 | | Q5 | C | 平滑加权轮询第一轮时所有实例的 CurWeight = 0，加上各自 Weight 后 A 的 CurWeight = 5 最大，所以第一轮一定选 A。之后 A 减 12 变为 -7，其他依次加完再选。 | | Q6 | B | Spring Cloud LoadBalancer 基于 Reactor，返回 Flux。它**不提供**重试和熔断（那是 Resilience4j 的职责），默认策略是 RoundRobinLocator（轮询），不是哈希。 | ### 填空题答案 | 题号 | 答案 | 解析 | |------|------|------| | F1 | `2^32`（或"4294967296"） | 一致性哈希将 32 位 hash 空间映射为环形地址空间，首尾相接。顺时针寻找最近实例的逻辑确保了实例增减时的最小影响范围。 | | F2 | `100`；`200` | 这是业界经验值。太少了分布不均，太多了内存占用大且维护代价高。频繁增删场景需要 500+ 的虚拟节点数。 | | F3 | `totalW`（或"总权重 total_weight"） | Nginx 的平滑加权轮询核心公式：cur += weight（累积），选 max 后 selected -= total。这样经过一个完整周期，每个实例被选中的次数恰好等于它的权重占比。 | ### 简答题参考答案 S1：**参考答案要点**： 1. **核心矛盾**：性能差异大的实例不能用简单轮询——每台都会被分到相同数量的请求，导致弱机过载而强机资源浪费。 2. **推荐算法**：加权轮询（Weighted Round Robin）。将 3 台高性能机的权重设为普通机的若干倍（如 3:1 或根据实测 QPS 计算比例），使得长期来看请求按容量比例分配。 3. **不选简单的理由**：简单轮询无视容量差异；随机法在小样本下可能极端不均（连续命中同一个弱机），大促场景不能接受这种不确定性。 4. **边界处理**：需要考虑实例下线时的权重动态调整（Hot Restart 机制）、健康检查剔除故障实例后的自动重新加权。 **评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。 ## 关联笔记 - [[服务注册与发现]] - [[限流熔断降级]]