Redis PUB/SUB在并发下无法保证消息顺序与消费一致性，因其无服务端状态跟踪；必须用Stream替代，通过XADD生成有序ID、XREADGROUP绑定消费者组、XACK确认消费来实现可靠消息传递。
Redis 的 PUB/SUB 在并发环境下**无法保证跨客户端、跨连接、跨重连场景下的消息顺序性与消费一致性**——这不是配置或调优能解决的问题，而是设计层面的限制。它只在「单个订阅连接持续存活、无网络抖动、无重连」的理想路径下维持通道内 FIFO，现实系统几乎不可能满足。
为什么 PUB/SUB 的顺序性在并发下必然失效
根本原因在于它没有服务端状态跟踪：Redis 不记录谁收到了哪条消息、哪条没收到、是否处理成功。所有“有序”依赖 TCP 连接的字节流保序 + 客户端缓冲区 FIFO，一旦连接中断，整个链路就断了。
- 订阅者断连重连后，
SUBSCRIBE重建连接，但断连期间所有PUBLISH消息彻底丢失，无法回溯 - 多个消费者同时
SUBSCRIBE同一 channel，Redis 并发广播，各客户端接收时间受网络延迟、本地调度影响，到达顺序不一致 - 生产者用两个线程分别
PUBLISH channel1 msgA和PUBLISH channel2 msgB，消费者无法判断 msgA 和 msgB 的真实发生先后 - 没有任何机制让 Redis 知道某条消息是否被业务逻辑真正“处理完成”，也就谈不上重试、确认、去重
用 Stream 替代 PUB/SUB 是唯一可行路径
要同时满足「顺序性」+「消费一致性」+「并发容错」，必须切换到 Stream。它的 ID 机制和消费者组（Consumer Group）是为分布式可靠消费而生的，不是 PUB/SUB 的增强版，而是替代方案。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
XADD stream_name * field value自动生成单调递增 ID（如1743892210123-0），天然支持全局时序对齐 - 必须用
XREADGROUP GROUP g1 c1 COUNT 1 STREAMS stream_name >，而不是裸XREAD；只有XREADGROUP才会绑定消费者名、维护last_delivered_id和PEL - 消费后必须显式调用
XACK stream_name g1 <id></id>，否则消息一直留在 PEL 中，内存持续增长 - 若消费者崩溃未
XACK，其他成员可用XCLAIM抢占超时消息，避免卡死
别踩这些 Stream 实操坑
很多团队把 PUB/SUB 换成 Stream 后仍出问题，往往卡在细节上：
- 创建消费者组时用了
XGROUP CREATE stream_name g1 $，结果从最新消息开始读，漏掉历史数据；应改用0-0从头消费 -
XACK传入的 ID 格式错误，比如只传"1743892210123"而不是完整"1743892210123-0"，命令静默失败，PEL 不清理 - 误以为
MAXLEN ~ 1000能自动缩容 PEL —— 它只控制主 stream 长度，PEL 是独立结构，需靠XACK主动释放 - 没设置消费者组的
GROUP名唯一性约束，多个服务用同名 group 写同一 stream，造成消费进度互相覆盖
真正难的不是写对几条命令，而是接受一个事实：PUB/SUB 从来就不是为“顺序+一致”设计的。把它当广播通知用可以，想靠它做订单状态同步、资金流水对账，等于在流沙上盖楼。Stream 的学习成本略高，但每一步都是在补上状态管理的缺口——这个缺口，PUB/SUB 根本不打算填。
