轮询是nginx默认负载均衡策略,按顺序循环分配请求至后端服务器,适用于性能均等、无需会话保持的场景;加权轮询通过weight参数按能力分配流量,适配异构服务器;ip哈希则基于客户端ip固定路由,解决会话粘滞问题。

轮询:最简默认策略,适合同构服务器
轮询是 Nginx 的默认负载均衡算法,无需额外配置即可启用。它按顺序把请求逐一分发给 upstream 块中定义的每台后端服务器,循环往复。比如三台服务器 A、B、C,请求依次落到 A→B→C→A→B……这样分配天然均匀,实现简单、开销极低。
它的关键特点是“静态”和“无状态”:不感知服务器当前连接数、响应时间或资源占用。只要服务器在线,就参与轮询;一旦某台宕机,Nginx 会根据 max_fails 和 fail_timeout 自动临时剔除,故障恢复后自动重新加入调度队列。
适用场景包括:
- 后端服务器硬件配置、部署环境完全一致
- 服务响应时间较稳定,无明显长尾延迟
- 对会话保持无要求(如纯 API 接口、静态资源)
加权轮询:按能力分配流量,应对性能差异
当集群中服务器性能不均(如 CPU、内存、磁盘 I/O 差异大),直接轮询会导致强机“吃不饱”、弱机“扛不住”。加权轮询通过 weight 参数为每台服务器显式指定权重,默认为 1。Nginx 按权重比例分配请求,例如:
upstream backend {
server 192.168.1.10 weight=3;
server 192.168.1.11 weight=5;
server 192.168.1.12 weight=2;
}
该配置下,三台服务器理论请求占比约为 30%、50%、20%。注意:权重不是绝对请求数,而是概率倾向;实际调度仍保持平滑轮询节奏,避免突发集中打到高权值节点。
使用建议:
- 权重值建议设为整数,便于估算和维护
- 避免权重悬殊过大(如 1:100),否则低权值节点可能长期闲置
- 配合健康检查使用,防止权重再高也压垮已故障节点
IP 哈希:固定客户端路由,解决会话粘滞问题
IP 哈希算法对客户端源 IP 地址做哈希运算,并根据结果将请求始终转发至同一台后端服务器。配置只需在 upstream 块中添加 ip_hash; 指令:
upstream backend {
ip_hash;
server 192.168.1.10;
server 192.168.1.11;
}
这种机制天然实现会话保持(session stickiness),适用于未引入共享 Session 存储(如 Redis)的传统 Web 应用,比如依赖本地 Cookie 或内存 Session 的 PHP/Java 项目。
但要注意局限性:
- 若客户端大量来自同一出口 IP(如企业 NAT、运营商网关),会造成单台后端过载
- 服务器扩容或缩容时,哈希映射关系整体变动,可能导致大量用户会话中断
- 不支持权重设置(Nginx 会忽略 weight 参数)
选型关键看三点:一致性、动态性、业务约束
轮询适合简单均匀场景;加权轮询补足硬件差异;IP 哈希解决无共享状态的会话问题。实际选型不能只看算法名字,要结合三个维度判断:
- 一致性需求:是否要求同一用户多次请求落在同一节点?有则优先考虑 IP 哈希或通用哈希
- 动态适应性:请求耗时波动大、连接生命周期不一?最少连接(least_conn)比轮询更稳
- 基础设施约束:后端是否具备 Session 共享能力?没有的话,IP 哈希仍是务实选择
不复杂但容易忽略。











