Workerman 能支撑万级 MQTT 设备长连接，但需自行实现协议解析、会话管理与消息路由；其本质是异步 TCP 网关，非开箱即用的 MQTT 服务器，关键在正确处理 CONNECT/PING/STATE 机制及 Redis 协同状态维护。
Workerman 能不能扛住万级 MQTT 设备长连接
能，但不是直接跑 MQTT 协议——Workerman 本身不解析 MQTT 报文，得自己实现或套一层 php-mqtt/server 这类库。它的优势是 PHP 少有的真正异步长连接能力，适合做 TCP 层的设备接入网关，但别指望它像 EMQX 那样开箱即用。
常见错误现象：connection reset by peer 频发、心跳超时后连接不释放、设备重连时旧连接残留；根本原因是没处理好 MQTT 的 CONNECT/CONNACK/PINGREQ/PINGRESP 状态机，只做了裸 TCP 转发。
- 必须自己维护连接状态（client_id、clean session、will message），PHP 没原生 MQTT 会话管理
- 心跳检测不能只靠 TCP keepalive，得解析 MQTT PING 包并主动回复
PINGRESP - 消息路由要按 topic 做内存级分发，别一来 publish 就全广播——否则 5000 设备连上来，一条群控指令就 CPU 拉满
用 Workerman 写 MQTT 接入层的关键三步
不是写个 onMessage 就完事。真实设备接入要过三关：协议解析、会话绑定、上下行分流。
使用场景：温湿度传感器定时上报、PLC 下发控制指令、固件远程升级通知下发。
- 第一步：用
binaryProtocol+ 自定义decode/encode处理 MQTT 固定头和可变头，别用json_decode硬解——MQTT 报文是二进制流，CONNECT包里的 protocol name 是 0x00 0x04 ‘M’ ‘Q’ ‘T’ ‘T’，不是字符串 - 第二步：在
onConnect里根据 client_id 查 Redis，恢复上次会话（如果 clean_session = false），并把$connection->session设为关联数组存 qos、topic filter 等 - 第三步：收到
PUBLISH后，用preg_match或前缀树（如php-trie）匹配订阅关系，只推给匹配的 connection，避免全量遍历
为什么别在 Workerman 里直接存设备数据
Workerman 进程间内存不共享，$_SESSION 或全局数组在多进程下完全不可靠。设备状态、最后上线时间、未确认 QoS1 消息这些，必须落地到外部存储。
性能影响：如果在 onMessage 里同步写 MySQL，单条 PUBLISH 延迟从毫秒级变成百毫秒级，设备端会因超时反复重发。
- 设备在线状态用 Redis 的
SET device:xxx online EX 60 NX+ 定时任务扫描过期 key - QoS1 的 PUBACK 未收到，要把 msg_id 存 Redis Sorted Set，score 设为超时时间戳，另起一个
Timer::add定期扫 - 千万别用
file_put_contents记日志——高并发下文件锁会让所有 worker 卡住
TCP 长连接下 Workerman 的真实瓶颈在哪
不是 CPU，也不是内存，是 Linux 内核的 socket 数量限制和 TIME_WAIT 连接堆积。设备频繁断连重连时，netstat -ant | grep TIME_WAIT | wc -l 很容易破万。
兼容性影响：PHP 8.1+ 的 stream_socket_server 默认开启 SO_REUSEPORT，但 Workerman 2.x 不支持，得升到 4.x 或手动 patch。
- 调大
net.ipv4.ip_local_port_range和net.ipv4.tcp_fin_timeout，否则新连接建不起来 - 客户端必须带
keepalive（比如 60 秒），服务端在onClose里别直接 unset connection，先标记为 closing 等心跳超时再清理 - Workerman 的
reload会杀掉所有连接，设备无感知断连；要用gracefulStop+ 反向代理（如 Nginx）做连接漂移
复杂点在于 MQTT 协议状态和 Workerman 生命周期不耦合——一个连接可能经历多次重连、clean session 切换、topic 订阅变更，这些都得在内存+Redis 之间小心对齐，漏一步，设备就收不到指令或者重复上报。
