消息队列MQ的消息丢失、重复、积压

一、消息队列的使用场景

    1、系统解耦,不同系统之间信息交互

    2、流量控制，削峰

二、消息队里使用的缺点

     1、系统解耦,分布式,带来了数据一致性问题,数据丢失与重复

     2、流量控制，也会导致消息堆积的问题

三、在使用 MQ 消息队列时，如何确保消息不丢失？

      首先，要分析几个点吧，比如：

      如何知道有消息丢失？

      哪些环节可能丢消息？

      如何确保消息不丢失？

      一条消息从生产到消费完成这个过程，可以划分三个阶段，分别为消息生产阶段，消息存储阶段和消息消费阶段。

     消息生产阶段：

        从消息被生产出来，然后提交给 MQ 的过程中，只要能正常收到 MQ Broker 的 ack 确认响应，就表示发送成功，所以只要处理好返回值和异常，这个阶段是不会出现消息丢失的。

      消息存储阶段：

        这个阶段一般会直接交给 MQ 消息中间件来保证，要了解它的原理，比如 Broker 会做副本，保证一条消息至少同步两个节点再返回 ack（这里涉及数据一致性原理），消息队里自带的持久化等。

       消息消费阶段：

        消费端从 Broker 上拉取消息，只要消费端在收到消息后，不立即发送消费确认给 Broker，而是等到执行完业务逻辑后，再发送消费确认，也能保证消息的不丢失。

        但在分布式系统中，故障不可避免，作为消费生产端，你并不能保证 MQ 是不是弄丢了你的消息，消费者是否消费了你的消息，所以，还是需要一种机制，来 Check 消息是否丢失了。

解决思路：

        在消息生产端，给每个发出的消息都指定一个全局唯一 ID，或者附加一个连续递增的版本号，然后在消费端做对应的版本校验。

        在生产端发送消息之前，通过拦截器将消息版本号注入消息中（版本号可以采用连续递增的 ID 生成，也可以通过分布式全局唯一 ID生成）。然后在消费端收到消息后，再通过拦截器检测版本号的连续性或消费状态，这样实现的好处是消息检测的代码不会侵入到业务代码中，可以通过单独的任务来定位丢失的消息，做进一步的排查。（注意：如果同时存在多个消息生产端和消息消费端，通过版本号递增的方式就很难实现了，因为不能保证版本号的唯一性，此时只能通过全局唯一 ID 的方案来进行消息检测，具体的实现原理和 版本号递增的方式一致。）

四、怎么解决消息被重复消费的问题

        其实就是如何解决消费端幂等性问题。

        实现方案：在数据库中建一张消息日志表

        这个表有两个字段：消息 ID 和消息执行状态。这样，我们消费消息的逻辑可以变为：在消息日志表中增加一条消息记录，然后再根据消息记录，异步操作更新用户消费数据。因为我们每次都会在插入之前检查是否消息已存在，所以就不会出现一条消息被执行多次      的情况，这样就实现了一个幂等的操作。

五、如何处理消息积压问题

        其实就是如何通过 MQ 实现真正的高性能问题 因为消息发送之后才会出现积压问题，故和消息生产端没关系，又因为绝大部分的消息队列单节点都能达到每秒钟几万的处理能力，相对于业务逻辑来说，性能不会出现在中间件的消息存储上面。毫无疑问，出问题的肯定是消息消费阶段，那么从消费端入手

解决思路方案:

        如果是线上突发问题，要临时扩容，增加消费端的数量，与此同时，降级一些非核心的业务。通过扩容和降级承担流量。其次，排查解决异常问题，如通过监控，日志等手段分析是否消费端的业务逻辑代码出现了问题，优化消费端的业务处理逻辑。

     

      注意：还有不是很懂的同学可以查看这篇文章，讲的非常详细，也有实例，可以结合这2篇文章好好理解一下

RabbitMQ常见问题解决方案——消息丢失、重复消费、消费乱序、消息积压_koala、的博客-CSDN博客_rabbitmq消息丢失和重复消费RabbitMQ的消息丢失、重复消费、消费乱序、消息积压问题，非常常见，如何解决必须掌握。消息中间件在业务开发当中具有举足轻重的地位，很多场景/问题下都可以依托于消息中间件来实现，所以消息中间件的很多问题也是在面试的高频点。https://blog.csdn.net/qq_42937522/article/details/119567072