Redis Stream 和 Pub/Sub 有什么区别？能替代消息队列吗？

简化版

Pub/Sub 是实时广播，订阅者离线就收不到历史消息；Stream 是可持久化的消息日志，支持消费组、消息 ID、ACK 和待处理列表，更接近轻量消息队列。但 Redis Stream 仍不等同于专业 MQ，复杂路由、海量堆积和强治理能力要谨慎。

详细版

Redis Pub/Sub 适合在线通知、实时广播、配置变更等轻量场景。它不保存消息，消费者断开期间的消息会丢。

Redis Stream 类似追加日志，消息有递增 ID，可以按范围读取，也支持消费组：

• XADD 写入消息。
• XREAD 读取消息。
• XGROUP 创建消费组。
• XACK 确认消息。
• PEL 保存已投递但未确认消息。

Stream 可以承担轻量异步任务、事件流、简单削峰，但面对跨机房高可靠、复杂重试死信、长时间海量堆积、复杂路由时，Kafka/RocketMQ/RabbitMQ 更合适。

完整版教学

一、先区分“广播”和“消息日志”

Pub/Sub 的核心是广播。发布者把消息发到 channel，当前在线订阅者收到。它更像直播间喊话，人在就听到，人不在就错过。

Stream 的核心是日志。消息追加到 stream key 中，有 ID、有顺序、有历史记录，消费者可以从某个 ID 往后读。它更像一本持续追加的账本。

记忆钩子：Pub/Sub 像喊话，Stream 像记账；喊话不补课，记账能翻历史。

二、Pub/Sub 的工作方式和限制

Pub/Sub 使用 PUBLISH、SUBSCRIBE、PSUBSCRIBE。服务端收到消息后推给当前订阅者，不负责保存，也没有 ACK。

Publisher -> Channel -> 当前在线 Subscriber

这意味着消费者断线、网络抖动、处理失败时，消息没有内建重投机制。它适合“不强依赖每条必达”的场景，比如后台通知、缓存刷新广播、在线状态通知。

三、Stream 的消息模型

Stream 用 XADD 追加消息，每条消息有类似 1690000000000-0 的 ID。消费者可以用 XREAD 从指定 ID 读取，也可以用消费组分摊处理。

XADD orders * orderId 100 status paid
XREAD COUNT 10 STREAMS orders 0

消息 ID 让 Stream 能表达“从哪里开始消费”。这点是它区别于 Pub/Sub 的关键。

四、消费组、ACK 和 PEL

消费组让多个消费者共同消费同一个 Stream。同一组内，一条消息通常分配给一个消费者处理。消费者处理完后用 XACK 确认。

如果投递后没有 ACK，消息会进入 PEL，也就是 pending entries list。后续可以通过 XPENDING、XCLAIM 或自动 claim 机制找回超时未确认消息。

Stream -> Consumer Group
          |-- C1 处理 msg1 后 XACK
          |-- C2 处理 msg2 但未 ACK -> PEL

这让 Stream 具备了轻量可靠消费能力。

五、和专业 MQ 的差距

Stream 能做消息队列，但不是所有场景都适合。专业 MQ 通常有更完整的主题治理、分区扩展、死信队列、重试策略、堆积治理、消费位点管理和跨集群能力。

能力	Redis Stream	Kafka/RocketMQ 等
轻量异步任务	适合	适合
消费组	支持	支持更完整
海量长期堆积	谨慎	更适合
复杂路由死信	需要自建	通常内建
运维治理	较轻	更系统

如果只是小规模异步任务，Stream 很方便；如果是核心交易消息链路，要评估可靠性和运维能力。

六、消息堆积和内存风险

Redis 是内存数据库，Stream 消息堆积会占用内存。即使启用持久化，线上仍要控制长度，例如 XADD MAXLEN 或定期裁剪。

假设每条消息平均 1 KB，每秒 5000 条，1 小时就是约 18 GB 原始消息量。这个量如果全部压在 Redis 内存里，风险很高。

5000 条/秒 * 3600 秒 * 1 KB ≈ 18 GB

所以 Stream 用作队列时必须设计保留策略、消费者告警和堆积上限。

七、场景选择怎么回答

如果业务是在线广播，选 Pub/Sub；如果需要可追溯、可确认、可消费组分摊，选 Stream；如果要大型消息平台能力，选专业 MQ。

场景	推荐
在线通知	Pub/Sub
简单异步任务	Stream
订单交易可靠消息	专业 MQ
日志采集海量流	Kafka

面试时不要绝对说 Stream 可以替代 MQ，应该说能覆盖轻量队列场景，但要看可靠性、堆积量和治理需求。

八、常见误区与追问

• 误区：Pub/Sub 能保证离线消息不丢。 Pub/Sub 不保存历史消息，订阅者离线期间收不到。
• 误区：Stream 有 ACK 就等于专业 MQ。 ACK 只是可靠消费的一部分，还缺少很多治理能力。
• 误区：Redis 持久化开启后消息就绝对安全。 RDB/AOF 策略、主从复制延迟和故障切换仍会影响可靠性。
• 追问：PEL 是什么？ PEL 保存已投递但未确认消息，用于发现和转移超时消息。
• 追问：Stream 如何防止无限增长？ 使用 MAXLEN、定期裁剪、消费堆积告警和容量规划。
• 追问：什么时候不用 Stream？ 海量堆积、强顺序分区、复杂重试死信、跨集群治理要求高时优先专业 MQ。

九、加强记忆

记住“Pub/Sub 管实时广播，Stream 管可确认日志，MQ 管重型消息平台”。这三个层次不要混。

答题时从是否保存历史、是否支持消费组、是否 ACK、是否适合堆积四个维度对比，面试官基本会认可。