RabbitMQ如何解決各種情況下丟資料的問題

1.生產者丟資料

生產者的訊息沒有投遞到MQ中怎麼辦？從生產者弄丟資料這個角度來看，RabbitMQ提供transaction和confirm模式來確保生產者不丟訊息。
transaction機制就是說，傳送訊息前，開啟事物(channel.txSelect())，然後傳送訊息，如果傳送過程中出現什麼異常，事物就會回滾(channel.txRollback())，如果傳送成功則提交事
物(channel.txCommit())。

然而缺點就是吞吐量下降了。因此，按照博主的經驗，生產上用confirm模式的居多。一旦channel進入confirm模式，所有在該通道上面釋出的訊息都將會被指派一個唯一的ID(從1開始)，一旦
訊息被投遞到所有匹配的佇列之後，rabbitMQ就會傳送一個Ack給生產者(包含訊息的唯一ID)，這就使得生產者知道訊息已經正確到達目的佇列了.如果rabiitMQ沒能處理該訊息，則會傳送一個N
ack訊息給你，你可以進行重試操作。

下面演示一下confirm模式：

//測試確認後回撥
@Service
public class HelloSender1 implements RabbitTemplate.ConfirmCallback {

    @Autowired
    private RabbitTemplate rabbitTemplate;


    public void send() {
        String context = "你好現在是 " + new Date() +"";
        System.out.println("HelloSender傳送內容 : " + context);
        this.rabbitTemplate.setConfirmCallback(this);
        //exchange,queue 都正確,confirm被回撥, ack=true
        //this.rabbitTemplate.convertAndSend("exchange","topic.message", context);

        //exchange 錯誤,queue 正確,confirm被回撥, ack=false
        //this.rabbitTemplate.convertAndSend("fasss","topic.message", context);

        //exchange 正確,queue 錯誤 ,confirm被回撥, ack=true; return被回撥 replyText:NO_ROUTE
        //this.rabbitTemplate.convertAndSend("exchange","", context);

        //exchange 錯誤,queue 錯誤,confirm被回撥, ack=false
        this.rabbitTemplate.convertAndSend("fasss","fass", context);
    }

    @Override
    public void confirm(CorrelationData correlationData, boolean ack, String cause) {
        System.out.println("confirm--:correlationData:"+correlationData+",ack:"+ack+",cause:"+cause);
    }

}

2.訊息佇列丟資料

處理訊息佇列丟資料的情況，一般是開啟持久化磁碟的配置。這個持久化配置可以和confirm機制配合使用，你可以在訊息持久化磁碟後，再給生產者傳送一個Ack訊號。這樣，如果訊息持久化磁碟
之前，rabbitMQ陣亡了，那麼生產者收不到Ack訊號，生產者會自動重發。
那麼如何持久化呢，這裡順便說一下吧，其實也很容易，就下面兩步
①、將queue的持久化標識durable設定為true,則代表是一個持久的佇列
②、傳送訊息的時候將deliveryMode=2
這樣設定以後，rabbitMQ就算掛了，重啟後也能恢復資料。在訊息還沒有持久化到硬碟時，可能服務已經死掉，這種情況可以通過引入mirrored-queue即映象佇列，但也不能保證訊息百分百不丟
失（整個叢集都掛掉）

 

    /**
     * 第二個引數：queue的持久化是通過durable=true來實現的。
     * 第三個引數：exclusive：排他佇列，如果一個佇列被宣告為排他佇列，該佇列僅對首次申明它的連線可見，並在連線斷開時自動刪除。這裡需要注意三點：
　　  1. 排他佇列是基於連線可見的，同一連線的不同通道是可以同時訪問同一連線建立的排他佇列；
　　  2.“首次”，如果一個連線已經宣告瞭一個排他佇列，其他連線是不允許建立同名的排他佇列的，這個與普通佇列不同；
　　  3.即使該佇列是持久化的，一旦連線關閉或者客戶端退出，該排他佇列都會被自動刪除的，這種佇列適用於一個客戶端傳送讀取訊息的應用場景。
     * 第四個引數：自動刪除，如果該佇列沒有任何訂閱的消費者的話，該佇列會被自動刪除。這種佇列適用於臨時佇列。
     * @param
     * @return
     * @Author zxj
     */
    @Bean
    public Queue queue() {
        Map<String, Object> arguments = new HashMap<>();
        arguments.put("x-message-ttl", 25000);//25秒自動刪除
        Queue queue = new Queue("topic.messages", true, false, true, arguments);
        return queue;
    }

 

        MessageProperties properties=new MessageProperties();
        properties.setContentType(MessageProperties.DEFAULT_CONTENT_TYPE);
        properties.setDeliveryMode(MessageProperties.DEFAULT_DELIVERY_MODE);//持久化設定
        properties.setExpiration("2018-12-15 23:23:23");//設定到期時間
        Message message=new Message("hello".getBytes(),properties);
        this.rabbitTemplate.sendAndReceive("exchange","topic.message",message);

3.消費者丟資料

啟用手動確認模式可以解決這個問題
①自動確認模式，消費者掛掉，待ack的訊息迴歸到佇列中。消費者丟擲異常，訊息會不斷的被重發，直到處理成功。不會丟失訊息，即便服務掛掉，沒有處理完成的訊息會重回佇列，但是異常會讓
訊息不斷重試。
②手動確認模式
③不確認模式，acknowledge="none" 不使用確認機制，只要訊息傳送完成會立即在佇列移除，無論客戶端異常還是斷開，只要傳送完就移除，不會重發。

指定Acknowledge的模式：
spring.rabbitmq.listener.direct.acknowledge-mode=manual，表示該監聽器手動應答訊息
針對手動確認模式，有以下特點：
1.使用手動應答訊息，有一點需要特別注意，那就是不能忘記應答訊息，因為對於RabbitMQ來說處理訊息沒有超時，只要不應答訊息，他就會認為仍在正常處理訊息，導致訊息佇列出現阻塞，影響
業務執行。
2.如果消費者來不及處理就死掉時，沒有響應ack時，會專案啟動後會重複傳送一條資訊給其他消費者；
3.可以選擇丟棄訊息，這其實也是一種應答，如下，這樣就不會再次收到這條訊息。
channel.basicNack(message.getMessageProperties().getDeliveryTag(), false,false);
4.如果消費者設定了手動應答模式，並且設定了重試，出現異常時無論是否捕獲了異常，都是不會重試的
5.如果消費者沒有設定手動應答模式，並且設定了重試，那麼在出現異常時沒有捕獲異常會進行重試，如果捕獲了異常不會重試。

 

重試機制：

spring.rabbitmq.listener.simple.retry.max-attempts=5  最大重試次數
spring.rabbitmq.listener.simple.retry.enabled=true 是否開啟消費者重試（為false時關閉消費者重試，這時消費端程式碼異常會一直重複收到訊息）
spring.rabbitmq.listener.simple.retry.initial-interval=5000 重試間隔時間（單位毫秒）
spring.rabbitmq.listener.simple.default-requeue-rejected=false 重試次數超過上面的設定之後是否丟棄（false不丟棄時需要寫相應程式碼將該訊息加入死信佇列）

如果設定了重試模式，那麼在出現異常時沒有捕獲異常會進行重試，如果捕獲了異常不會重試。

 

 

當出現異常時，我們需要把這個訊息回滾到訊息佇列，有兩種方式：

//ack返回false，並重新回到佇列，api裡面解釋得很清楚

//ack返回false，並重新回到佇列，api裡面解釋得很清楚
channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
//拒絕訊息
channel.basicReject(message.getMessageProperties().getDeliveryTag(), true);

經過開發中的實際測試，當訊息回滾到訊息佇列時，這條訊息不會回到佇列尾部，而是仍是在佇列頭部，這時消費者會立馬又接收到這條訊息進行處理，接著丟擲異常，進行         回滾，如此反覆進行。這種情況會導致訊息佇列處理出現阻塞，訊息堆積，導致正常訊息也無法執行。對於訊息回滾到訊息佇列，我們希望比較理想的方式時出現異常的訊息到         達訊息佇列尾部，這樣既保證訊息不會丟失，又保證了正常業務的進行，因此我們採取的解決方案是，將訊息進行應答，這時訊息佇列會刪除該訊息，同時我們再次傳送該訊息         到訊息佇列，這時就實現了錯誤訊息進行訊息佇列尾部的方案。

   //手動進行應答
            channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
            //重新傳送訊息到隊尾
            channel.basicPublish(message.getMessageProperties().getReceivedExchange(),
                    message.getMessageProperties().getReceivedRoutingKey(), MessageProperties.PERSISTENT_TEXT_PLAIN,
                    JSON.toJSONBytes(new Object()));

如果一個訊息體本身有誤，會導致該訊息體，一直無法進行處理，而伺服器中刷出大量無用日誌。解決這個問題可以採取兩種方案：

1.一種是對於日常細緻處理，分清哪些是可以恢復的異常，哪些是不可以恢復的異常。對於可以恢復的異常我們採取第三條中的解決方案，對於不可以處理的異常，我們採用記錄日誌，直接丟棄該訊息方案。

2.另一種是我們對每條訊息進行標記，記錄每條訊息的處理次數，當一條訊息，多次處理仍不能成功時，處理次數到達我們設定的值時，我們就丟棄該訊息，但需要記錄詳細的日誌。

 

訊息監聽內的異常處理有兩種方式：

 1.內部catch後直接處理，然後使用channel對訊息進行確認

 2.配置RepublishMessageRecoverer將處理異常的訊息傳送到指定佇列專門處理或記錄。監聽的方法內丟擲異常貌似沒有太大用處。因為丟擲異常就算是重試也非常有可能會繼續出現異常，當重試次數完了之後訊息就只有重啟應用才能接收到了，很有可能導致訊息消費不及時。當然可以配置RepublishMessageRecoverer來解決，但是萬一RepublishMessageRecoverer傳送失敗了呢。。那就可能造成訊息消費不及時了。所以即使需要將處理出現異常的訊息統一放到另外佇列去處理，個人建議兩種方式：

①catch異常後，手動傳送到指定佇列，然後使用channel給rabbitmq確認訊息已消費
②給Queue繫結死信佇列，使用nack（requque為false）確認訊息消費失敗