Redis原生PUB/SUB无法跨机房工作，因其纯内存、无状态、不复制的设计本质；替代方案是STREAMS配合桥接服务实现跨机房消息同步。
Redis 原生 PUB/SUB 无法跨机房工作，这不是配置问题，而是设计使然——它根本没打算支持跨网络区域的消息同步。
为什么 PUB/SUB 在跨机房场景下必然失效
核心原因就三点：纯内存、无状态、不复制。订阅者连上哪个 Redis 实例，就只收那个实例上的 PUBLISH；消息不会持久化，也不会转发到其他节点。即使你用 Sentinel 或 Cluster，它们只管高可用和分片路由，完全不管 PUB/SUB 消息的传播范围。
-
Sentinel故障转移后，所有SUBSCRIBE连接会断开，客户端必须重连，且历史消息全丢 -
CLUSTER下PUBLISH默认只发当前节点，加--cluster-call遍历执行也不可靠——订阅者未必连在目标节点上 - 强行让客户端直连异地 Redis 节点，会遇到
READONLY错误（从节点）、NOAUTH拒绝、高延迟导致PSUBSCRIBE模式匹配漏事件等问题
用 STREAMS 替代 PUB/SUB 是唯一可行路径
STREAMS 支持持久化、消费者组、ACK 确认，这才是跨机房消息分发的基础设施。关键不是“怎么配”，而是“谁来同步”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 源机房写入：
XADD stream:events * event "data" region "shanghai" - 用
redis-cli --rdb或redis-replicator监听 AOF/RDB/协议流，捕获XADD并转发到目标机房 Redis 或 Kafka/Pulsar - 目标机房用
XREADGROUP消费，或由同步服务再XADD到本地 stream - 注意
MAXLEN和TRIM策略——同步延迟高时，本地 stream 容易积压爆炸
如果必须保留 PUB/SUB 接口，只能靠桥接服务兜底
这不是 Redis 的能力，是应用层自己搭的消息网关。每个机房部署一个桥接服务，它同时连本地和远端 Redis，把本地 PUBLISH 解析后通过 HTTP/gRPC/MQTT 转发出去。
- 桥接服务必须处理连接抖动：重试 + 幂等（比如用
message_id+SETNX去重） - 序列化要统一：推荐 JSON 或 Protobuf，避免不同语言解析歧义
- 不能依赖
SUBSCRIBE的实时性：网络延迟 >100ms 时，PSUBSCRIBE可能漏掉刚到达的 pattern 匹配 - 监控必须跟上：
PUBSUB NUMSUB channel查在线订阅数，INFO clients里看connected_clients和client_recent_max_input_buffer
真正容易被忽略的是：跨机房消息一致性从来不是单靠一个中间件能解决的，STREAMS 提供了基础能力，但同步延迟、重复投递、消费者位点管理这些细节，必须在桥接逻辑或业务层显式处理。指望 Redis 自动搞定，只会在线上出问题时才发现根本没日志可查。
