1. Redis发布订阅机制的特性与痛点
Redis的PUB/SUB（发布订阅）模式是实时消息系统的经典实现，但用过的人都知道它有个致命伤——消息不持久化。当订阅者离线时，所有在此期间发布的消息就像没存在过一样。这种设计源于Redis早期的内存数据库定位，但如今在要求可靠消息传递的场景下就成了明显的短板。
我曾在电商秒杀系统中踩过这个坑。当时用PUB/SUB做库存变更通知，结果某个消费者服务重启期间，漏掉了关键库存释放消息，直接导致超卖事故。这个教训让我深入研究了Redis消息持久化的几种解决方案，下面就把实战经验分享给大家。
2. 原生PUB/SUB的运作原理
2.1 消息传递机制
当客户端执行PUBLISH channel message时，Redis会立即将消息推送给所有连接到该channel的订阅者。这个过程完全在内存中完成，不会写入任何磁盘文件，也不会记录到AOF/RDB中。这就是为什么服务重启后消息会"蒸发"的根本原因。
2.2 设计哲学与局限
这种设计其实体现了Redis的核心思想：用内存换速度。PUB/SUB的吞吐量可以达到10万+/秒，正是牺牲了持久性换来的。但对于订单状态变更、支付通知等业务场景，这种"即发即弃"的模式显然不够可靠。
3. 主流解决方案对比
3.1 Redis Stream方案
Redis 5.0引入的Stream数据结构是解决该问题的首选方案。它本质上是个持久化的消息队列，具有以下关键特性：
- 消息持久化到内存和磁盘（如果开启AOF）
- 支持消费者组（Consumer Group）
- 消息可回溯
- 支持阻塞/非阻塞读取
# 生产者示例 XADD mystream * field1 value1 field2 value2 # 消费者示例 XREAD COUNT 2 STREAMS mystream 0重要提示：Stream的存储机制与PUB/SUB完全不同，它使用类似日志的结构存储消息，每条消息都有唯一ID，消费者需要自己维护消费位置。
3.2 列表(List)+BRPOP方案
对于低版本Redis，可以用LPUSH+BRPOP组合模拟持久化队列：
# 生产者 LPUSH myqueue "message1" # 消费者 BRPOP myqueue 0 # 0表示无限等待这种方案的缺点是：
- 没有多消费者组支持
- 消息被消费后即删除
- 需要自行实现消息重试机制
3.3 第三方插件方案
有些企业会选择使用Redis模块如：
- ReJSON：在消息中存储消费状态
- RedisTimeSeries：记录消息时间戳 但这些方案会增加系统复杂度，一般不建议中小项目使用。
4. Stream方案深度实践
4.1 生产环境配置建议
在redis.conf中确保以下配置：
appendonly yes # 开启AOF持久化 aof-rewrite-incremental-fsync yes auto-aof-rewrite-percentage 1004.2 消费者组最佳实践
创建消费者组：
XGROUP CREATE mystream mygroup $ MKSTREAM消费消息并确认：
XREADGROUP GROUP mygroup consumer1 COUNT 1 STREAMS mystream > XRANGE mystream - + COUNT 5 # 查看最近5条消息 XACK mystream mygroup 1526569495631-0 # 确认消息处理完成4.3 消息堆积处理
当消费者处理速度跟不上时，需要监控Pending队列：
XPENDING mystream mygroup处理策略：
- 增加消费者实例
- 实现死信队列转移
- 报警人工干预
5. 性能优化技巧
5.1 内存控制
Stream默认不限制长度，生产环境建议设置上限：
XTRIM mystream MAXLEN ~ 1000 # 保留约1000条5.2 批量操作
使用管道(pipeline)提升吞吐量：
pipe = redis.pipeline() pipe.xadd("mystream", {"data": "value1"}) pipe.xadd("mystream", {"data": "value2"}) pipe.execute()5.3 监控指标
关键监控项包括：
- stream_length：队列长度
- groups：消费者组数量
- pending：待处理消息数
- memory：内存占用
6. 常见问题排查
6.1 消息丢失排查
如果发现消息丢失：
- 检查AOF是否开启
- 确认消费者没有误用XREAD代替XREADGROUP
- 检查网络中断情况
6.2 性能瓶颈
当吞吐量下降时：
- 检查是否单个Stream过大（可考虑分片）
- 监控消费者处理耗时
- 检查Redis内存碎片率
6.3 消费者重启处理
消费者重启后应该：
- 先处理XPENDING中的消息
- 再开始新消息消费
- 记录最后处理的消息ID到外部存储
7. 方案选型建议
对于不同场景我的推荐：
- 实时通知+可靠性要求高：Redis Stream
- 简单任务队列：List+BRPOP
- 兼容旧系统：可考虑用Stream模拟PUB/SUB行为
迁移到Stream时要注意：
- 客户端库的版本兼容性
- 消息ID的生成策略
- 消费者偏移量管理方式
在最近的一个物联网平台项目中，我们将原有的PUB/SUB迁移到Stream后，消息可靠性从约70%提升到99.99%，虽然吞吐量下降了约30%，但这个代价对于业务来说是完全值得的。
