Redis Pub/Sub 消息顺序是「通道内有序，跨通道不保证」
Redis 的 SUBSCRIBE 机制对单个 channel 内的消息严格按发布顺序投递，这是由其内部事件循环和客户端缓冲区 FIFO 特性决定的。但这个“有序”非常脆弱——它只在连接存活、无重连、无订阅延迟的前提下成立。
常见错误现象包括：订阅者断连后重连，SUBSCRIBE 会重新建立连接，但断连期间所有消息彻底丢失；多个 channel 之间无全局序号，无法做跨 channel 的时序对齐；发布端用 PUBLISH channel1 msg1 和 PUBLISH channel2 msg2，消费者无法判断哪个先发。
使用场景上，它适合「实时广播类通知」，比如聊天室新消息、系统告警推送，但不适合需要严格时序保障的业务流程（如订单状态流转、资金流水同步）。
Stream 的 XADD + XREADGROUP 才真正支持可追溯的顺序消费
Redis Stream 是为解决 Pub/Sub 的不可靠性而生的：每条消息自带唯一 ID（形如 1743892210123-0），由时间戳 + 序列号组成，天然具备全局单调递增特性。这意味着即使多个生产者并发写入，也能通过 ID 排序还原真实发生顺序。
关键参数差异：
XADD stream_name * field value 中的 * 让 Redis 自动生成 ID；显式指定 ID（如 1743892210123-1）可用于回填或测试XREADGROUP GROUP g1 c1 COUNT 1 STREAMS stream_name > 中的 > 表示只读未分配消息，0-0 可读历史全部未确认消息消费者组（GROUP）自动维护每个消费者的 PEL（Pending Entries List），记录已派发但未 XACK 的消息 ID
性能影响：Stream 写入比 Pub/Sub 略慢（因要落盘+生成 ID），但读取可阻塞/非阻塞、支持多消费者组并行消费同一份数据，且不丢消息。
为什么不能只靠 XREAD 而必须用 XREADGROUP 来保序消费？
单独用 XREAD 是单消费者模型，没有状态跟踪，无法区分“没读过”和“读过但失败”，更谈不上重试与确认。而 XREADGROUP 把消费进度绑定到消费者组+客户端名，让 Redis 主动管理偏移量。
容易踩的坑：
忘记调用 XACK stream_name g1 <id>，导致 PEL 不断膨胀，内存泄漏消费者处理超时后崩溃，消息卡在 PEL 里，需配合 XCLAIM 抢占超时消息用错 ID 格式：比如传字符串 "1743892210123" 而不是完整 ID "1743892210123-0"，XACK 会静默失败误以为 MAXLEN ~ 1000 能自动清理 PEL——其实它只限制主消息流长度，PEL 独立存在
Pub/Sub 和 Stream 在顺序性上的本质区别是「有无持久化状态」
Pub/Sub 是纯内存管道，像广播电台：开播才听见，关机就错过，频道之间互不认得。Stream 是带日志的邮局：每封信编号、存档、可查投递记录、支持签收回执。
复杂点在于，Stream 的顺序性依赖 ID 的生成逻辑和消费者组的生命周期管理。如果你的业务要求“绝对不丢 + 严格时序 + 可重放”，就必须放弃 Pub/Sub，哪怕它写起来更短；而一旦选了 Stream，XGROUP CREATE、XREADGROUP、XACK 这三步一个都不能少，漏掉任意一环，所谓的“顺序消费”就只剩心理安慰。
评论(0)