系统设计:消息队列为什么需要、怎么选

先抛一个常见的线上事故:

秒杀活动开始,瞬时 QPS 从几百冲到 5 万,下游订单服务直接 OOM,数据库连接池打满,整条链路雪崩。

复盘时你会发现,这种问题的根因往往不是单点性能不够,而是上下游速率不匹配。上游一阵猛冲,下游来不及消化,整个系统就被冲垮。

消息队列(Message Queue,下称 MQ)就是来解决这个问题的。它本质上是分布式系统里的"减震器"和"缓冲池"——把同步调用换成异步投递,把直连换成通过 Broker 中转。看起来只是多了一层,但它改变了系统的耦合方式、吞吐模型和容错边界。

这篇文章我尽量讲透四件事:它到底解决了什么问题、可靠性怎么保证、顺序和重复怎么取舍、主流产品怎么选。

一、消息队列解决什么问题

很多人把 MQ 当成"先进先出的队列",这没错,但太表层。真正驱动你引入 MQ 的,是下面四类工程问题。

1. 削峰填谷(最常见)

这是 MQ 最直接的价值。上游有突发流量(秒杀、推送、爬虫抓取、日志上报),下游处理能力有限。中间放一个队列,让流量先排队,下游按自己的节奏消费。

瞬时 5w QPS  →  [ Queue (堆积) ]  →  下游稳定 2k QPS

关键认知:MQ 不是让你处理得更快,而是让你不被打死。容量规划从"扛住峰值"变成"扛住平均值",成本数量级下降。

2. 解耦

同步调用意味着上游必须知道下游的存在、地址、接口、可用性。任何一个下游挂掉,上游跟着报错。

经典场景:用户注册后,要发短信、发邮件、发优惠券、写积分、推送到 CRM。如果都是同步 RPC,五个下游任何一个超时都会让注册接口变慢甚至失败。

放进 MQ 之后,上游只管扔一条"用户注册了"的事件,谁关心谁订阅。新增下游不用改上游代码,下游宕机也不影响主流程。系统的扩展边界从代码耦合变成了配置订阅。

3. 异步化

有些操作天然不需要等结果:埋点上报、日志收集、风控记录、消息推送。同步做这些既浪费 RT,又放大了失败影响面。

异步化之后,接口响应时间从"所有下游耗时之和"变成"投递到 MQ 的耗时"(通常个位数毫秒)。用户体验的差距可能是 800ms vs 50ms。

4. 最终一致(配合事务消息)

强一致用数据库事务,跨服务强一致用 2PC/TCC(又重又容易错)。而很多业务场景其实只要求"最终一致":只要这条数据最终能被对端处理到就行。

MQ 的"本地事务 + 消息投递"模式,是分布式最终一致性的标准解法之一。RocketMQ 的事务消息、Kafka 的事务producer,都是为这种场景设计的。

一句话总结:MQ 不是性能优化工具,是系统架构的解耦和缓冲层。引入它通常是为了换可用性、换扩展性、换系统的"韧性"。

二、两种核心模型:点对点 vs 发布订阅

所有 MQ 的语义模型,基本都能归到这两种。

点对点(Point-to-Point)

一条消息只会被一个消费者消费。

Producer → [Queue] → Consumer A (消费后消息删除)
                  ↘ Consumer B (拿不到这条)

典型场景:订单处理、任务分发、-worker 池。多个消费者组成一个消费组竞争消费,目的是提高吞吐,不是广播。

发布订阅(Pub/Sub)

一条消息会被所有订阅者各自消费一份。

Producer → [Topic] → 订阅者 A (收到一份)
                  → 订阅者 B (收到一份)
                  → 订阅者 C (收到一份)

典型场景:领域事件广播。比如"订单已支付"这个事件,物流系统、积分系统、风控系统、数据仓库都要各自处理一份。

实际产品里这两种模型是融合的。Kafka 的 consumer group 机制很妙:同一个 group 内竞争消费(点对点),不同 group 之间各自消费全量(发布订阅)。一套机制两种语义都覆盖了。

选型时先想清楚:你的下游是"一群竞争者"还是"一群旁观者"。这决定了你用 Queue 还是 Topic,用 group 还是 fanout。

三、可靠性:别丢消息是底线

MQ 最容易翻车的地方就是可靠性。线上丢一条关键消息(比如支付成功事件)可能就是几万块的资损。可靠性是一个组合拳,缺一不可。

1. 持久化(Persistence)

消息落到磁盘,而不是只放内存。Broker 宕机重启后,未消费的消息不能丢。

• Kafka:所有消息按日志追加写盘,可配置副本数(replication.factor=3)和 ack 策略(acks=all)。
• RabbitMQ:队列要声明为 durable,消息要设置 delivery_mode=2,否则重启即丢。
• Redis Streams:靠 Redis 的 RDB/AOF 持久化,但 Redis 默认持久化是异步的,崩溃可能丢秒级数据,这点要心里有数。

同步刷盘 vs 异步刷盘是个关键取舍。同步刷盘性能差但更可靠,异步刷盘性能好但机器断电可能丢。金融类业务选前者,日志类业务选后者。

2. 生产端确认(Producer ACK)

生产者投递后,Broker 要回确认。没确认就不知道消息到没到。

• Kafka:acks=0(发了就当成功,fire and forget)/ acks=1(leader 写入即确认)/ acks=all(ISR 副本都写入才确认)。
• RabbitMQ:发布确认(publisher confirm)机制。

重要数据用 acks=all + 重试 + 幂等 key,不要图快用 acks=0,出了事你根本不知道丢了多少。

3. 消费端 ACK 与重试

消费者处理完一条消息,必须显式告诉 Broker"我处理完了",Broker 才会删消息。这叫 ACK(确认)。

如果消费者拿到消息后崩溃、或者抛异常没 ACK,Broker 会把这条消息重新投递给其他消费者——这叫 重投(redelivery)。

注意 ACK 的时机,两种常见模式:

• 处理完再 ACK(at-least-once,推荐):消息可能被重复消费,需要业务幂等。
• 拿到就 ACK(at-most-once):性能好,但处理失败消息就丢了。

大多数业务场景选前者。ACK 是消费侧可靠性的最后一道闸,关掉它等于裸奔。

4. 死信队列(Dead Letter Queue,DLQ)

消息消费失败,不能无限重试,否则一条毒消息能把整个消费链路卡死。标准做法是:重试 N 次仍失败,把它丢到 DLQ,人工介入或离线处理。

• RabbitMQ:原生支持 x-dead-letter-exchange。
• Kafka:没有内建 DLQ,通常消费端自己实现——捕获异常后写到另一个 topic。
• RocketMQ:有专门的死信 topic(%DLQ%consumerGroup)。

DLQ 是线上稳定性的救命稻草,任何严肃的 MQ 消费代码都必须配套 DLQ 策略。没有 DLQ 的消费者都是定时炸弹。

5. 幂等消费(业务侧兜底)

由于重投机制存在,同一条消息可能被消费多次。消费逻辑必须是幂等的,否则就会出现重复扣款、重复发货、重复发短信这种事故。

实现幂等的常见手段:

• 业务唯一键 + 数据库唯一约束(插入冲突即跳过)。
• Redis/DB 记录已处理消息 ID,消费前查重。
• 状态机校验(订单已支付,再来一条"支付成功"直接忽略)。

幂等是消费可靠性的业务层补充,光靠 MQ 保证不了"恰好一次"(下面会讲为什么)。

四、顺序与重复:分布式永恒的取舍

顺序问题

全局顺序:所有消息严格按生产顺序消费。代价极大——只能一个分区、一个消费者,完全丧失并行能力。除非常特殊场景(比如金融事件回放),不要追求全局顺序。

分区顺序(Partition Order):同一 key 的消息进同一分区,分区内有序。这是工程上的标准答案。

举例:订单事件按 orderId 做 partition key,那么同一个订单的"创建 → 支付 → 发货 → 签收"一定按顺序到达同一个消费者,业务顺序保证;不同订单之间可以并行。

Kafka、RocketMQ、Pulsar 都是这个模型。别要全局顺序,要分区顺序,你 99% 的场景都够用。

重复问题

MQ 的投递语义分三种:

行业里公开的秘密:真正端到端的 exactly-once 几乎不存在,或者说代价高到通常不值得。Kafka 的"exactly-once"是 broker + producer + consumer 之间的事务协调,但你的业务真的"恰好一次"还需要下游数据库幂等配合——绕了一圈,本质还是 at-least-once + 幂等。

所以工程实践是:默认 at-least-once,在业务层做幂等,模拟出 exactly-once 的效果。这是最务实、性价比最高的方案。

五、主流 MQ 怎么选

四款主流产品,各有性格。我按"它最适合做什么"来区分。

Kafka:吞吐王,流处理首选

• 强项:单机十万级 TPS,顺序写盘 + 零拷贝,生态最强(Streams、Connect、Flink 对接),分区顺序保证。
• 弱项: topic 数量多了之后(Zookeeper/KRaft 元数据)有压力;不适合复杂的路由;消息默认按策略删除而非消费完即删。
• 典型场景:日志收集、行为埋点、实时数仓、事件溯源、CDC 数据管道、流式计算。
• 一句话:只要是"高吞吐 + 顺序流",选 Kafka 基本不会错。

RabbitMQ:灵活路由,传统业务消息

• 强项:AMQP 协议,路由能力极强(exchange + routing key + binding),延迟低(毫秒级),优先级队列、TTL、DLX 等功能完备,管理界面好用。
• 弱项:吞吐比 Kafka 低一个数量级;消息堆积能力弱(堆积多了性能急剧下降);集群伸缩没 Kafka 自然。
• 典型场景:订单异步处理、任务分发、复杂路由(比如按类型路由到不同队列)、需要请求/响应(RPC over MQ)。
• 一句话:业务消息优先选 RabbitMQ,功能齐全,语义清晰。

Redis Streams:轻量级,顺手就用

• 强项:部署简单(已在用 Redis 就够了),消费组、ACK、持久化都有,接入成本低。
• 弱项:可靠性边界模糊(Redis 持久化是异步的,极端情况可能丢秒级数据);不适合大体量堆积;运维工具不如 Kafka/RabbitMQ 成熟。
• 典型场景:中小项目内部异步任务、用户通知、轻量事件总线。
• 一句话:别拿它扛核心交易,做"差不多就行"的异步足够了。

RocketMQ / Pulsar:国内大厂和金融场景

• RocketMQ:阿里出品,Java 实现,事务消息做得最完整(半消息 + 回查机制),金融/电商订单场景特别好用。国内文档、生态成熟。
• Pulsar:计算存储分离架构,多租户隔离强,支持 geo-replication。架构先进但运维复杂度高。

一句话:RocketMQ 在国内做电商、交易类业务很好用;Pulsar 偏面向超大规模、多租户的平台型场景。

场景选型表

选型原则:别看榜单选,看场景选。没有最好,只有最合适。

六、常见陷阱(踩过的都懂)

最后列几个我见过最多的翻车点,前三个都是高频线上事故。

1. 消息堆积不报警

下游消费慢或挂了,消息在队列里堆积。等你发现的时候已经堆了几千万条,SLA 早炸了。

对策:监控队列深度(consumer lag),设阈值告警;评估下游处理能力的下限,而不是平均值。

2. 丢消息(没持久化 / 没正确 ACK)

最经典的低级错误。RabbitMQ 队列没声明 durable、生产者没开 confirm、消费者拿到就 ack——任何一个疏忽都能丢消息。

对策:核心链路一律 durable + confirm + 手动 ack + acks=all,配置项要 Code Review。

3. 消费没做幂等

重投 + 非幂等 = 重复扣款、重复发货。这是资损事故,比系统挂了还严重。

对策:所有消费逻辑默认按"可能被重复消费"来设计,业务唯一键 + 去重表是标配。

4. 单分区性能瓶颈

某个 partition key 的数据量过大(比如某个大客户的埋点),导致单个分区消费跟不上,而其他分区闲置。

对策:partition key 设计要避免热点;监控分区消费延迟;必要时重新分片。

5. 把 MQ 当数据库用

业务逻辑依赖于"消息一定按顺序、一定不丢、一定能查"。但 MQ 的设计目标是传输,不是存储。消息保留时间到了就被清掉。

对策:业务一致性靠业务系统自己保证(数据库 + 状态机),MQ 只负责传输。

6. 无脑上 Kafka

很多团队不管什么场景都用 Kafka,简单订单消息也上 Kafka,运维成本和收益完全不成比例。

对策:中小业务 RabbitMQ 一把梭,别给自己找麻烦;真要 Kafka 之前先问一句"我需要百万级 TPS 吗"。

小结

写到这里,几条要点浓缩一下:

1. MQ 解决的是耦合、速率、异步三件事,不是性能优化。引入前先想清楚是为哪个问题引入的,否则只是徒增复杂度。
2. 可靠性是组合拳:持久化 + 生产 ACK + 消费手动 ACK + 重试 + DLQ + 幂等消费,六件套缺一不可。任何一个环节漏了都可能是事故。
3. 顺序选分区顺序,别追求全局顺序;投递语义默认 at-least-once,业务层做幂等就是工程上最务实的"恰好一次"。
4. 选型看场景:日志/流选 Kafka,业务消息/复杂路由选 RabbitMQ,事务消息选 RocketMQ,轻量场景用 Redis Streams。
5. 陷阱永远来自细节:堆积监控、持久化、幂等——这三件事你做对了,90% 的 MQ 事故就不会发生。

最后送一句金句:

消息队列不是银弹,它是"用复杂度换韧性"的交易。能不用就不用,要用就用得专业——可靠性从来不是配置项,是设计哲学。

下一篇我们聊聊"系统设计:限流与熔断",看看流量进来之后该怎么挡。