Redis Pub/Sub 不支持消息回溯，因其无存储、不记offset；需改用Stream，配合XGROUP、XREADGROUP、XACK等命令实现持久化与确认机制。
Pub/Sub 根本不存消息，所以“回溯”无从谈起
Redis Pub/Sub 没有消息存储层，不生成 ID、不记 offset、不维护任何消费位置。PUBLISH 一执行完，消息就进 socket 缓冲区发给当前在线的 SUBSCRIBE 连接，发完即焚。哪怕你刚断开 100ms，期间发布的所有消息全部丢弃，Redis 不会缓存、不会重放、也不会告诉你“你漏了哪几条”。这不是配置没开对，是协议本身就不支持。
常见错误现象包括：
-
PUBSUB NUMSUB mychannel返回 1，你以为“有人在线就能收到”，其实只是“此刻连着”，和历史消息完全无关 - 用
PSUBSCRIBE order:*，网络抖动后重连，之前发布的order:123消息永远消失 - 服务滚动重启时，
UNSUBSCRIBE→ 断连 →SUBSCRIBE窗口期内的消息全量丢失
想回溯必须换 Stream，不是加参数能解决的
Redis 5.0+ 的 Stream 是唯一可行替代方案，它把事件当 append-only log 存下来，每条消息带自增 ID（如 1743892210123-0），天然支持按 ID 回溯。但要注意几个关键动作不能少：
- 写入必须用
XADD stream:events * event "paid" order_id "123"，*表示由 Redis 自动生成 ID；别用LPUSH+PUBLISH组合，那还是没回溯能力 - 首次消费前必须建组：
XGROUP CREATE stream:events mygroup $ MKSTREAM，$表示从最新消息开始，避免一启动就拉几万条老数据 - 回溯读取要指定 ID：
XREADGROUP GROUP mygroup c1 STREAMS stream:events 0-0从头读，1743892200000-0从某个时间点读，>只读新消息 - 不设
MAXLEN会导致 stream 无限膨胀，建议加XADD stream:logs MAXLEN ~ 10000 * level "warn"，~是近似裁剪，性能更好
Stream 消费者名不是标签，是强状态标识
很多人以为 consumer1 可以随便换，比如每次用 "c_" + System.currentTimeMillis()，结果发现消息越积越多。实际上，Redis 内部为每个 consumer 名单独维护 PEL（Pending Entries List）和 LAST_DELIVERED_ID。随机 consumer 名 = 每次都注册新消费者 = 老消息没人 XACK = PEL 堆满后阻塞新消费。
正确做法：
- consumer 名应固定且有业务含义，比如
order-processor-v2，而不是时间戳或 UUID - 处理成功后必须调
XACK stream:events mygroup 1743892210123-0，否则该消息下次还会被拉到 - 若消费者宕机，可用
XPCLAIM把超时未 ACK 的消息转给其他 consumer，实现故障转移
别在 Pub/Sub 上试图模拟回溯逻辑
所有“先写 DB 再 publish”“用 Redis List 存消息副本”“定时轮询 pending 队列补发”等方案，本质上都是绕开设计缺陷的缝合，反而增加复杂度和失败点。比如：
- DB 和 Redis 不同事务域，
INSERT成功但PUBLISH失败，消息就卡在 DB 里没人拉 - 轮询脚本漏跑一次，pending 队列里的消息就永远沉底
- 多个服务实例同时监听同一 List，靠
BRPOP争抢，容易重复消费又难去重
真正需要回溯的场景——订单状态变更、审计日志、协同操作同步——必须接受 Stream 的语义：写入即持久化、ID 可排序、消费需确认。这不是“升级”，而是换模型。最容易被忽略的一点是：Stream 的 consumer 名一旦写死，就不能轻易改；改了等于新建消费者，历史未 ACK 消息将滞留在原 consumer 的 PEL 中，再也无法自动清理。
