主题
面试速答（先看这里）
**一句话结论：**想要尽量确保消息的可靠性，可以用本地消息表或者事务消息：
60秒标准回答：
在使用消息队列时，虽然它能有效解耦系统、削峰填谷、提升异步处理能力，但实际工程中也存在不少“坑”
不管是哪种MQ，用了什么样的方案，都只能尽可能的保障消息不丢，但是都没办法彻底解决消息丢失的问题，在极限情况下，消息还是可能会丢的
想要尽量确保消息的可靠性，可以用本地消息表或者事务消息
**答题顺序：**结论 → 原理/机制 → 关键流程 → 场景与取舍 → 易错点
回答主线：
- **要点1：**在使用消息队列时，虽然它能有效解耦系统、削峰填谷、提升异步处理能力，但实际工程中也存在不少“坑”
- **要点2：**不管是哪种MQ，用了什么样的方案，都只能尽可能的保障消息不丢，但是都没办法彻底解决消息丢失的问题，在极限情况下，消息还是可能会丢的。
- **要点3：**在MQ的使用中，尤其是消费者端，最常见的问题就是消息重复了，这个问题发生的原因有很多：
- **要点4：**都有可能导致消息重复，所以，这是一个必须要解决的问题，常见的方案就是实现消息的幂等消费。
- **要点5：**消息乱序指的是消息没有按照我们希望的顺序投递，这个也有很多原因，比如发送方就没有按照顺序发送，或者broker投递的时候就不是有序的，或者是消费者处理的时候因为网络延迟啥的就没有保障顺序。
**记忆锚点：**用本地消息表或者事务 → feature → broker → 或者多线程 → topic → SOP
易错提醒：
- 想要尽量确保消息的可靠性，可以用本地消息表或者事务消息： 在MQ的使用中，尤其是消费者端，最常见的问题就是消息重复了，这个问题发生的原因有很多： 1、发送者多发了 2、消息第一次处理失败，又重投了 都有可能导致消息重复，所以，这是一个必须要解决的问题，常见的方案就是实现消息的幂等消费。
追问准备：
- 围绕「用本地消息表或者事务」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「feature」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「broker」：底层原理是什么？使用时有哪些边界和常见坑？
- 如果线上出现异常，你会如何定位、验证并规避？
典型回答
在使用消息队列时，虽然它能有效解耦系统、削峰填谷、提升异步处理能力，但实际工程中也存在不少“坑”
1、丢消息
不管是哪种MQ，用了什么样的方案，都只能尽可能的保障消息不丢，但是都没办法彻底解决消息丢失的问题，在极限情况下，消息还是可能会丢的。
想要尽量确保消息的可靠性，可以用本地消息表或者事务消息：
2、消息重复
在MQ的使用中，尤其是消费者端，最常见的问题就是消息重复了，这个问题发生的原因有很多：
1、发送者多发了
2、消息第一次处理失败，又重投了
都有可能导致消息重复，所以，这是一个必须要解决的问题，常见的方案就是实现消息的幂等消费。
3、消息堆积
相信很多人也都遇到过消息堆积的问题，这个问题也常见，因为MQ的主要功能就是削峰填谷，既然他做了削峰填谷了，那么他必然有消息堆积的能力，不然他怎么做削峰填谷呢？
所以，消息堆积很常见，遇到这个问题，有很多不同的解法，给大家一条解决的SOP：
4、消息乱序
消息乱序指的是消息没有按照我们希望的顺序投递，这个也有很多原因，比如发送方就没有按照顺序发送，或者broker投递的时候就不是有序的，或者是消费者处理的时候因为网络延迟啥的就没有保障顺序。
解决方案也有的，要么是用顺序消息，要么就是自己实现排序
5、消息延迟
这个其实不算啥问题，和消息堆积一样，消息延迟本来就是MQ的一个特性，是个feature，不是个bug，哈哈哈。
想要减少延迟，那么就提升消费速度吧，搞消费者组，用批量消费，或者多线程消费都可以，总之就是让他消费的更快。
6、重平衡
当消费者数量、topic数量等发生变化的时候，MQ会触发重平衡，这时候可能会带来重复消费、乱序、STW等问题。需要重视。