Redis5.0Stream与Pub/Sub对比分析

Redis的Pub/Sub和Stream看似都是消息传递机制，实则本质迥异：Pub/Sub是零存储、无状态的实时广播喇叭，消息一发即逝，断连即丢，只适用于允许丢失、消费者始终在线的轻量通知场景；而Stream则是带持久化、ACK确认、消费者组和时间序ID的挂号信系统，支持消息回溯、精确消费控制与故障恢复，但需手动管理XACK、MAXLEN等细节以避免内存泄漏或性能退化——选型关键不在技术优劣，而在于明确业务底线：消息能否丢失？消费者是否稳定在线？是否需要历史追溯？答案直接决定该用“即时喊话”还是“可查可签收的正式信函”。

Stream 和 Pub/Sub 不是“选哪个更好”，而是“根本不是同一类东西”——Pub/Sub 是广播喇叭，Stream 是带签收的挂号信系统。

Pub/Sub 没有消息存储，断连即丢

Pub/Sub 的 PUBLISH 命令发出去后，Redis 不存这条消息。如果此时没有任何 SUBSCRIBE 连接在线，或者订阅者网络中断、进程崩溃，那这条消息就彻底消失了。它不写 AOF，不进 RDB，不占内存结构，纯内存中一闪而过。

常见错误现象：

• 测试时一切正常，上线后偶发“通知没收到”，查日志发现订阅客户端曾短暂断开
• 用 redis-cli 手动 SUBSCRIBE 能收到，但程序里用 pubsub.listen() 却收不到——大概率是没处理连接重试或消息循环阻塞

适用场景仅限于：实时性压倒一切、允许丢失、且消费者始终在线（如 WebSocket 心跳广播、开发环境日志推送）。

Stream 支持消费者组和 ACK，但必须显式管理

Stream 的可靠性不是自动来的，得靠你主动调用 XGROUP CREATE、XREADGROUP、XACK 三步闭环。漏掉 XACK，消息就会卡在 PEL（Pending Entries List）里，下次 XREADGROUP 还会再推给你——这既是重试机制，也是内存泄漏源头。

关键实操要点：

• XREADGROUP 的起始 ID 写 > 表示只读新消息；写 0-0 表示重读所有未确认消息（适合消费者重启后兜底）
• 消费者组名和消费者名要区分清楚：XGROUP CREATE mystream mygroup 0 中 mygroup 是组，consumer1 是具体实例名，后者在 XREADGROUP 里才出现
• 不调 XACK 的后果不是“消息重复”，而是“PEL 不断膨胀”，最终拖慢整个 Stream 的读取性能

Stream 消息 ID 是时间戳+序列，不能自定义

你无法控制 XADD 生成的 ID，它是 millisecondsTime-sequence 格式（如 1743405096987-0）。这意味着：

• ID 天然有序，支持按时间范围回溯：XRANGE mystream 1743405000000-0 +
• 不能用业务主键当 ID，也不能填字符串或数字——填错会直接报错 ERR Invalid stream ID specified as stream command argument
• 想让消息“按插入顺序严格递增”，就得确保同一毫秒内不超过 999999 条，否则 sequence 会溢出（实际极少遇到）

对比之下，Pub/Sub 根本没有 ID 概念，自然也谈不上回溯或范围查询。

Stream 占内存多，Pub/Sub 几乎不占

Stream 每条消息都持久化在内存链表中，字段数越多、值越长，占用越大。一个含 5 个字段、平均值长度 200 字节的消息，10 万条就接近 100MB。而 Pub/Sub 的 PUBLISH 调用完，内存瞬间释放。

容易被忽略的点：

• Stream 不会自动清理旧消息，必须配合 MAXLEN 参数：XADD mystream MAXLEN ~ 1000 * field value，否则内存只增不减
• 用 XTRIM 手动清理不如建流时就设 MAXLEN，因为前者是 O(N) 操作，可能阻塞主线程
• Pub/Sub 看似轻量，但大量频道 + 高频发布时，Redis 的事件循环压力会上升，表现为 latency spikes

真正做选型时，别纠结“哪个更先进”，先问自己：这条消息丢了能不能接受？消费者是不是总在线？要不要查三天前某笔订单的触发记录？答案一出来，路径就清晰了。

今天关于《Redis5.0Stream与Pub/Sub对比分析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！