MQ如何保证消息不丢失

MQ如何保证消息不丢失

• 我们需要从多个维度来进行思考，很多时候我们都知道将消息持久化

下面我们从多个维度来进行总结

第一个维度

• 第一个维度就是我们mq的服务器端，我们的producer他将我们的msg消息投到我们的mq服务器端的时候，我们是需要将消息给持久化的，我们的消息持久化到硬盘，注意这个过程是有同步和异步刷盘的，如果你选择同步刷盘的话，那他真正严格以上保证了我们的消息不丢失，如果选择了异步刷盘的情况下，注意，这个时候丢失是有概率的，因为是异步的，不是同步的，如果同步情况下刷盘失败，在后期是可以做补偿的，如果是异步刷盘，那就有些麻烦了，所以我们的mq服务端他是需要将我们的message持久化到硬盘，我们可以选择同步或异步进行刷盘，同步会更加安全，更加保证消息不丢失。

第二个维度

• 下面我们在谈到，我们的生产角色，也就是我们的producer，我们的生产者，他在投我们的msg消息到达mq服务端的时候，我们是可以使用到消息确认机制，也就是必须要确保我们的msg消息一定要投到mq成功之后，我们在走后面的流程，但是你这样都是同步的，因为我们porducer投消息，他是有同步和异步形式的，同步形式，就是我们必须要投递消息到mq成功之后给我们返回一个消息，如果投递失败的情况下，我们可以不断的进行补偿补偿，只不过我们像mq里面producer投消息，他是可以走这个异步回调的形式拿到这样一个投递消息结果，然后在投失败的情况下，我们可以在根据这个结果在做一个补偿。

第三个维度

• 就是我们的消费者，如果使用的是ribbetMQ消费者消费了消息之后，msg会在mq中将这个消息进行删除，如果使用的kafka或rocketMQ，消费了消息之后，这个消息是不被删除的，所以kafka和rocketMQ在确保消息消费成功的情况下，我们才会收到的取ack进行删除操作，如果消费失败的情况下，消费者应该，不断的进行重试整个业务逻辑代码，让他不断的进行重试

总结：如果想要使我们的MQ保证消息不丢失，那我们的produce投消息他到mq选择同步的方式，刷盘也选择同步，这样的话多少会有延迟，因为是完全同步的。