第一種：（生產者）生產者弄丟了數據。生產者將數據發送到 RabbitMQ 的時候，可能數據就在半路給搞丟了，因為網路問題啥的，都有可能。

第二種：（服務端）RabbitMQ 弄丟了數據。MQ還沒有持久化自己掛了

第三種：（消費者）消費端弄丟了數據。剛消費到，還沒處理，結果進程掛了，比如重啟了。

1.針對生產者

方案2： 使用confirm機制

事務機制和 confirm 機制最大的不同在於，事務機制是同步的，你提交一個事務之後會阻塞在那兒，但是 confirm 機制是非同步的

在生產者開啟了confirm模式之後，每次寫的消息都會分配一個唯一的id，然後如果寫入了rabbitmq之中，rabbitmq會給你回傳一個ack消息，告訴你這個消息發送OK了；如果rabbitmq沒能處理這個消息，會回調你一個nack介面，告訴你這個消息失敗了，你可以進行重試。而且你可以結合這個機制知道自己在記憶體里維護每個消息的id，如果超過一定時間還沒接收到這個消息的回調，那麼你可以進行重發

2.針對RabbitMQ

有三點需要註意：

（1）要保證rabbitMQ不丟失消息，那麼就需要開啟rabbitMQ的持久化機制，即把消息持久化到硬碟上，這樣即使rabbitMQ掛掉在重啟後仍然可以從硬碟讀取消息；

（2）如果rabbitMQ單點故障怎麼辦，這種情況倒不會造成消息丟失，這裡就要提到rabbitMQ的3種安裝模式，單機模式、普通集群模式、鏡像集群模式，這裡要保證rabbitMQ的高可用就要配合HAPROXY做鏡像集群模式

（3）如果硬碟壞掉怎麼保證消息不丟失

（1）消息持久化

RabbitMQ 的消息預設存放在記憶體上面，如果不特別聲明設置，消息不會持久化保存到硬碟上面的，如果節點重啟或者意外crash掉，消息就會丟失。所以就要對消息進行持久化處理。如何持久化，下麵具體說明下：

    要想做到消息持久化，必須滿足以下三個條件，缺一不可。

　　1） Exchange 設置持久化

　　2）Queue 設置持久化

　　3）Message持久化發送：發送消息設置發送模式deliveryMode=2，代表持久化消息

（2）設置集群鏡像模式

我們先來介紹下RabbitMQ三種部署模式：

1）單節點模式：最簡單的情況，非集群模式，節點掛了，消息就不能用了。業務可能癱瘓，只能等待。

2）普通模式：消息只會存在與當前節點中，並不會同步到其他節點，當前節點宕機，有影響的業務會癱瘓，只能等待節點恢復重啟可用（必須持久化消息情況下）。

3）鏡像模式：消息會同步到其他節點上，可以設置同步的節點個數，但吞吐量會下降。屬於RabbitMQ的HA方案

（3）消息補償機制

為什麼還要消息補償機制呢？難道消息還會丟失，沒錯，系統是在一個複雜的環境，不要想的太簡單了，雖然以上的三種方案，基本可以保證消息的高可用不丟失的問題，

比如：持久化的消息，保存到硬碟過程中，當前隊列節點掛了，存儲節點硬碟又壞了，消息丟了，怎麼辦？

1）生產端首先將業務數據以及消息數據入庫，需要在同一個事務中，消息數據入庫失敗，則整體回滾

2）根據消息表中消息狀態，失敗則進行消息補償措施，重新發送消息處理。

3.針對消費者

方案一：ACK確認機制

多個消費者同時收取消息，比如消息接收到一半的時候，一個消費者死掉了(邏輯複雜時間太長，超時了或者消費被停機或者網路斷開鏈接)，如何保證消息不丟？

使用rabbitmq提供的ack機制，服務端首先關閉rabbitmq的自動ack，然後每次在確保處理完這個消息之後，在代碼里手動調用ack。這樣就可以避免消息還沒有處理完就ack。才把消息從記憶體刪除。

這樣就解決了，即使一個消費者出了問題，但不會同步消息給服務端，會有其他的消費端去消費，保證了消息不丟的case。

四、總結

如果需要保證消息在整條鏈路中不丟失，那就需要生產端、mq自身與消費端共同去保障。

生產端：對生產的消息進行狀態標記，開啟confirm機制，依據mq的響應來更新消息狀態，使用定時任務重新投遞超時的消息，多次投遞失敗進行報警。

mq自身：開啟持久化，併在落盤後再進行ack。如果是鏡像部署模式，需要在同步到多個副本之後再進行ack。

消費端：開啟手動ack模式，在業務處理完成後再進行ack，並且需要保證冪等。

通過以上的處理，理論上不存在消息丟失的情況，但是系統的吞吐量以及性能有所下降。

在實際開發中，需要考慮消息丟失的影響程度，來做出對可靠性以及性能之間的權衡。