Workerman多Worker共享数据必须通过进程安全的外部媒介，推荐Redis作为统一中转站，需初始化连接、规范key命名、使用INCR/DECR避免竞态；也可用Redis Pub/Sub或RabbitMQ/Kafka解耦通知；共享内存仅限单机只读缓存，严禁并发写入；文件锁仅作低频兜底方案。
Workerman多Worker之间共享数据时，若直接操作全局变量或文件，会导致数据错乱、覆盖或丢失，必须通过进程安全的外部媒介实现协同访问。
用Redis做统一数据中转站
这是最常用且推荐的方式。每个Worker进程不保存任何状态，所有读写都经由Redis完成，天然规避进程隔离带来的冲突。
第一步：在项目中引入Predis或phpredis扩展，并确保Redis服务已启动且可连通。
第二步：在Worker启动前初始化Redis连接实例，避免每次onMessage中重复创建连接——连接复用能显著降低开销，频繁新建连接可能触发Redis连接数上限或TIME_WAIT堆积。
第三步：对需要共享的数据，统一使用带业务前缀的key，例如用户在线状态存为 【online:user:1001】，群消息计数存为 【group:msg_count:55】；禁止直接用裸key如“count”，否则极易被其他模块误覆写。
第四步：涉及增减类操作（如+1/-1），必须使用Redis原生命令如INCR/DECR，而非先GET再SET——后者存在竞态窗口，两个Worker同时读到值5，各自加1后写回6，最终结果仍是6而非7。
用消息队列解耦状态变更
当共享行为本质是“通知”而非“同步读写”，比如某Worker处理完订单后需广播更新库存，此时用消息队列比轮询Redis更高效可靠。
方法一：Redis Pub/Sub
一个Worker执行publish('stock_update', json_encode(['sku'=>'A001','delta'=>-2]))，其余Worker订阅同一channel，收到后各自刷新本地缓存或触发校验逻辑。注意：Pub/Sub是fire-and-forget，不保证送达，适合非关键通知。
方法二：RabbitMQ或Kafka
将状态变更封装为结构化消息，投递到持久化队列，由专用消费者Worker顺序处理并更新Redis或数据库。这能严格保障变更顺序与至少一次交付，适用于资金、库存等强一致性场景。
用共享内存做高频只读缓存
仅限单机多Worker、且数据极少变动的场景，例如配置项、白名单IP列表。
启用shmop扩展后，在主进程中分配一块共享内存段，写入序列化后的配置数组；各Worker启动时attach该段并读取一次，后续全程读本地副本。这一步操作起来很简单，直接调用shmop_open即可。
但【严禁在Worker中写入共享内存】——PHP没有内置的跨进程互斥锁机制，多个Worker并发写会导致内存结构损坏，轻则数据错乱，重则引发Segmentation Fault崩溃。
用文件锁控制临界区写入
仅作为兜底方案，性能差、扩展性弱，仅适用于低频、小数据、单机部署的运维脚本类需求。
步骤一：打开目标文件，用fopen('data.json','c+')获取句柄。
步骤二：调用flock($fp, LOCK_EX)申请独占锁；未获得锁时阻塞等待，避免多个Worker同时解析-修改-写回造成覆盖。
步骤三：读取内容→反序列化→修改数组→json_encode→fwrite→fflush→flock($fp, LOCK_UN)释放锁。
这一步必须确保每次写入后调用fflush，否则操作系统缓冲区可能延迟落盘，导致其他Worker读到旧数据。
