轮询是nginx默认负载均衡策略，按顺序依次将请求分发至后端服务器，配置只需在upstream块中列出server地址，无需额外参数；适用于性能相近、无状态场景，支持max_fails/fail_timeout实现基础故障隔离。
轮询是 Nginx 默认的负载均衡策略，无需额外声明即可生效，核心在于按顺序把请求依次分发到后端服务器。它简单、公平、易验证，适合后端节点性能相近、无状态业务场景。
轮询的基本配置写法
只需在 upstream 块中列出后端地址，不加任何参数，Nginx 就自动启用轮询：
- 每个 server 指令代表一个后端节点，支持 IP + 端口（如
192.168.1.101:8080） - 默认权重为 1，所有节点被等比例轮转调度
- 配置示例：
http {
upstream backend {
server 192.168.1.101:80;
server 192.168.1.102:80;
server 192.168.1.103:80;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
轮询的健康保障机制
轮询本身不主动探测服务可用性，但可通过参数实现基础故障隔离：
- max_fails：连续失败多少次后标记该节点为不可用
- fail_timeout：失效状态持续多久（秒），超时后重新尝试连接
- 例如：
server 192.168.1.101:80 max_fails=3 fail_timeout=30s; - 注意：该机制基于 TCP 连接层面，若需 HTTP 层健康检查（如返回 200 才算存活），需配合第三方模块或外部监控
轮询的实际效果验证方式
部署后可通过轻量方法确认请求是否真正按序分发：
- 用
curl连续发起多次请求，观察响应内容（如后端返回不同 server 标识） - 查看各后端服务器的访问日志，确认 IP 和时间戳呈规律交替
- 使用
ab -n 30 -c 5 http://nginx-ip/发起小规模压测，统计各节点接收请求数是否接近 1:1:1 - 注意：浏览器可能因缓存或 Keep-Alive 复用连接，建议用 curl 或 ab 工具绕过干扰
轮询适用与慎用边界
轮询不是万能解法，需结合业务特点判断是否合适：
- 适合：静态资源服务、无状态 API、节点配置和负载高度一致的集群
- 慎用：后端处理耗时差异大（如有的接口要 100ms，有的要 2s），会导致部分节点积压连接
- 慎用：需要用户会话保持（如登录态、购物车），此时应改用 ip_hash 或引入 Redis 共享 session
- 若发现某节点响应明显变慢，即使未宕机，也建议临时调低其权重或切换为加权轮询
