redis-shake无法同步Pub/Sub消息，因其仅同步RDB/AOF及写命令，而SUBSCRIBE/PUBLISH属连接态行为且不持久化；应改用LPUSH/BRPOP或Stream等可复制数据结构替代。
Redis 的发布订阅（Pub/Sub）本身不支持跨机房同步，redis-shake 也不能转发 Pub/Sub 消息 —— 它只同步写命令和 RDB/AOF 数据，而 SUBSCRIBE/PSUBSCRIBE 是客户端连接态行为，不属于持久化或可复制的命令流。
为什么 redis-shake 同步不了 Pub/Sub 消息
redis-shake 的 sync 模式本质是伪装成 Redis 从节点，靠 PSYNC 协议拉取主节点的 RDB 文件 + 复制缓冲区中的写命令（如 SET、LPUSH、EXPIRE）。但：
-
PUBLISH命令虽会被复制，但它只是“触发一次广播”，不改变任何 key 状态，也不写入 AOF（除非开启notify-keyspace-events并配置了E事件）； -
SUBSCRIBE/PSUBSCRIBE是纯客户端连接协议指令，服务端不记录、不复制、不落盘，redis-shake 根本收不到； - 即使源端
PUBLISH被同步到目标端，目标端没有活跃的 subscriber 连接，消息就直接丢弃 —— 没有“消息队列”的存储语义。
替代方案：把 Pub/Sub 转成可同步的写操作
真正可行的做法，是绕过 Pub/Sub 协议本身，改用 redis-shake 能识别的、带状态的命令来承载消息语义。常见落地方式：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
LPUSH+BRPOP模拟队列：发消息写LPUSH queue:order_event "..."，消费者用阻塞读消费；redis-shake 全量+增量都能同步这个 list，目标端可照常BRPOP； - 用 Stream（Redis 5.0+）：
XADD stream:log * field value写入，消费者用XREAD或XGROUP消费；Stream 是持久化数据结构，redis-shakesync模式默认支持； - 加一层轻量代理：在源机房部署一个服务，监听 Pub/Sub，收到后转成
SET+ 过期时间 或LPUSH到某个 key，再由 redis-shake 同步该 key —— 关键是让“消息”变成“可复制的数据”。
如果硬要用 redis-shake 配合 Pub/Sub，必须注意的坑
有人试图在源端开 notify-keyspace-events Ex，把订阅事件转成 __keyevent@0__:expired 这类 key 事件，再用 redis-shake 同步这些 key。这行不通，因为：
- keyspace 事件是服务器主动推送的，不是客户端执行的命令，不会进入复制流；
- 即使你用
CONFIG SET notify-keyspace-events开启，redis-shake 作为从节点也收不到这些通知； - 事件 key（如
__keyevent@0__:set）本身不是业务数据，同步过去也没法被目标端的 subscriber 感知。
跨机房 Pub/Sub 同步不是配置问题，而是模型错配。真正要做的，是放弃“同步订阅关系”，转而同步“消息载体”。Stream 和 List 是目前最稳妥、redis-shake 支持最完整的选择 —— 它们有状态、可重放、能跨集群 slot 映射，且不需要额外维护连接生命周期。
