当前位置：首页 > 文章列表 > 文章 > php教程 > Workerman广播消息方法及循环发送数据技巧

Workerman广播消息方法及循环发送数据技巧

2026-04-05 11:18:26 0浏览收藏

Workerman虽无内置广播方法，但通过安全遍历$worker->connections并结合isClosed()与isWebSocket()校验可实现高效广播；然而实际生产中，连接状态管理、多进程下连接与用户ID映射的跨进程一致性（需Redis或Channel支撑）、以及发送缓冲区积压导致的静默失败这三大陷阱，往往让看似简单的广播功能在高并发、万级连接场景下悄然崩溃——稍有疏忽，就可能因残留连接、未监听onBufferFull或未节流循环而拖垮服务。

Workerman怎么广播消息_循环connections发送数据方法【方法】

Workerman广播消息最直接的做法就是遍历`$worker->connections`

Workerman本身不内置“广播”方法，但每个Worker实例都维护着一个$connections数组，里面存着当前进程所有活跃的TcpConnection对象。只要遍历它、对每个连接调用send()，就完成了广播。

常见错误现象：$worker->connections是只读属性，不能直接修改；如果在onMessage里误删了某个连接又没及时清理引用，可能导致send()调用失败或静默丢包。

必须确保连接未关闭（可用$connection->isClosed()判断）再调用send()
单进程下可直接用$worker->connections；多进程必须配合Channel组件同步连接状态，否则只能广播到本进程内的连接
广播前建议加if ($connection->isWebSocket())过滤非 WebSocket 连接（如你只跑 WebSocket 服务）

为什么不能直接用`foreach($worker->connections as $conn)`无脑发？

因为$worker->connections包含所有连接——包括正在握手、尚未完成协议升级的 TCP 连接，也包括已触发onClose但尚未被 Worker 内部清理的“僵尸连接”。直接发会导致Call to a member function send() on null或Connection is closed警告。

实操建议：广播函数里加上安全包裹：

function broadcast($worker, $data) {
    foreach ($worker->connections as $connection) {
        if ($connection && !$connection->isClosed() && $connection->isWebSocket()) {
            $connection->send($data);
        }
    }
}

$connection->isWebSocket()能排除掉 raw TCP 或 HTTP 升级前的中间态连接
不检查isClosed()的话，在高并发断连场景下容易触发 warning 甚至 crash
该循环本身是同步阻塞的，10 万连接时单次广播可能耗时数百毫秒，业务敏感场景需考虑分批或异步队列

想按用户 ID 推送？别只靠`$connection->uid`，得自己建映射表

Workerman 不自动管理用户身份，$connection->uid只是个可写属性，赋值后不会自动去重、不会跨进程共享、也不会在断连时自动清理。很多人以为设了$connection->uid = 123就能靠它精准推送，结果发现重复登录、ID 冲突、推送丢失全来了。

正确做法是：在onMessage首次验证后，把$connection->uid作为键，存进$worker->uidConnections这个自定义数组，并在onClose里主动unset。

必须把$worker->count = 1，否则多进程下$worker->uidConnections各自为政，推送会漏人
真实项目要支持横向扩展，就得用 Redis 或 Channel 做 uid → connection 的跨进程映射
别在onClose回调里做耗时操作（比如查 DB），否则会拖慢整个进程的连接回收

广播性能卡在哪？不是`send()`慢，是缓冲区压爆了

真正让广播变慢甚至失败的，往往不是循环本身，而是某几个连接的发送缓冲区（_sendBuffer）持续积压。一旦某个连接网络卡顿或客户端不收数据，它的_sendBuffer就会涨到$connection->maxSendBufferSize（默认 1MB），触发onBufferFull，后续send()直接返回false，但多数人没监听这个回调，就以为“发出去了”。