Workerman仅负责连接与协议处理，支撑Discord级万人多频道需自建分层架构：接入层（多Worker进程）、路由层（中心化ChannelManager+Redis同步映射）、存储层（Redis集群+MySQL），禁用全局连接遍历与进程内状态存储。
Workerman 本身不提供频道、权限、消息持久化等上层业务能力，它只负责连接管理与协议收发。要支撑类似 Discord 的万人多频道架构，必须在 Workerman 基础上自行设计分层结构——核心难点不在「能不能连」，而在于「怎么高效路由、隔离和扩缩容」。
为什么不能直接用 $worker->connections 全局广播？
Discord 场景下，1 万用户绝不会全在一个频道。若每次发消息都遍历全部 $worker->connections，哪怕只有 10% 用户在线（1000 连接），每条消息也要做 1000 次判断：这个连接属于哪个频道？有没有权限？是否已静音？这会迅速吃满 CPU，且无法水平扩展。
- 真实项目中，
$worker->connections是裸连接池，无业务语义，不可直接用于频道路由 - Workerman 默认单进程最多管理约 3000–5000 并发连接（取决于内存与内核参数），万人需多进程 + 连接分片
- 所有频道状态（谁在哪个频道、谁被禁言）必须脱离单个 Worker 进程存储，否则进程重启即丢失
必须拆出独立的频道路由层：用 ChannelManager 管理连接归属
你需要一个中心化的频道映射管理器，它不依赖某个 Worker 进程存活，而是基于内存+共享存储协同工作：
- 每个连接建立时（
onConnect），必须立刻完成「用户认证 → 分配 uid → 加入默认频道」三步，不能延迟到发消息时才查 - 用 PHP 的
SplObjectStorage或关联数组维护channel_id → [connection1, connection2, ...]映射，但该映射需在所有 Worker 进程间同步（推荐 Redis Hash 或 Swoole Table） - 禁止在
onMessage中实时查数据库判断权限——高频操作必须预加载进内存，如用户角色、频道 mute 列表可缓存在$connection->attributes中 - 频道切换（JOIN/LEAVE）必须原子操作：先从旧频道列表移除，再加入新频道列表，并广播「user X left/joined channel Y」
Worker::reload() 和多进程下频道状态不同步的坑
Workerman 的平滑重启（kill -USR1 或 php start.php reload）只会重启 Worker 子进程，但 onConnect 绑定的连接对象仍保留在原进程内存里——这意味着你手动存的频道映射数组（如 $channels['general'] = [...]）在新进程里是空的。
- 所有频道成员关系、用户在线状态、未读计数等，必须落地到外部存储（Redis 是最现实选择），不能靠进程内变量
- 不要用
global或静态属性存频道列表；Worker::$pid是进程 ID，不是唯一标识，别拿它当 key - 如果用 Redis，务必设置合理的过期时间（如连接断开后 30 秒自动清理），并配合
onClose主动 del key，避免僵尸连接堆积 - WebSocket ping/pong 心跳必须开启（
$connection->ping();配合定时器），否则断网用户无法及时从频道列表剔除
真正能扛住万人的部署结构长什么样？
单台机器跑一个 Workerman 实例撑不起 Discord 级负载。实际架构至少要三层分离：
- 接入层：多个 Workerman WebSocket Worker（如 8 个进程），只做连接维持、协议解析、消息收发，不做任何业务逻辑
- 路由层：独立的 Gateway 进程（可用 GatewayWorker 扩展，或自研），负责 uid ↔ connection 映射、频道路由、消息广播策略（单播/组播/广播）
- 存储层：Redis Cluster 存频道成员、消息队列（如 Predis + LIST/PUBSUB）、MySQL 存历史消息与用户资料
- 注意：Workerman 默认不支持跨机器连接广播，若要多机部署，必须用 Redis PUBSUB 或 Kafka 做消息总线，不能靠本地
$worker->connections
频道数量越多、用户越活跃，对 Redis 内存与网络延迟越敏感——这里没有银弹，Workerman 只是让你少写 epoll 循环，真正的架构复杂度一点没少。
