Redis Pub/Sub 不支持消息持久化，是设计使然；需改用 Redis Stream 或应用层兜底实现可靠性，关键在于明确业务需求是广播通知还是可靠事件分发。

Redis Pub/Sub 本身不支持消息持久化，这是设计使然

Redis 的 PUBSUB 模型定位就是轻量、实时、无状态的广播通信——它不存消息，不记消费进度，也不管订阅者是否在线。只要发布者一调用 PUBLISH，消息就发出去；如果此时没人订阅，或者订阅者网络断开，消息直接丢弃，连日志都不会留。这不是 bug，是 feature。

所以别试图给 redis-cli 加个参数、改个配置项，或在 redis.conf 里翻 appendonly 或 save 设置来“开启 Pub/Sub 持久化”——这些只管 Redis 数据库本身的 RDB/AOF，对 Pub/Sub 流量完全无效。

用 Redis Stream 替代 Pub/Sub 是最直接的落地方案

Stream 是 Redis 5.0+ 内置的持久化消息模型，天然支持：消息写入磁盘（AOF/RDB 覆盖）、消费者组（GROUP）、ACK 确认（XACK）、未确认重投（XPENDING）、历史消息回溯（XREAD 从任意 ID 读）。

• XADD stream:logs * level "ERROR" msg "timeout" —— 发送带结构的消息，ID 自动生成
• XGROUP CREATE stream:logs mygroup $ MKSTREAM —— 创建消费者组，$ 表示从最新开始
• XREADGROUP GROUP mygroup c1 COUNT 1 STREAMS stream:logs > —— 拉取新消息，“>” 表示只读未分配过的
• 处理完必须手动调 XACK stream:logs mygroup {id}，否则下次 XPENDING 还能查到

Spring Data Redis 也已完整支持 Stream：streamOperations.add()、streamOperations.readGroups()，比手写 pubsub 监听器更可控。

硬要保留 Pub/Sub？那就得靠应用层兜底

如果已有大量基于 PUBLISH/SUBSCRIBE 的代码，短期无法重构，就得在业务逻辑里补足缺失的能力：

• 所有关键消息，发布前先 LPUSH msg_queue_backup 到一个 List，再 PUBLISH；订阅者收到后，异步删掉对应备份（或用 LREM 安全删除）
• 监听器收到消息后，立刻落库（如 MySQL 的 messages 表），加字段 status ENUM('pending','processed')，定时任务扫 pending 补发
• 不要依赖 RedisMessageListenerContainer 的自动重连——它只重连连接，不重发离线期间的消息；得自己维护一个 last_seen_id 偏移量，重启后去 Stream 或 DB 拉增量

这种方案不是“修复 Pub/Sub”，而是绕开它，在它外面套一层可靠性壳。代价是代码变重、事务边界变模糊、排查链路变长。

别忽略监控和告警，否则问题永远后知后觉

Pub/Sub 场景下最容易被忽视的是“静默丢失”：没报错、没异常日志，但某类通知就是收不到。这时光看应用日志没用，得盯 Redis 侧指标：

• 用 pubsub numpat 和 pubsub numsub channel 查当前订阅数，突然归零说明客户端批量崩溃或网络隔离
• 在发布端加埋点：记录每次 PUBLISH 的返回值（整数，表示收到消息的客户端数），持续为 0 就得告警
• Stream 方案下重点监控 XPENDING 返回的 pending 数和 idle 时间，超 5 分钟未 ACK 就触发人工介入

真正的难点不在怎么写代码，而在于想清楚：你到底需要“广播通知”，还是“可靠事件分发”。选错模型，后面所有优化都是在给漏水的桶打补丁。