轮询必须搭配无状态后端，因为它按固定顺序分发请求且不绑定会话，若后端有本地状态（如内存中的session），会导致会话漂移、登录失效、购物车丢失等问题；解决方式包括Session外存、JWT认证、幂等设计等，否则需改用ip_hash等粘性策略。
轮询机制本身不关心业务逻辑，但它要求后端服务必须是无状态的，否则请求被分发到不同节点时会出现数据不一致、会话丢失或重复处理等问题。它不是“支持”无状态，而是“依赖”无状态才能正常工作。
为什么轮询必须搭配无状态后端
轮询按固定顺序把请求打到不同服务器，不记录请求来源、不绑定会话、不感知业务上下文。如果后端有状态（比如 session 存在本地内存、用户登录态只保留在某台机器上），那么第二次请求落到另一台机器时，就找不到上下文，导致登录失效、购物车为空、操作失败等典型问题。
- 用户第一次请求被轮到 server-A，登录成功，session 写在 A 的内存里
- 第二次请求轮到 server-B，B 没有该 session，判定未登录，强制跳转登录页
- 这种“会话漂移”不是轮询的 bug，而是它与有状态设计的根本冲突
无状态的常见落地方式
要让轮询真正可用，后端需主动剥离状态，把关键数据外置或标准化：
- Session 外存：用 Redis 或数据库统一存储 session，所有后端节点共享读写
- Token 化认证：用 JWT 等自包含 token，服务端无需查 session，验证即可放行
- 请求幂等 + 状态由客户端携带：如订单创建带唯一 trace_id，后端根据 id 去 DB 查重，避免重复下单
- 静态资源与 API 分离：前端直接对接 CDN 或对象存储，API 层只做纯计算，不存临时状态
轮询下有状态场景的替代方案
如果业务暂时无法改造为无状态（如遗留系统、强事务依赖），轮询就不合适，应换其他策略：
- ip_hash：同一 IP 固定打到同一台后端，保证会话粘性（但存在单点风险、NAT 下失效）
- cookie_hash（sticky session）：Nginx 插件或商业版支持，用 cookie 标识后端节点
- 应用层路由：在业务代码中解析请求特征（如 user_id 取模），主动转发到指定节点
配套配置强化无状态前提
即使后端已无状态，Nginx 配置不当也会破坏效果：
- 禁用 proxy_buffering off 或长连接未开启，可能引发响应体截断，间接导致业务误判状态
- 没配 keepalive 和 proxy_http_version 1.1，频繁建连会放大后端状态恢复开销
- 健康检查缺失，故障节点仍参与轮询，请求失败后重试可能触发重复提交（看似“状态混乱”）
