Pub/Sub是无存储的实时广播机制，消息断连即丢，适合允许丢失的在线通知；Stream是带ACK的持久化消息队列，支持回溯、消费者组和精确控制，但需手动管理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
真正做选型时，别纠结“哪个更先进”，先问自己：这条消息丢了能不能接受？消费者是不是总在线？要不要查三天前某笔订单的触发记录？答案一出来，路径就清晰了。
