如果聊到消息中间件，老辣的面试官一定会问你：如何最大限度防止消息不丢失？

还没关注？

快动动手指！

聊技术、论职场！

为IT人打造一个“有温度”的 狸猫技术窝

RabbitMQ的主要作用基本上可以用8个字概括， 削峰填谷、异步解耦 。但是引入MQ我们也不得不考虑引入MQ后带来的一些问题，如消息丢失。

业务场景不一样，处理方式也就不一样。比如发短信，日志收集，我们主要看吞吐量，所以对消息丢失容忍度较高，这类场景基本上不用花太多时间在消息丢失问题上。

另外一种，如我们用MQ来做分布式事务，续保计算，提成的计算，这类业务对消息丢失容忍度较底，所以我们一定要考虑消息丢失的问题。

这次分享的内容是 怎么来最大限制的防止消息丢失 ，顺带提一下消息的重发和重复消费。

RabbitMQ 模型图

ConfirmCallback 和 ReturnCallback

在这里我们主要实现了ConfirmCallback和ReturnCallback两个接口，这两个接口主要是用来发送消息后回调的。

因为rabbit发送消息是只管发，至于发没发成功，发送方法不管。

• ConfirmCallback ：当消息成功到达exchange的时候触发的ack回调。

• ReturnCallback ：当消息成功到达exchange，但是没有队列与之绑定的时候触发的ack回调。发生网络分区会出现这种情况。

在这里一定要把这两个开关打开，publisher-confirms="true" publisher-returns="true"。

生产者端使用ConfirmCallback和ReturnCallback回调机制，最大限度的保证消息不丢失，对原有CorrelationData类进行扩展，来实现消息的重发，具体请看下面的源码。

消息的日志链路跟踪

使用MQ来解耦服务，异步化处理一些复杂耗时逻辑，但是也带来了一个问题。

由于异步化以后，排查问题就很不方便了，根本不知道这个消息什么时候消费，消费的日志也很不好排查。

所以，引入了Slf4j MDC机制将主线程的日志链路和消息的日志链路连起来，方便MQ问题的排查。

RabbitSender

CorrelationData

Message

AbstractConsumer

END

作者： xiaolyuh

来源：

https://www.jianshu.com/p/f7165dd06db3

本文版权归作者所有

长按下图二维码，即刻关注【 狸猫技术窝 】

阿里、京东、美团、字节跳动

顶尖技术专家 坐镇

为IT人打造一个 “有温度” 的技术窝！