A:生產者丟失消息
①：可以選擇使用rabbitmq提供是事物功能，就是生產者在發送數據之前開啟事物，然后發送消息，如果消息沒有成功被rabbitmq接收到，那么生產者會受到異常報錯，這時就可以回滾事物，然后嘗試重新發送；如果收到了消息，那么就可以提交事物。

  channel.txSelect();//開啟事物
  try{
      //發送消息
  }catch(Exection e){
      channel.txRollback()；//回滾事物
      //重新提交
  }

缺點：rabbitmq事物已開啟，就會變為同步阻塞操作，生產者會阻塞等待是否發送成功，太耗性能會造成吞吐量的下降。

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

    //開啟confirm
    channel.confirm();
    //發送成功回調
    public void ack(String messageId){
      
    }

    // 發送失敗回調
    public void nack(String messageId){
        //重發該消息
    }

二者不同
事務機制是同步的，你提交了一個事物之后會阻塞住，但是confirm機制是異步的，發送消息之后可以接著發送下一個消息，然后rabbitmq會回調告知成功與否。
一般在生產者這塊避免丟失，都是用confirm機制。
B:rabbitmq自己弄丟了數據
設置消息持久化到磁盤。設置持久化有兩個步驟：
①創建queue的時候將其設置為持久化的，這樣就可以保證rabbitmq持久化queue的元數據，但是不會持久化queue里面的數據。
②發送消息的時候講消息的deliveryMode設置為2，這樣消息就會被設為持久化方式，此時rabbitmq就會將消息持久化到磁盤上。
必須要同時開啟這兩個才可以。

而且持久化可以跟生產的confirm機制配合起來，只有消息持久化到了磁盤之后，才會通知生產者ack，這樣就算是在持久化之前rabbitmq掛了，數據丟了，生產者收不到ack回調也會進行消息重發。
C:消費者弄丟了數據
使用rabbitmq提供的ack機制，首先關閉rabbitmq的自動ack，然后每次在確保處理完這個消息之后，在代碼里手動調用ack。這樣就可以避免消息還沒有處理完就ack。