Redis 里有 Pub/Sub，也有 Stream，很多人会把它们都归到“消息”这一类。但它们解决的是两个完全不同的问题。
Pub/Sub 像广播：订阅者在线就收到，不在线就错过；Stream 像日志：消息写进结构里，消费者可以按 ID 读取、确认和重试。
先把机制边界说清楚
这一篇讨论消息语义，不讨论具体客户端封装。关键判断是：你要临时通知，还是要可追溯、可重放、可确认的事件流。
整体路径
上面这张图先把主线铺开：一个是在线广播，一个是可追溯日志。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- Pub/Sub 维护 channel/pattern 到客户端的订阅关系，消息不会为离线客户端保留。
- 慢消费者会积压输出缓冲，严重时被服务器断开。
- Stream 把消息写入数据结构，读取位置由客户端或消费组状态维护。
- Redis Cluster 下还要区分普通 Pub/Sub 和分片 Pub/Sub 的路由范围。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
Pub/Sub 轻、快、简单；Stream 重一些，但有状态。把关键订单消息放进 Pub/Sub，是把可靠性寄托在客户端永远在线上。
典型问题：用机制化例子排查
- 配置广播、在线通知、局部失效消息适合 Pub/Sub。
- 订单、支付、积分、库存这类需要重试和审计的事件，用 Stream 或专业 MQ。
- Pub/Sub 要监控输出缓冲，防止慢消费者拖垮连接。
- Stream 要监控 pending 和裁剪策略，防止消息日志无限增长。
收束：一句判断
广播解决“现在告诉你”，日志解决“以后还能查”。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
