如果聊到訊息中介軟體，老辣的面試官一定會問你：如何最大限度防止訊息不丟失？
還沒關注？
快動動手指！
聊技術、論職場！
為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人打造一個 “有溫度” 的技術窩！
