消息队列高频考点核心是解耦、异步、削峰三大作用：解耦实现服务间松耦合，异步提升响应速度，削峰缓冲流量洪峰；并需掌握消息可靠性（确认机制+手动提交）、幂等性防重、分组有序保序等落地要点。
面试官问“消息队列高频考点怎么答”，其实不是考你背了多少概念，而是看你懂不懂它在真实业务里到底起什么作用、踩过什么坑、怎么兜住底。用大白话讲，就三件事：解耦、异步、削峰——其他所有问题，基本都是围绕这三点展开的。
一、解耦：让系统之间“互不打扰”
比如A系统要通知B、C、D三个系统某条订单生成了。以前是A直接调接口，B挂了A得重试，C改接口了A得跟着改，E系统突然也要这个数据？A还得加代码……太累。
换成消息队列后，A只管把消息发到MQ，就像往快递柜扔个包裹；B、C、D各自去取，谁要谁取、谁不想要就取消订阅，A完全不用知道后面是谁、有几个、有没有挂。系统之间不再“手拉手”，而是“各干各的”。
二、异步：别让用户干等着
用户下单，A系统写完自己库（30ms），还要同步调B系统发短信（200ms）、C系统更新积分（300ms）、D系统推消息（150ms）——总共680ms，页面卡半天。
用MQ后，A写完本地库，把发短信、更新积分、推送这些事打包成几条消息丢进队列，立刻返回“下单成功”。后面的事由B、C、D自己慢慢处理，用户零感知，响应时间从680ms降到30ms。
三、削峰：给流量踩刹车
秒杀开始那一秒，10万请求涌进来，但库存服务每秒最多处理5000次扣减。硬扛？直接崩。
MQ在这里就是个“缓冲池”。前端把请求转成消息塞进去，库存服务按自己节奏一条条消费——哪怕积压1小时，只要最终都处理完，系统就不垮。相当于把“洪水”变成“细水长流”。
顺带说清几个常被追问的点
消息丢了怎么办？ 生产者发消息时开启确认机制（如RocketMQ的SYNC_FLUSH），MQ落盘成功才回ACK；消费者处理完再手动提交offset，别自动提交。
重复消费怎么防？ 关键是幂等。比如扣库存，加个唯一业务ID做数据库唯一索引；发优惠券，先查是否已发再插入；或者用Redis记录已处理ID，消费前先判断。
顺序乱了怎么保？ 单队列+单消费者最简单，但吞吐低；更常用的是“分组有序”——比如用订单ID做key，保证同一订单的所有消息进同一个partition或queue，再由一个消费者串行处理。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
