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

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

今天带大家了解了的相关知识，希望对你有所帮助；关于数据库的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~