PUB/SUB 不保证消息顺序性，仅单连接内 FIFO；多客户端、断连重连、无 offset/ack 机制导致全局顺序不可靠，严禁用于订单/支付等顺序敏感场景。
PUB/SUB 本身不保证消息顺序性——这不是 Redis 的设计目标，也不是它能解决的问题。
它只保证「单个 TCP 连接内、同一频道的消息按发布顺序送达」，但一旦涉及多个订阅者、网络重传、客户端重启或连接抖动，顺序就不可靠了。别被文档里“消息按发布顺序接收”这种模糊表述误导。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
PUB/SUB 的顺序性实际表现
-
SUBSCRIBE后，客户端进入阻塞读状态，Redis 按写入 socket 的顺序 push 消息，所以对单个活跃连接来说，看到的消息是 FIFO 的 - 但不同客户端之间完全独立：client A 和 client B 订阅同一个频道，它们收到消息的时间差取决于各自网络延迟、处理速度、是否卡在 GC 或 IO 上
- 客户端断连重连后，
SUBSCRIBE会从头开始收新消息，历史消息不会补发，也就谈不上“全局顺序” - 没有 offset、没有 ack、没有重试机制，
PUBLISH成功即认为完成，哪怕某个订阅者刚好丢包或崩溃
常见错误现象：
- 前端展示聊天记录时出现时间错乱（后发的消息先显示）
- 多个微服务监听同一事件频道，有的服务处理了
order_created，另一个却还没收到，导致状态不一致
为什么不能靠 PUB/SUB 做订单/支付类顺序敏感场景？
- 它本质是「fire-and-forget」广播，不是消息队列
- 不支持消费者组、无消费进度管理、无法确认消息已处理
-
PUBSUB CHANNELS只能查当前活跃订阅数，不能查某条消息是否被谁收到了 - 一旦
UNSUBSCRIBE或连接中断，消息永久丢失，无法追溯
如果你需要顺序性，必须换方案：
- 用
XADD+XREADGROUP，靠消费者组和XACK管理偏移量 - 或引入 Kafka / RabbitMQ，它们把顺序性作为核心契约来保障
- 纯 Redis 场景下，也可以用有序集合（
ZSET）+ 定时轮询模拟，但复杂度陡增，且非实时
PSUBSCRIBE 模式订阅对顺序性的影响更糟
- 模式匹配（如
news.*）由 Redis 在每次PUBLISH时遍历pubsub_patterns链表匹配，耗时不可控 - 匹配结果不缓存，高并发下可能造成消息投递延迟波动
- 多个 pattern 重叠时（比如
news.<em></em>和.sports），同一消息可能被重复匹配、重复发送，顺序更难对齐
真正容易被忽略的点：
你写的“顺序消费逻辑”，很可能只在本地测试环境跑通了——因为单机、低并发、无断连。一上生产，网络分区、客户端升级、DNS 切换、TLS 握手失败，都会让顺序瞬间瓦解。别拿 PUB/SUB 冒充可靠消息通道。
