作為業務開發者，對各種技術元件都要有比較紮實的瞭解，這樣在各種複雜的業務面前，才能更好更快制定安全有效的技術方案。所以，本人準備總結一個專欄，解決在各種技術方面一個厲害的、業務開發應該具備什麼樣的“專業性常識“。文章基於多年大廠一線開發的實際經驗、官方檔案、個人實驗和原始碼分析；並在個人的思考上進行了總結、提煉和昇華。希望能幫到大家

(A) 本文的內容和知識基礎

         訊息中介軟體丟訊息需要補償方案估計是業務開發在選用queue方案時不可避免的話題，所以首先分析這個問題。丟訊息問題也可以稱為資料安全問題，或者說訊息佇列的可靠性問題。（這裡學習兩個單詞：data safety，reliability）

       後面內容的理解建立在讀者對rabbitmq最最基本概念的理解的基礎上（比較深入的話題本文會展開分析比如channel的概念），所以建議沒有用過rabbitmq的花半小時時間去官網讀rabbitmq的get started部分。文末有彙總所有用到的rabbitmq黑心概念，核心概念本文直接使用英文避免翻譯過來造成混淆。

（B）rabbitmq中為啥會丟訊息

    首先說一下丟訊息的根源（1）來核心來自於現實世界的不可靠，來自於（2）rabbimtq訊息中介軟體的設計不如innodb能可靠。所以rabbitmq會在現實世界

    所以注意（1）rabbitmq要理解現實世界會出現什麼樣的異常，在這些異常下（2）rabbitmq的為什麼會丟訊息，（3）rabbitmq如何解決這種丟訊息的方法，（4）其他訊息的佇列的改進。

（C）rabbitmq中哪些環節會丟訊息

Data safety is a joint responsibility of RabbitMQ nodes,publishers and consumers. 

        分析是不是會丟訊息有一個核心的方法論是：Message的一生經過publisher（也是producer），broker，consumer三個階段，所以message的安全性要從三個階段逐一考慮。另一種比較有趣的說法是，publisher，broker nodes和consumer是message的三個監護人，如果訊息丟失要分析是在哪個監護人上會丟失。這種通過資料鏈路經過的不同節點來分析資料可靠性

        上圖是我對rabbitmq叢集模式下畫的簡圖，並標註了每個訊息的責任人。下面就從訊息的一生開始逐一分析丟訊息的責任界定範圍、原因和解決方案。