Workerman 4 中 Redis Pub/Sub 多进程重复接收消息，因每个进程独立订阅形成广播；应仅由一个进程订阅并转发，或改用 Redis Stream 消费者组实现公平分发。
Workerman 4 中用 Redis 的发布订阅（Pub/Sub）实现多进程通信时，多个 Worker 进程各自订阅同一频道，会导致每条消息被每个进程都收到一次——这就是典型的“重复接收”问题。这不是 Redis 的 bug，而是 Pub/Sub 的设计机制：它面向的是客户端连接，不是进程。一个进程启动一个连接，就等于一个独立订阅者。
为什么多进程会重复消费？
Redis Pub/Sub 是广播模型：只要客户端调用 SUBSCRIBE channel，它就成为该频道的独立接收端。Workerman 默认开启多个子进程（如 count = 4），每个进程在 onWorkerStart 中新建 Redis 连接并订阅，结果就是 4 个连接同时监听同一个频道，消息一发，4 份副本全收到。
这和消息队列（如 Redis List + BRPOP）有本质区别：队列是“抢模式”，消息只能被一个消费者取走；而 Pub/Sub 是“推模式”，不区分消费者身份，只看当前有多少订阅连接。
解决思路：单进程订阅 + 进程间转发
核心原则：**只让一个 Worker 进程负责订阅，其他进程通过内部通信接收消息**。这样既保留 Pub/Sub 的实时性，又避免重复。
- 选一个进程（例如 worker_id === 0）作为“订阅中心”，建立 Redis 连接并
SUBSCRIBE - 该进程收到消息后，不直接处理业务，而是通过 Workerman 内置的
Worker::$connections或Channel组件广播给所有其他 Worker 进程 - 其他进程只负责接收和执行，不连 Redis 订阅
示例关键逻辑：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
$worker = new Worker('text://0.0.0.0:1234');
$worker->count = 4;
$worker->onWorkerStart = function($worker) {
if ($worker->id === 0) {
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
// 只在 id=0 的进程里订阅
$redis->setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_PHP);
$redis->subscribe(['event'], function($redis, $chan, $msg) use ($worker) {
// 向所有其他进程广播（不含自己）
foreach($worker->connections as $conn) {
if ($conn->workerId !== 0) {
$conn->send(json_encode(['type'=>'event','data'=>$msg]));
}
}
});
}
};
替代方案：改用 Redis Stream（推荐用于生产）
如果项目允许升级 Redis 版本（≥5.0），强烈建议用 Stream 替代 Pub/Sub。Stream 支持消费者组（Consumer Group），天然解决多进程公平分发问题：
- 所有 Worker 进程加入同一个 consumer group（如
workerman-group） - 使用
XREADGROUP拉取消息，Redis 自动保证每条消息仅由组内一个消费者处理 - 支持消息确认（
ACK）、未处理消息重投、消费者离线恢复等能力
相比 Pub/Sub，Stream 更接近专业 MQ 的语义，适合需要可靠投递的场景。
不推荐的“伪解法”
有些方案试图用分布式锁（如 SETNX）或消息 ID 去重，但这治标不治本：
- 加锁只是把并发变串行，没减少网络和 CPU 开销，还引入锁失败逻辑
- 去重依赖业务层判断，无法避免消息已多次到达各进程的内存中
- Pub/Sub 本身无 ACK、无持久化，消息一旦发出即丢失上下文，不适合做可靠性保障
真正要解决重复，得从通信模型源头入手——要么收敛订阅入口，要么换更合适的中间件语义。
