workerman 4 websocket 应用中，onmessage 内执行同步耗时操作会阻塞事件循环，正确做法是将任务序列化后推入 redis 队列，由独立 worker 进程异步消费，配合唯一 id、ack 机制、死信队列及会话中心保障可靠性与上下文传递。
Workerman 4 WebSocket 应用中，收到消息后若直接执行数据库写入、文件操作或远程 API 调用等耗时任务，会阻塞当前 Worker 进程的事件循环，导致其他连接无法及时响应——这是高并发场景下最常见也最危险的性能陷阱。解决的核心思路是：把同步阻塞操作从 onMessage 回调中剥离，交由独立的消费者进程异步处理。
消息入队：在 onMessage 中只做轻量推送
收到客户端消息后，不要在 onMessage 里查库、发邮件或调用 curl。应立即序列化任务数据（如用户 ID、消息内容、时间戳、来源连接标识），推送到可靠的消息中间件：
- 推荐用 Redis List +
LPUSH，配合BRPOP阻塞消费，轻量且兼容性好 - 任务体建议包含唯一 ID（如 UUID）和时间戳，便于幂等与超时追踪
- 示例：
$redis->lPush('chat_tasks', json_encode(['uid'=>1001, 'msg'=>'hello', 'ts'=>time()]));
独立消费者：用专用 Worker 进程消费队列
另起一个或多个 Worker 进程（不监听网络端口），专注从队列取任务并执行业务逻辑。这类 Worker 不参与连接管理，只做后台处理：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 使用
Worker::runAll()启动，但协议设为text://0.0.0.0:0或直接用new Worker(null)创建无监听 Worker - 在
onWorkerStart中初始化 Redis 客户端、DB 连接池（注意：不能用阻塞式 PDO，推荐workerman/mysql异步驱动） - 循环调用
BRPOP获取任务，失败时带短延时重试，避免空转消耗 CPU
保障可靠性：加 ACK、重试与死信
纯“推即走”容易丢任务。生产环境需补充基础可靠性机制：
- 任务入队前生成唯一 ID，执行成功后记录到 Redis Set 或 DB 表中，防止重复消费
- 消费者执行失败时，将任务移入
chat_tasks_failed列表，设置 TTL 自动过期 - 单独配置一个定时 Worker，定期扫描失败队列，对超时未恢复的任务触发告警或人工介入
连接上下文传递：需要知道是谁发的消息？
WebSocket 连接断开后，$connection 对象失效，无法在异步任务中直接调用 $connection->send()。若需服务端主动回推（比如消息存库后通知对方已读），有两类解法：
- 在入队时附带用户身份信息（如 token 或 session_id），由消费者查在线状态，通过全局
$connections数组（需用ConnectionInterface的id索引）定向推送 - 更稳妥的方式是引入「会话中心」：所有上线连接注册到 Redis Hash（
online_users:{uid}），离线时自动清理；任务执行完再通过 Redis Pub/Sub 或轮询方式触达目标连接
