第七篇：消息队列（MQ）——就是个带存储的异步通信管道

别再背各种MQ的区别了你只需要知道“它就是个中间人A把消息给它它转交给B”写在前面消息队列Message Queue简称MQ是分布式系统里最常用的解耦工具。面试里问到MQ核心就考一件事消息怎么不丢、怎么不重、怎么不积压。MQ的本质是什么就是两个系统之间的**“信箱”** 。A系统把消息放进信箱B系统从信箱里取。A不用管B在不在、能不能处理B也不用管A什么时候发。就这么简单。所有复杂的功能持久化、集群、事务消息都是围绕“信箱怎么更可靠”做的增强。面试时MQ要掌握到什么程度你不需要懂所有MQ的源码但你要能说清选型理由 怎么保证消息不丢 怎么保证不重复消费 消息积压怎么处理。这篇文章就按这个思路来讲。一、MQ解决了什么问题先搞懂“为什么需要”面试官如果问“你们项目里为什么用MQ”你要回答三个核心价值而不是只说“解耦”。① 解耦服务之间不直接依赖A系统完成订单后需要通知B短信、C积分、D物流。如果A直接调用B、C、D的接口B挂了A也跟着报错C改接口A要跟着改代码。引入MQ后A只管发消息B/C/D自己去订阅。A不知道B的存在B挂了不影响A。② 异步非阻塞提升响应速度用户下单后A系统要做扣库存 → 生成订单 → 发短信 → 加积分。如果同步执行用户要等好几秒。引入MQ后A只做核心操作扣库存生成订单然后发一条消息到MQ就返回“下单成功”短信和积分异步执行。用户体验大幅提升。③ 削峰填谷流量洪峰时保护下游双11零点每秒10万下单请求数据库根本扛不住。MQ就像一个缓冲池把请求先存下来下游数据库按自己能承受的速度比如每秒5000条慢慢消费。高峰流量被“削”平了数据库不会被打死。二、核心链路面试就考这一条面试官问MQ的所有问题本质上都围绕着这条链路生产者 → BrokerMQ服务器 → 消费者每个环节都要保证两件事消息不丢、消息不重。2.1 消息不丢怎么保证可靠性① 生产者 → Broker生产者发消息时Broker收到后返回ACK确认。如果生产者没收到ACK就重试最多重试N次超过记录日志人工介入。RocketMQ/Kafka都支持acks参数acks0不等待确认最快但可能丢、acks1Leader确认默认、acks-1/all所有副本确认最安全但最慢。② Broker 存储消息消息到了Broker先刷盘再返回ACK或异步刷盘折中。RocketMQ的刷盘方式SYNC_FLUSH同步刷盘安全但慢和ASYNC_FLUSH异步刷盘快但断电可能丢。Kafka用分区多副本保证消息写入Leader后等ISR同步副本集里的follower都同步完了才返回ACK。③ Broker → 消费者消费者拉取消息处理完业务逻辑后再手动提交offset位移或ACK。绝对不能拉取到消息就自动提交ACK然后业务处理失败了——消息就丢了。正确做法业务处理成功 → 手动提交offset业务处理失败 → 不提交消息会被重新消费或进死信队列。2.2 消息不重幂等性消息队列保证“至少一次At Least Once”投递即消息可能重复但不会丢失。所以消费者必须自己做幂等即同一条消息处理多次和一次效果一样。常见幂等方案数据库唯一索引订单号作为唯一键重复插入报错简单有效。Redis缓存处理状态处理前SETNX如果key已存在说明已处理过直接跳过。业务本身幂等比如“将库存减1”不幂等执行两次变减2但“将库存设为某个值”幂等。三、消息积压消费者扛不住了怎么办场景生产者发消息太快消费者太慢MQ里消息越堆越多。常见原因下游数据库慢SQL没优化、锁表消费者单线程处理没充分利用资源消费者逻辑太重比如每条消息要调多个外部接口解决思路临时扩容消费者增加消费者实例同时增加Topic的分区数Kafka中分区是并行度的上限一个分区只能被一个消费者消费。这是最快速的应急方案。优化消费逻辑批量处理一次拉取100条批量插入数据库、异步化消费时只做最核心的逻辑非核心的异步处理。降级如果积压太严重先丢弃非核心消息保证核心业务能正常消费。排查上游是不是生产者的流量突增能不能上游限流注意队列满了一般不会影响生产者因为MQ有反压机制生产者会阻塞或超时。但积压持续下去磁盘会被写满造成更严重的问题。四、常见MQ选型对比面试必问面试官一定会问“Kafka、RocketMQ、RabbitMQ你们怎么选的”你不需要把三者所有功能都背下来记住核心场景就行对比维度KafkaRocketMQRabbitMQ吞吐量极高百万级/秒高十万级中等万级延迟毫秒级非极端场景毫秒级微秒级最低消息可靠性高副本机制极高同步刷盘事务高事务消息不支持支持不支持但有事务机制顺序消息分区内有序支持支持延迟消息不支持支持支持语言Scala/JavaJavaErlang适用场景日志收集、大数据、流处理业务消息、交易场景、需要事务低延迟业务、灵活路由选型建议面试里你就这么说日志收集、大数据、流处理→ Kafka吞吐量是王道丢一点日志也能接受。金融交易、订单、库存等核心业务→ RocketMQ支持事务消息同步刷盘保证数据绝对不丢Java技术栈好维护。低延迟、复杂路由、中小企业→ RabbitMQ延迟最低路由灵活但吞吐量不如前两者。五、高级特性面试加分项5.1 RocketMQ的事务消息分布式事务解决方案这是RocketMQ独有的能力面试里提到会很加分。问题A扣款成功了发消息给B扣库存。如果消息发失败了A的扣款怎么回滚如果消息发成功了但B扣库存失败了怎么办RocketMQ事务消息的流程A发送一条半消息Half Message到RocketMQ——对消费者不可见相当于“我要开始事务了先占个坑”。A执行本地扣款事务update account set money money - 100 where id 1绑在同一个本地事务里。根据本地事务结果执行二次确认扣款成功 → A向MQ发送Commit指令 → 半消息变为可见B才能消费到这条消息去扣库存。扣款失败 → A向MQ发送Rollback指令 → MQ直接删除半消息B永远收不到。兜底反查机制如果A在执行本地扣款后、发送Commit/Rollback之前突然宕机了怎么办RocketMQ会定时回查A系统“你那条扣款到底成功了没”A根据本地事务状态告诉MQ是Commit还是Rollback。面试官追问“本地事务怎么和发送半消息绑定的”RocketMQ的事务消息本质上把“发送半消息”和“执行本地事务”放在了一个事务里。具体实现生产者定义TransactionListener重写executeLocalTransaction和checkLocalTransaction方法。第一个方法是执行本地事务并返回事务状态COMMIT/ROLLBACK/UNKNOW第二个方法是事务状态未知时的回查逻辑。核心价值这是一种最终一致性方案用消息的可靠投递 本地事务 反查机制保证A扣款和B扣库存最终一致。它牺牲了强一致性允许短暂不一致换来了高可用和高性能。5.2 顺序消息局部有序有些场景要求消息按顺序消费比如订单状态流转创建→支付→发货必须按顺序。Kafka/RocketMQ的实现方式把需要有序的消息发到同一个分区Partition/Queue。一个分区只能被一个消费者消费串行所以消息在分区内是严格有序的。注意这只能保证“局部有序”同一个订单的消息有序不能保证“全局有序”所有订单的所有消息有序。因为不同订单可以走不同分区并行消费。场景订单创建、支付、发货三条消息按orderId做分区键同一个orderId的消息永远进同一个分区串行消费。不同orderId的消息可以并行消费互不影响。5.3 死信队列处理消费失败的消息场景消息消费重试了N次比如16次还是失败不能再重试了否则一直占着队列。处理进入死信队列DLQDead Letter Queue人工介入处理比如修复数据后手动补发消息、或者单独写修复脚本。RocketMQ和RabbitMQ自带死信机制Kafka没有死信概念需要业务自己实现失败的消息打到另一个Topic。5.4 消息幂等 去重高并发必备除了前面说的幂等在高并发场景下还要考虑去重消费者拿到消息后先往Redis里存一个处理标志SETNX key value EX 300key 业务ID 消息ID。如果SETNX返回1说明这条消息没处理过执行业务逻辑。如果SETNX返回0说明已经处理过了或者在处理中直接跳过返回ACK不重试。注意SETNX和业务逻辑如果拆成两步可能存在并发问题A线程查不到标志→去执行业务B线程也查不到→也去执行业务。要在Lua脚本或分布式锁里保证原子性或者直接用数据库唯一索引作为去重手段把“判断是否存在 插入”交给数据库的INSERT IGNORE或唯一约束来处理。六、面试官真正想听什么场景1“你们项目里用的什么MQ为什么”普通回答“RocketMQ。”加分回答“我们做的是订单交易系统对数据一致性要求很高。RocketMQ的事务消息能帮我们保证订单和库存的最终一致性而且它是Java写的出问题了团队能看懂源码。Kafka虽然吞吐量更大但不太适合事务场景。RabbitMQ的Erlang栈维护成本高我们没选。”场景2“RocketMQ事务消息你们怎么用的”加分回答真实感“下单场景订单服务先发半消息然后在本地事务里扣库存、生成订单。本地事务提交后就发Commit库存服务消费到消息扣减库存。如果订单服务挂了RocketMQ会回查我们提供的checkLocalTransaction接口我们根据订单号查数据库状态返回Commit或Rollback。这套方案保证了最终一致性上线后没出现过数据不一致的问题。”场景3“遇到过消息积压吗怎么处理的”加分回答“有次大促下游的积分服务消费太慢每次都要调外部接口消息积压了几十万条。我们紧急做了两件事一是给积分服务扩容了3个实例同时给Topic加了分区二是在消费逻辑里把批量调接口改成了异步缓存。半小时内积压清空了。”场景4“消息重复消费过吗”加分回答“有一次消费者在业务处理完成后、提交offset之前宕机了重启后消息被重新消费导致数据重复比如积分加了两次。后来我们引入了幂等机制每条消息带唯一ID处理前用Redis的SETNX做去重业务逻辑里也用数据库唯一索引兜底。之后就再没出现过重复问题。”小结核心概念大白话面试考点解耦A不知道B的存在MQ解决的核心问题之一异步核心逻辑先做完非核心慢慢来用户体验提升削峰把高峰流量存起来慢慢放保护下游数据库消息不丢ACK 持久化 手动提交各环节怎么保证可靠消息不重消费者幂等唯一ID、Redis去重消息积压消费太慢队列堆满了扩容消费者 优化消费逻辑Kafka高吞吐日志场景选型理由RocketMQ事务消息交易场景半消息 本地事务 反查RabbitMQ低延迟路由灵活选型理由死信队列重试N次失败后的归宿人工介入处理记住一句话MQ就是个带存储的异步通信管道面试围绕的核心就是——怎么让消息安全地从A到B不丢、不重、不怕压。下一篇我们讲Spring Boot——自动配置的原理到底是什么IoC容器就是个MapAOP的代理是怎么生成的把Spring的底裤也扒干净。下期见。