轮询调度算法按配置顺序循环分发请求，第1个请求给第1台服务器、第2个给第2台……第n+1个回到第1台，指针无状态自动下移并跳过不可用节点；它不保证响应时序，仅决定请求分发目标，适合同构、无状态、请求耗时均衡的场景。
轮询调度本身不改变请求的逻辑顺序，它只决定“哪个请求发给哪台服务器”，而所有请求在客户端发起和响应返回时仍保持原有时间先后关系。真正影响你感知到的“顺序”的，是后端处理能力、网络延迟和健康检查机制，不是轮询算法本身。
轮询如何确定每请求的分发目标
轮询靠一个内部指针按配置顺序逐台“点名”：第1个请求→第1台 server，第2个→第2台，……第n个→第n台，第n+1个→回到第1台。这个过程无状态、无计算开销，也不看响应快慢或连接数多少，纯粹依据配置列表位置和当前指针偏移量。
- 指针在每次请求完成分发后自动下移，到末尾即归零，形成闭环
- 重启 Nginx 后指针重置为 0，但运行中会持续跳过被标记为不可用的节点
- 没有“排队等待”或“缓存重排”，每个请求独立决策，即时生效
为什么你可能觉得请求“乱序”了
看起来顺序异常，往往不是轮询出了问题，而是后端响应节奏不一致导致的观察偏差。比如 server A 处理一个请求要 500ms，server B 只需 50ms，那么第2个发给 B 的请求可能比第1个发给 A 的还早返回——这属于正常现象，轮询不保证响应时序。
- 某台 server 配了 weight 参数：立刻切换为加权轮询，原始顺序被打破
- 启用了 ip_hash 或 hash $request_uri：相同特征请求被固定路由，轮询失效
- 某台 server 因 max_fails 触发临时摘除：轮询队列变短，后续请求在剩余节点间循环，造成局部密度上升
验证和控制请求分发顺序的方法
想确认实际分发是否符合预期，最直接的方式是查日志，而不是凭响应时间判断。
- 在 location 块中启用 access_log，并使用 $upstream_addr 记录真实转发目标
- 确保 upstream 块里没有任何 weight、ip_hash、least_conn 等干扰指令
- 统一各 server 行的健康探测参数（如 max_fails=2 fail_timeout=15s），避免因探测松紧不一导致节点进出不一致
轮询适合什么场景，不适合什么
它天然适配无状态、处理耗时相近、扩容节奏稳定的后端集群。不适合强会话依赖、性能差异大、或需要按响应速度动态调优的场景。
- 适合：静态资源服务、API 网关初期灰度、同构容器组（如 K8s Deployment）
- 不适合：长连接网关、CPU 密集型任务混合部署、需严格会话保持的登录态服务
- 进阶替代：若需响应更快的节点多承接，应改用 least_conn；若需用户会话粘性，ip_hash 是更轻量的选择
