轮询算法本身无状态感知能力，其平滑上下线依赖nginx的配置控制（weight=0/down）、健康检查（http探活+503联动）、连接管理（draining调优）及后端主动配合（停入口、等连接归零）协同实现。
轮询算法本身不带状态感知能力，平滑上下线靠的是 Nginx 的配套机制协同实现——不是轮询自己“变聪明”，而是通过配置控制、健康检查和连接管理共同保障请求不丢、连接不断。
主动控制流量入口：weight=0 或 down 标记
这是最直接、最可控的下线方式，无需等待探测或失败重试：
- 将待下线节点设为 weight=0，Nginx 立即停止分发新请求，但已建立的连接仍可正常收发
- 使用 down 参数（如
server 10.0.0.5:8080 down;），尤其适合 ip_hash 场景，哈希计算会自动跳过该节点 - 修改后执行
nginx -s reload即可生效；若用 dyups 或 nginx-upsync-module，还能免 reload 动态更新 upstream
自动识别异常：健康检查 + 状态联动
仅靠手动标记不够灵活，需让 Nginx 主动感知后端退出意图：
- 启用
nginx_upstream_check_module（需编译时加入），配置 HTTP 探活：check interval=3 rise=2 fall=3 timeout=1 type=http; - 后端下线前，将
/health接口返回 503，触发 fall 计数，Nginx 在连续失败后自动标记节点为不可用 - 搭配
proxy_next_upstream error timeout http_503;，确保请求打到异常节点时能自动重试其他可用节点
保障已有连接完成：draining 参数调优
摘流只是开始，真正零丢失取决于是否给后端留足处理时间：
- 设置 proxy_read_timeout 为业务最长响应时间（如 90 秒），避免 Nginx 提前中断正在处理的请求
- 开启 proxy_ignore_client_abort on，防止用户关闭页面导致 Nginx 中断后端仍在运行的任务
- 启用 proxy_http_version 1.1 和 proxy_set_header Connection "keep-alive"，支持连接复用，减少重建开销
后端配合退出节奏：停入口、等连接归零
Nginx 是被动协调者，后端必须主动配合才能闭环：
- 下线前先关闭新请求入口：Spring Boot 可调
/actuator/refresh或停 Tomcat connector；Netty 可 shutdown EventLoopGroup - 保持已有连接可读写，等待活跃连接自然关闭；可通过
stub_status监控 Active connections 是否降为 0 - 确认无活跃连接后再终止进程，避免强制 kill 导致请求中断
