如果我是核酸系统架构师，我会这么用MQ。。。

V-xin：ruyuan0330 获得600+页原创精品文章汇总PDF

目录

• 一、前情提示
• 二、保证投递消息不丢失的confirm机制
• 三、confirm机制的代码实现
• 四、confirm机制投递消息的高延迟性
• 五、高并发下如何投递消息才能不丢失
• 六、消息中间件全链路100%数据不丢失能做到吗？

一、前情提示

上篇文章：《选Redis做MQ的人，是脑子里缺根弦儿吗？》，我们分析了RabbitMQ开启手动ack机制保证消费端数据不丢失的时候，prefetch机制对消费者的吞吐量以及内存消耗的影响。

通过分析，我们知道了prefetch过大容易导致内存溢出，prefetch过小又会导致消费吞吐量过低，所以在实际项目中需要慎重测试和设置。

这篇文章，我们转移到消息中间件的生产端，一起来看看如何保证投递到MQ的数据不丢失。

如果投递出去的消息在网络传输过程中丢失，或者在RabbitMQ的内存中还没写入磁盘的时候宕机，都会导致生产端投递到MQ的数据丢失。

而且丢失之后，生产端自己还感知不到，同时还没办法来补救。

下面的图就展示了这个问题。

所以本文呢，我们就来逐步分析一下。

---

二、保证投递消息不丢失的confirm机制

其实要解决这个问题，相信大家看过之前的消费端ack机制之后，也都猜到了。

很简单，就是生产端（比如上图的订单服务）首先需要开启一个confirm模式，接着投递到MQ的消息，如果MQ一旦将消息持久化到磁盘之后，必须也要回传一个confirm消息给生产端。

这样的话，如果生产端的服务接收到了这个confirm消息，就知道是已经持久化到