不能在 node.js cluster 模式下让多个 worker 共享同一个 redis 订阅连接，因为每个 worker 是独立进程，内存与 socket fd 完全隔离，且 redis 订阅连接进入阻塞模式后仅响应 pub/sub 命令；必须为每个 worker 单独创建 ioredis 实例并监听 ready 后订阅，同时处理重连与异常。
不能在 Node.js cluster 模式下让多个 Worker 共享同一个 Redis 订阅连接 —— 这不是限制，而是必然失败的设计。
为什么 worker 间无法共享 ioredis 的 subscribe 连接
Redis 的 subscribe 是长连接 + 阻塞式协议行为：一旦进入订阅模式，该连接就只能处理 message、subscribe 等 Pub/Sub 相关响应，不能再发普通命令；更重要的是，Node.js 的每个 worker 是独立进程，内存和 socket fd 完全隔离。你在一个 worker 里 redis.subscribe('a')，其他 worker 根本“看不见”这个连接，也无法收消息。
常见错误现象包括：
- 只有启动最早的那个 worker 收到消息，其余静默
- 某个 worker 崩溃后，整个订阅中断，且无重连（因为没监听
reconnecting和ready） - 用
cluster.fork()后在 master 里创建 redis 实例并传给 worker —— 失败，IPC 不支持传递 socket 句柄
正确做法：每个 worker 独立订阅，但避免重复消费
必须接受“每个 worker 都要建立自己的 ioredis 实例并调用 subscribe”这个事实。关键在于控制语义，而非连接数：
- 使用
psubscribe('user:*')时，所有 worker 都会收到同一条user:123消息 → 需业务层做幂等或分片路由 - 若只想让一个 worker 处理某类事件（如定时任务触发），改用 Redis 的
BRPOP+ List 队列，天然支持多 consumer 竞争消费 - 对广播类消息（如配置刷新），所有 worker 订阅没问题，但需确保 handler 是无状态、可重入的
- 务必封装订阅逻辑为函数，并在
redis.on('ready')后调用，同时监听reconnecting并在恢复后重新subscribe
示例片段（worker 内）：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
const Redis = require('ioredis');
const redis = new Redis({ host: '127.0.0.1', port: 6379 });
function setupSubscription() {
redis.subscribe('config:reload', (err, count) => {
if (err) console.error('subscribe failed:', err);
});
}
redis.on('ready', setupSubscription);
redis.on('reconnecting', () => {
console.log('Redis reconnecting...');
});
redis.on('message', (channel, msg) => {
if (channel === 'config:reload') reloadConfig();
});
Master 进程要不要也连 Redis？
通常不要。master 只负责进程管理，不处理业务逻辑；如果它也 subscribe，反而增加冗余连接和消息重复风险。例外场景仅限于：
- 需要由 master 统一接收信号并广播给所有 worker（比如通过
process.send） - 实现跨 worker 的协调逻辑（如 leader election），此时要用 Redis 的
SET key value NX EX 30加锁，而不是 Pub/Sub
这种协调场景下，master 和 worker 都连 Redis 没问题，但必须用原子命令，不能依赖 Pub/Sub 的时序。
性能与稳定性容易被忽略的点
每个 worker 建立独立订阅连接看似浪费，实际影响极小 —— Redis 单实例轻松支撑上万订阅连接。真正要卡住的是错误处理：
- 没监听
error事件会导致 unhandledRejection，worker 意外退出 - 没设
retryStrategy，网络抖动时连接断开即永久失联 - 用
psubscribe('*')或模糊匹配过宽（如psubscribe('log:*:error')但日志键名含特殊字符），会触发 Redis 内部正则扫描，CPU 暴涨 - Worker 重启时未取消旧订阅（虽然连接已断，但部分 Redis 版本会残留 SUBSCRIBE 状态），建议加
redis.quit()在process.on('SIGTERM')中
复杂点不在“怎么连”，而在于“连上之后，谁该响应、怎么不重复、断了怎么办”。Pub/Sub 在 cluster 下从来不是共享机制，而是广播通道 —— 接收方必须自行承担去重、路由、容错责任。
