RabbitMQ一般情況很少丟失，但是不能排除意外，為了保證系統高可用，我們必須作出更好完善措施，保證系統的穩定性。
1.消息持久化
2.ACK確認機制
3.設置集群鏡像模式
4.消息補償機制
第一種：消息持久化
RabbitMQ 的消息默認存放在內存上面，如果不特別聲明設置，消息不會持久化保存到硬盤上面的，如果節點重啟或者意外crash掉，消息就會丟失。
所以就要對消息進行持久化處理。如何持久化，下面具體說明下：
要想做到消息持久化，必須滿足以下三個條件，缺一不可。
1） Exchange 設置持久化
2）Queue 設置持久化
3）Message持久化發送：發送消息設置發送模式deliveryMode=2，代表持久化消息
第二種：ACK確認機制
多個消費者同時收取消息，比如消息接收到一半的時候，一個消費者死掉了(邏輯復雜時間太長，超時了或者消費被停機或者網絡斷開鏈接)，如何保證消息不丟？
這個使用就要使用Message acknowledgment 機制，就是消費端消費完成要通知服務端，服務端才把消息從內存刪除。
這樣就解決了，及時一個消費者出了問題，沒有同步消息給服務端，還有其他的消費端去消費，保證了消息不丟。
第三種：設置集群鏡像模式
我們先來介紹下RabbitMQ三種部署模式：
1）單節點模式：最簡單的情況，非集群模式，節點掛了，消息就不能用了。業務可能癱瘓，只能等待。
2）普通模式：默認的集群模式，某個節點掛了，該節點上的消息不能用，有影響的業務癱瘓，只能等待節點恢復重啟可用（必須持久化消息情況下）。
3）鏡像模式：把需要的隊列做成鏡像隊列，存在於多個節點，屬於RabbitMQ的高可用方案
為什么設置鏡像模式集群，因為隊列的內容僅僅存在某一個節點上面，不會存在所有節點上面，所有節點僅僅存放消息結構和元數據。
高可用三種策略模式：
1）同步至所有的節點
2）同步最多N個機器
3）只同步至符合指定名稱的節點
第四種：消息補償機制
消息補償機制需要建立在消息要寫入數據庫日志，發送日志，接受日志，兩者的狀態必須記錄。
然后根據數據庫日志記錄檢驗消息發送消費是否成功，不成功，進行消息補償措施，重新發送消息處理。