Workerman本身不支持双机热备，必须依赖外部组件实现：需配置负载均衡器（启用会话保持或确保无状态）、Redis集群跨机房高可用（3主3从+Cluster模式）、跨机房消息中继（RabbitMQ镜像队列或Kafka）、独立心跳服务（Consul/etcd）及全链路NTP校时。
Workerman 本身不支持双机热备，必须靠外部组件组合实现；单靠改 Workerman 代码或启多个进程无法自动故障转移。
负载均衡器必须启用会话保持或彻底无状态
客户端长连接若被随机分发到不同服务器，会导致消息丢失、状态错乱。常见错误是直接用 Nginx 四层转发却不加 ip_hash 或 sticky，结果用户反复重连。
- 若业务允许无状态（如广播推送），可关闭会话保持，但所有用户状态必须存 Redis，且每个 Workerman 实例在
onConnect时从 Redis 加载用户信息 - 若业务强依赖会话（如在线房间），必须启用会话保持，并配合 DNS 级健康探测+自动切流（如 Cloudflare Health Check + 自动 CNAME 切换）
- Nginx 七层代理 WebSocket 时，
upstream块中必须加sticky cookie=workerman_sid expires=1h domain=.example.com，否则升级后连接会被 302 重定向中断
Redis 必须跨机房高可用，禁用单点写入
所有 Workerman 实例共用一个 Redis 集群来存连接映射、用户在线状态、离线消息；一旦 Redis 单点宕机，整个长连接系统就不可用。典型坑是只配主从却没开 Sentinel 或 Cluster 模式，主库挂了从库不会自动升主。
- 推荐部署 Redis Cluster，至少 3 主 3 从，分布在两个机房（如 A 机房 2 主 1 从，B 机房 1 主 2 从），用
redis-cli --cluster create初始化 - Workerman 代码里不能写死
127.0.0.1:6379，必须用tcp://redis-cluster.example.com:6379这类域名，并确认 PHP 的redis扩展版本 ≥ 5.3.2（支持集群） - 所有
setex操作必须带过期时间，避免某台 Workerman 异常退出导致online:uid键永久残留
跨机房消息同步必须用 Pub/Sub + 本地队列兜底
用户 A 在机房 1 发消息，用户 B 在机房 2 在线，仅靠共享 Redis 无法实时触发 B 所在 Workerman 进程的推送——因为 Redis Pub/Sub 不跨集群，且没有持久化。常见错误是只用 $redis->publish()，结果 B 收不到。
- 每个机房部署独立 Redis Pub/Sub 通道，用
workerman/async-redis的subscribe监听本地channel:msg - 跨机房消息中继必须走 AMQP（如 RabbitMQ 镜像队列）或 Kafka，不能只靠 Redis
- 关键逻辑：机房 1 的 Workerman 收到消息 → 写本地 Redis + publish 到本地
channel:msg→ 同时发一份到 Kafka topic:cross-dc-msg → 机房 2 的消费者拉取后写本地 Redis + publish 到本地channel:msg
心跳与故障剔除必须独立运行，全链路统一 NTP 校时
Workerman 自带的 Timer::add 仅作用于本机进程，无法感知其他节点是否存活；若靠各实例自行检测再通知中心，容易因网络抖动误判。
- 必须部署独立的心跳服务（如基于 Consul 或 etcd 的健康检查），由外部统一采集各 Workerman 实例的
/status接口并标记状态 - 负载均衡器（如 Nginx Plus 或 HAProxy）需配置
health_check并对接该心跳服务，而非简单 ping 端口 - 所有服务器必须开启 NTP 客户端并指向同一授时源（如
pool.ntp.org），否则 Redis 过期键、心跳超时判定、日志时间戳都会错乱
真正难的不是启动两台 Workerman，而是让它们在故障发生时行为一致、状态不冲突、消息不丢——这要求每一层（连接层、状态层、通信层）都明确谁负责什么，且不能有单点隐含依赖。
