一、基础内置策略（最常用）
表格
|----------------------|----------------------------------------------------------------------------|---------------------------------------|----------------------|
| 策略 | 配置示例 | 核心原理 | 适用场景 |
| 轮询（默认） | upstream backend { server 192.168.1.1; server 192.168.1.2; } | 按时间顺序，依次将请求分配给后端服务器；故障节点会被自动剔除。 | 后端服务器性能相近、无状态短请求场景。 |
| 加权轮询 | server 192.168.1.1 weight=3; server 192.168.1.2 weight=1; | 在轮询基础上，通过 weight 配置分配比例，权重越高接收请求越多。 | 后端服务器性能不均，需要差异化分配负载。 |
| ip_hash | upstream backend { ip_hash; server 192.168.1.1; server 192.168.1.2; } | 基于客户端 IP 哈希计算，将同一 IP 的请求固定分配到同一后端服务器。 | 需要会话保持的场景（如登录态、购物车）。 |
| least_conn（最少连接） | upstream backend { least_conn; server 192.168.1.1; server 192.168.1.2; } | 将请求分配给当前活跃连接数最少的后端服务器。 | 后端请求耗时差异大，需要避免服务器过载。 |
二、其他常用策略
- 通用哈希（hash） 可自定义哈希键（如请求 URL、请求参数），实现基于请求内容的会话保持，比
ip_hash更灵活。 - **一致性哈希（consistent_hash）**适合缓存服务场景，后端节点增减时，仅少量缓存失效，大幅降低缓存穿透风险。
- **least_time（Nginx Plus 支持）**优先分配给响应时间最短的后端服务器，适合对延迟敏感的业务场景。
三、关键补充说明
- 权重策略本质 ：是轮询的增强版，并非独立算法，配置时直接在
server指令后加weight参数即可。 - ip_hash 注意事项 ：后端服务器故障剔除后，请求会重新哈希分配；若需永久会话保持，可结合
sticky第三方模块。 - 故障容错：所有内置策略都支持健康检查，故障节点会被自动从分发列表中移除，恢复后自动加入。