什么是负载均衡，有哪些常见算法？

---

面试记录 2026-09-27

题目：什么是负载均衡，有哪些常见算法？

难度：medium

标签：arch/distributed/loadbalancing, general/knowledge

评分：⭐⭐⭐☆☆（3/5）

我的回答

负载均衡应该算是分布式下的一个内容，它映射的是将大量的请求，单机的请求拆分到多台机器上，通过一定的算法给不同的服务器分送请求。简单的说，负载均衡就是把一批资源均衡的分散给不同的机器，去进行处理，最终提高性能。常见的负载均衡算法有一致性哈希、取模、范围、随机、性能最佳、响应最佳、负载均衡，根据服务的状态去进行均衡的各种算法。

点评

优点：

• 概念清晰：单机 → 多机 → 算法分配
• 算法覆盖较全：取模、随机、一致性哈希、轮询（虽然没显式点名）都在里面
• 提到了"根据服务状态"这类动态算法

不足：

• 没有明确指出最常见的轮询（RoundRobin）和加权轮询——这是所有负载均衡的默认算法
• 算法名称和描述混杂：把"性能最佳、响应最佳、负载均衡"当算法列出来，其实它们是同义描述
• 没讲客户端 vs 服务端负载均衡：网关/LB（Nginx/LVS/HAProxy） vs 客户端（Ribbon/Spring Cloud LoadBalancer）
• 没讲一致性哈希的核心机制：虚拟节点、哈希环、节点扩缩容的影响（只有 N/K 的请求会重映射，而非全部）
• 没讲取模的问题：节点扩缩容会导致数据重新分布，是取模的死穴

补充：

• 经典 7 大算法：

1. 轮询（Round Robin）：默认算法
2. 加权轮询（Weighted Round Robin）：按机器配置权重
3. 随机（Random）：统计上均衡
4. 加权随机（Weighted Random）
5. 一致性哈希（Consistent Hashing）：扩缩容友好
6. 最短响应时间（Least Response Time）：按历史响应时间选
7. 最少活跃连接（Least Active/Busy Connections）：按并发选

• 两类负载均衡位置：
• 服务端 LB：LB（LVS/Nginx/HAProxy）/ K8s Service / SLB
• 客户端 LB：Ribbon / Spring Cloud LoadBalancer / Dubbo Consumer
• 一致性哈希细节：哈希环（0~2^32）+ 虚拟节点（一般 150 个/节点）→ 节点扩缩容时只影响 N/K 的请求

完整讲解

第一部分：知识重点剖析

核心考点定位：考察对负载均衡本质（分发流量提高可用性）和主流算法适用场景的理解。

知识点拆解：

1. 负载均衡三层：

• 网络层：LVS（四层）、F5（七层硬件）
• 应用层：Nginx、HAProxy（七层，HTTP/gRPC）
• 客户端：Ribbon、Spring Cloud LoadBalancer、Dubbo Consumer

1. 常见算法：

• 轮询：无状态无感知，机器同构时最简单
• 加权轮询：机器异构（8C16G vs 4C8G）时按权重分配
• 随机：数学上均衡，但短期可能有波动
• 一致性哈希：节点上下线只影响 N/K 请求，避免缓存击穿；配合虚拟节点避免数据倾斜
• 最少响应时间：适合机器性能差异大的场景
• 最少活跃连接：适合长连接、后端有队列的场景

1. 取模的问题：节点数变化时，几乎所有数据都要重新分布，不适合缓存场景
2. 一致性哈希原理：把所有节点映射到哈希环，请求也映射到环上顺时针取第一个节点；扩容时只影响新节点和邻居节点之间的请求

递进：先按"负载均衡位置"分（网络层/应用层/客户端），再按算法分（简单→复杂→动态）。

第二部分：考察方向与延伸递进

考察方向：

• 深度：一致性哈希的虚拟节点机制、取模在扩缩容时的重新分布问题
• 广度：与流量调度、Service Mesh（Istio sidecar）的关系
• 应用：不同业务场景选什么算法、Nginx upstream 配置、Dubbo 负载均衡配置

延伸递进面试题：

1. 一致性哈希如何解决数据倾斜？

• 解答要点：引入虚拟节点，每个真实节点在环上生成 100-200 个虚拟节点，让数据分布更均匀。扩容时新节点抢占原有虚拟节点的数据范围。

1. 取模在节点扩缩容时有什么问题？

• 解答要点：假设有 N 台机器，取模 N 分配；扩容到 N+1 后，几乎所有 key 的取模结果都变了，导致所有缓存失效、请求雪崩到后端。一致性哈希只影响 N/(N+1) 的请求。

1. 客户端 LB 和服务端 LB 有什么区别？

• 解答要点：客户端 LB 无第三方，性能高，但每个客户端都要实现；服务端 LB 集中在网关/LB，运维简单，但多一跳。Service Mesh（Istio）把客户端 LB 下沉到 sidecar。

1. Nginx 配置 upstream 时如何选算法？

• 解答要点：ip_hash 让同一 IP 命中同一后端（会话保持）；least_conn 最少连接；hash $uri 一致性哈希（Nginx 1.9.0+）；balance 是阿里云自研的一致性哈希。

第三部分：面试者参考回答（300-600 字口语化）

面试官您好，负载均衡是分布式系统里把流量分发到多个后端实例的机制，目的是提高吞吐、隐藏单点故障、支持水平扩展。

核心定义：通过算法把请求分给多台机器，让每台机器的负载接近。

位置分 3 层：

• 网络层：LVS（四层）、F5（七层硬件 LB）
• 应用层：Nginx、HAProxy（七层，支持 HTTP/gRPC）
• 客户端：Ribbon、Spring Cloud LoadBalancer、Dubbo Consumer

常见算法：

1. 轮询（Round Robin）：最简单，默认算法，同构机器时均衡性好；
2. 加权轮询：机器异构（8C16G vs 4C8G）时按权重分配，8C16G 权重 4，4C8G 权重 2；
3. 随机/加权随机：统计上均衡，实现简单；
4. 一致性哈希：节点扩缩容时只影响 N/K 的请求，避免缓存击穿，配合虚拟节点（一般 150 个/节点）避免数据倾斜；
5. 最短响应时间：按历史响应时间选，适合后端性能差异大；
6. 最少活跃连接：按当前并发数选，适合长连接、后端有队列的场景。

典型场景选型：

• 无状态 API 服务 → 轮询/随机最简单；
• 会话保持（登录后一直走同一台）→ 一致性哈希 + IP hash；
• 缓存场景（Redis 分片、Memcached）→ 一致性哈希，避免扩缩容全量失效；
• 机器性能差异大 → 加权轮询或最短响应时间；
• 有长连接后端（如 MQ Consumer）→ 最少活跃连接。

取模的坑：节点数变了几乎所有 key 都要重分，缓存全失效，所以缓存场景不用取模。