获课：xingkeit.top/5702/

告别“发后即忘”：从Redis Pub/Sub到Stream的消息流演进哲学

在分布式系统的语境里，消息队列往往是架构师们最愿意投入重金的地方。Kafka的吞吐、RocketMQ的事务，似乎成为了高阶架构的标配。但在许多中小规模或特定业务场景中，引入一套重量级消息中间件带来的运维成本，往往远超业务本身的复杂度。这时，Redis作为“万金油”被推向前台。然而，在我实战复盘Redis消息流架构时，我最大的感触是：很多人死在了把Redis的Pub/Sub（发布订阅）当成消息队列用的错觉里。

初识Redis Pub/Sub的人，大多会被它极简的API所迷惑：一个PUBLISH，一个SUBSCRIBE，仿佛世界就这么轻松地连接在了一起。但从架构哲学的视角审视，Pub/Sub本质上是一个“无情”的广播系统。它的核心机制是“发后即忘”，消息发出的一瞬间，如果没有消费者在监听，这条消息就像流星一样划过夜空，永远消失了。它没有持久化，没有ACK（确认机制），更没有重试。

在实战中，我见过太多因为滥用Pub/Sub导致的惨案：比如消费者因为网络闪断重启，导致丢失了关键的订单状态变更事件；或者消费者处理耗时过长，导致Redis的输出缓冲区无限膨胀，最终把Redis主节点直接OOM（内存溢出）阻塞。Pub/Sub只适合做纯粹的实时通知（如本地缓存失效广播），如果你试图用它来承载任何带有业务语义的数据流，无异于在悬崖边走钢丝。

正是为了填补这块短板，Redis 5.0推出了Stream。在我看来，Stream的诞生，标志着Redis在消息领域完成了从“通知机制”到“可靠数据结构”的惊险一跃。

如果说Pub/Sub是“广播电台”，那么Stream就是“录像带”。从个人体感来看，Stream的底层设计深得Kafka的精髓，但又保留了Redis轻量级的天性。它引入了持久化、消费者组（Consumer Group）和Pending列表（未确认消息列表）这三个杀器。

在处理“旅游电商异步出票”这类不能丢数据的场景时，Stream成为了我的首选。当我向Stream中追加一条消息时，它会自动获得一个全局唯一且单调递增的ID。这意味着即使所有消费者都在此刻宕机，消息依然安静地躺在内存甚至AOF文件中。当消费者恢复，它可以通过消费者组的机制，准确地从上次断开的地方继续拉取。

更让我感到安心的是Stream的ACK机制。在Pub/Sub时代，你根本不知道消息到底有没有被处理完；但在Stream中，消息被读取后会被放入Pending列表，只有当消费者显式地发送ACK，它才会被真正移除。如果某个消费者在处理出票时崩溃了，Stream会死死咬住这条消息，允许其他消费者接管并重新处理。这种“不抛弃、不放弃”的确定性，才是业务系统最需要的基石。

当然，承认Stream的强大，不代表我们要陷入“Redis能干翻一切MQ”的狂热。在实战架构中，我对两者的定位有着极其清晰的边界感。

Pub/Sub依然有它的用武之地，那就是“可以容忍丢失的极致实时性”。比如，在分布式节点间同步本地的路由配置更新，丢一两条无所谓，下一秒还会发，此时Pub/Sub的零延迟和无状态就是最大的优势。

而Stream，则被我严格限制在“核心业务异步链路”中，作为轻量级的事件溯源或任务队列。但我也深知它的极限：它毕竟还是受制于Redis单节点的内存容量，无法像Kafka那样将海量消息持久化到磁盘；在极致的吞吐量和跨数据中心的复制上，它依然无法替代专业的消息中间件。

总而言之，从Pub/Sub到Stream的演进，折射出的是我们在构建分布式系统时，从“追求快”到“追求准”的心智成熟。理解了这两者的底层差异，你就不会再在错误的地方使用错误的工具。真正的架构师，不是能画出最复杂的组件图，而是能在一把简单的瑞士军刀中，精准地抽出最合适的那一截刀刃，去解决恰到好处的业务痛点。