如果聊到消息中间件，老辣的面试官一定会问你：如何最大限度防止消息不丢失？
source link: http://mp.weixin.qq.com/s?__biz=MzU2Njg3OTU1Mg%3D%3D&%3Bmid=2247483848&%3Bidx=1&%3Bsn=6ec3902a602551d950beeba301843667&%3Butm_source=tuicool&%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
还没关注？
快动动手指！
聊技术、论职场！
为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人打造一个 “有温度” 的技术窝！
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK