PUB/SUB 无法持久化是设计使然，因其纯内存广播、无存储与消费状态管理；必须改用 Redis Stream，配合 XADD、XGROUP、XREADGROUP 和 XACK 实现可靠消息传递。
PUB/SUB 不能持久化，这不是配置问题，是设计决定的——它压根不存消息，重启、掉线、没订阅者，消息全丢。想“开启持久化”或加个参数让它记住消息，纯属白费劲。
为什么 PUB/SUB 永远存不住消息
PUB/SUB 是纯内存广播通道，没有存储层，也不维护任何消费状态：
-
PUBLISH返回1只表示“至少一个在线订阅者收到了”，不代表处理成功，更不保证落地 -
SUBSCRIBE不记录 offset、不存游标、不建消费者组，断连即失联，无从回溯 - AOF/RDB 配置对
PUB/SUB流量完全无效——这些机制只管 key-value 数据，不管 pubsub 管道里的字节流 - 常见现象：服务重启后漏订单通知、扩容新实例收不到历史日志、凌晨告警整批消失
必须用 Redis Stream 替代，不是打补丁
别在 PUB/SUB 上套 ACK 工具、加数据库兜底、或写定时轮询——这些都绕不开根本缺陷。真正能落地的方案，是切换到 Stream：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 写入用
XADD stream:order_events * event "paid" order_id "123"，*让 Redis 自动生成 ID（如1716649200000-0），天然有序可追溯 - 首次消费前必须建组：
XGROUP CREATE stream:order_events mygroup $ MKSTREAM，其中$表示从最新消息开始，MKSTREAM自动建 stream（避免NOGROUP错误） - 消费用
XREADGROUP GROUP mygroup consumer1 STREAMS stream:order_events >，>是特殊符号，代表“上次未确认的下一条” - 每条消息处理完必须调
XACK stream:order_events mygroup <message_id></message_id>，否则该消息会一直卡在 PEL（Pending Entries List）里，下次还给你
XADD 和 XGROUP 容易踩的坑
很多人以为改个命令就行，结果上线就堆积、重复、或查不到老消息：
- 忘记加
MAXLEN：比如XADD stream:logs MAXLEN ~ 10000 * level "warn"，~表示近似裁剪，比精确裁剪性能更好；不设就无限膨胀，磁盘迟早爆 - 建组时错用
0而非$：写成XGROUP CREATE mystream mygroup 0，会导致新消费者从头拉取几万条历史消息，直接打挂下游 - 消费者名随机生成：代码里每次用
"consumer_" + time.time()，等于不断注册新 consumer，旧消息永远没人XACK，PEL 越堆越多 - 误用
XREAD：它没消费者组概念，无法标记已读位置，也不支持XACK，仅适合单次快照读，不能替代XREADGROUP
Spring Data Redis 或 Python redis-py 怎么对接
不用硬写原生命令，主流客户端都封装了 Stream 支持：
- Spring Data Redis：用
streamOperations.add()发送，streamOperations.readGroups()拉取消息，自动处理GROUP和consumer名复用 - Python
redis-py：调r.xadd("mystream", {"event": "login"})和r.xreadgroup("mygroup", "c1", {"mystream": ">"})，注意传参格式，>必须作为字符串传入 - 别把
consumer当临时标签：它在 Redis 内部是强状态，同一组下不同名字 = 不同 PENDING 列表 + 独立游标，必须复用固定名
真正麻烦的不是换命令，而是意识到：你不是在修一个通信模块，而是在把“广播喇叭”换成“带签收的挂号信系统”。ID、组、ACK、游标、裁剪——每个环节漏掉一点，都会让消息在某个角落静默堆积或反复重发。
