一、内置基础算法
这些算法无需额外模块，默认集成在 Nginx 中，通过 upstream 模块配置即可使用。
1. 轮询（Round Robin）rr
原理：默认调度算法，将请求按顺序轮流分配到不同的后端服务器（逐个分发，循环往复）。
特点：
简单直观，无需额外配置。
假设所有后端服务器性能相同，适合服务器硬件配置一致的场景。
不考虑服务器负载、响应时间等实时状态。
适用场景：后端服务器性能均衡、无特殊会话需求的普通 Web 服务（如静态资源服务、API 接口等）。
配置示例：
nginx
upstream backend {
server 192.168.1.101; # 后端服务器1
server 192.168.1.102; # 后端服务器2
server 192.168.1.103; # 后端服务器3
}
调度效果：请求顺序为 101 → 102 → 103 → 101 → 102 → 103 → ...。
注意：若某台服务器故障（如超时、返回错误码），Nginx 会自动将其暂时排除，故障恢复后重新加入轮询。
2. 加权轮询（Weighted Round Robin）
原理：在轮询基础上，为后端服务器分配权重（weight 参数），权重越高的服务器接收的请求越多（权重比 = 请求数量比）。
特点：
可根据服务器性能差异调整权重（性能强的服务器权重高，承担更多请求）。
权重默认值为 1，权重为 0 的服务器不参与分配。
适用场景：后端服务器硬件配置不一致（如部分服务器 CPU / 内存更强），需按性能分配负载。
配置示例：
nginx
upstream backend {
server 192.168.1.101 weight=3; # 权重3，接收3/6的请求
server 192.168.1.102 weight=2; # 权重2，接收2/6的请求
server 192.168.1.103 weight=1; # 权重1，接收1/6的请求
}
调度效果：请求分配比例为 101:102:103 = 3:2:1（如顺序为 101→101→101→102→102→103，循环重复）。
3. IP 哈希（IP Hash）
原理：根据客户端的 IP 地址计算哈希值，将同一客户端的请求始终分配到同一台后端服务器（哈希值固定，
映射的服务器固定）。
特点：
实现会话保持（Session Sticky）：适合需要保存客户端状态的场景（如用户登录状态、购物车数据等）。
哈希计算基于客户端 IP（IPv4 的前 3 段或完整 IPv6 地址），避免因客户端 IP 微小变化（如动态 IP）
导致映射变化。
适用场景：需要保持会话一致性的服务（如电商网站、后台管理系统）。
配置示例：
nginx
upstream backend {
ip_hash; # 启用IP哈希算法
server 192.168.1.101;
server 192.168.1.102;
}
注意：
若后端服务器故障，需手动下线（down 标记），否则哈希映射会重新计算，导致会话丢失。
不适合客户端 IP 集中的场景（如同一局域网内的大量用户，可能导致某台服务器负载过高）。
4. 最少连接（Least Connections）
原理：优先将请求分配给当前连接数最少的后端服务器（实时监控服务器连接数，动态调整分配）。
特点：
考虑服务器的实时负载（连接数越少，说明越空闲），避免某台服务器因连接堆积过载。
适合请求处理时间差异较大的场景（如部分请求耗时久，导致服务器连接数偏高）。
适用场景：请求处理时间不稳定的服务（如复杂查询、文件上传下载）。
配置示例：
nginx
upstream backend {
least_conn; # 启用最少连接算法
server 192.168.1.101;
server 192.168.1.102;
}
扩展：可结合权重使用（weight），此时计算 “加权最少连接”（连接数 / 权重的值越小，优先级越高），兼顾性能差异。
二、扩展算法（需第三方模块）
部分高级算法需要通过额外模块（如 ngx_http_upstream_fair_module、nginx-upstream-consistent-hash 等）实现，需手动编译模块到 Nginx 中。
1. fair 算法
原理：根据后端服务器的响应时间（处理请求的快慢）分配请求，响应时间越短的服务器优先接收请求。
特点：
基于服务器实时响应速度动态调度，更贴合 “负载均衡” 的本质（响应快的服务器处理更多请求）。
需安装第三方模块 ngx_http_upstream_fair_module（Nginx 官方不自带）。
配置示例：
nginx
upstream backend {
fair; # 启用fair算法
server 192.168.1.101;
server 192.168.1.102;
}
2. 一致性哈希（Consistent Hash）
原理：通过哈希算法将客户端请求和后端服务器映射到同一个哈希环上，请求根据哈希值顺时针映射到最近的服务器。
特点：
当后端服务器新增或下线时，只有少量请求会被重新分配（哈希环扰动小），适合缓存服务（如 Redis 集群）的负载均衡。
可结合权重调整服务器在哈希环上的 “节点数量”（权重越高，节点越多，分配的请求越多）。
适用场景：分布式缓存、分布式存储等需要减少服务器变动影响的场景。
配置示例（需安装 nginx-upstream-consistent-hash 模块）：
nginx
upstream backend {
consistent_hash $request_uri; # 基于请求URI计算哈希
server 192.168.1.101 weight=3;
server 192.168.1.102 weight=2;
}
哈希键可自定义（如 $request_uri 基于请求路径，$remote_addr 基于客户端 IP）。
三、算法选择建议
场景需求 推荐算法 理由
服务器性能一致，无特殊需求 轮询（默认） 简单高效，分发均匀。
服务器性能差异大 加权轮询 按权重分配请求，性能强的服务器承担更多负载。
需要会话保持（如登录状态） IP 哈希 同一客户端请求固定到一台服务器，避免会话丢失。
请求处理时间差异大 最少连接 动态分配请求到空闲服务器，避免某台服务器过载。
缓存服务（如 Redis 集群） 一致性哈希 服务器上下线时，减少缓存失效范围，降低服务波动。
关注响应速度优化 fair 算法 优先分配给响应快的服务器，提升整体用户体验（需额外模块支持）。
四、总结
Nginx 负载均衡算法覆盖了从简单到复杂的场景，核心是通过 upstream 模块配置，结合 server 指令的 weight等参数调整行为。实际使用中，需根据后端服务器特性、业务对会话性能的要求，选择最合适的算法，必要时可通过第三方模块扩展功能。
评论 (0)