workerman多机部署需配置支持长连接会话保持的负载均衡器，推荐nginx（ip_hash或sticky cookie）或haproxy；若采用无状态方案，则必须依赖高可用redis集群实现状态同步与pub/sub广播，避免数据污染与连接中断。
Workerman多机部署时，负载均衡配置错误会导致用户连接反复断开、消息丢失、状态错乱，尤其在聊天室、在线游戏等强会话场景下，一次错误的转发就可能让玩家掉线或房间数据错位。
选对负载均衡器类型
必须使用支持长连接会话保持的四层或七层负载均衡器，禁用纯轮询LVS或未配置sticky的Nginx。LVS默认不感知TCP连接状态，Nginx若未启用ip_hash或cookie粘性，会把同一用户的WebSocket升级请求分发到不同后端，导致HTTP 101响应失败后连接直接中断。
推荐方案：Nginx（七层）或HAProxy（四层/七层），二者均能稳定维持长连接并提供灵活的会话保持策略。
配置Nginx实现连接粘性
方法一：基于客户端IP哈希（适用于公网IP稳定的场景）
在upstream块中添加ip_hash指令：【ip_hash必须放在upstream第一行，且不能与least_conn、hash等其他负载策略共存】
方法二：基于Cookie绑定（推荐，兼容NAT和移动端）
在upstream中加入sticky cookie配置：sticky cookie=workerman_sid expires=1h domain=.example.com path=/;
这一步操作起来很简单，直接把配置写进nginx.conf的upstream段就行。但要注意：WebSocket连接必须在首次HTTP握手时就携带该cookie，否则后续upgrade请求无法关联到同一后端实例。
方法三：彻底无状态+Redis兜底（适合广播类业务）
关闭所有会话保持，所有Workerman实例在onConnect时立即从Redis加载用户身份和房间信息；所有onMessage写入都带用户ID前缀，并通过Redis Pub/Sub广播给其他机房实例。此时负载均衡可使用最简轮询，但【Redis必须是跨机房高可用集群，单点Redis写入将成致命瓶颈】。
验证连接不丢的关键检查项
第一步：确认客户端建立连接后，连续发送3次心跳包，观察是否始终由同一台Workerman服务器响应；
第二步：手动kill掉当前服务节点的Worker进程，等待30秒，检查客户端是否自动重连且被路由回原节点（需DNS健康探测生效）；
第三步：抓包验证TCP连接五元组（源IP:端口→目标IP:端口）在整个会话周期内未发生变化；
第四步：登录Redis，执行KEYS "user:*"，确认用户状态键只在一个机房的Redis分片中存在——若跨分片重复出现，说明状态同步逻辑有误，连接虽未丢，但数据已污染。
