RabbitMQ消息隊列的可靠性

概述

RabbitMQ的可靠性貫穿整個消息的生命週期，主要包含以下三個階段：

1. 消息生產階段
2. 消息轉發階段
3. 消息消費階段

消息生產階段

通過事務機制或發送方確認機制保證消息已經正確地發送並存儲至RabbitMQ中

事務機制

事務會在一條消息發送之後阻塞發送端，直到收到服務端的響應，所以它是同步阻塞的:

try{

    channel.txSelect(); //開啓事務
    channel.BasicPublish(); //消息生產
    channel.txComment(); //提交事物
}catch(Exception e){
    channel.txRollBack(); //事務回滾
}

發送方確認機制

生產者將channel設置爲confirm模式，那麼所有通過該channel發送的消息都會從1開始分配一個唯一的ID，服務端響應會包含對應的ID。發送方確認機制是異步的，在等待服務端返回之前可以繼續發送下一條消息，消息成功發送後，服務端會返回ack給客戶端，發送失敗時，服務端會返回nack給客戶端，並且不會出現一條消息既被ack又被nack的情況。無論ack還是nack，客戶端都可以通過回調方法處理該響應。

channel.confirmSelect();
channel.basicPublish();
if( !channel.waitForConfirms() ){
    error msg...
}

除了發送方阻塞和非阻塞的區別外，在同步等待方式下，發送方確認機制發送一條消息需要通信交互的命令是2條：Basic.Publish和Basic.Ack；事務機制是3條：Basic.Publish、TxCommit/Commit-OK（失敗時Tx.rollBack/RollBack-OK），事務機制多了一個命令報文的交互，所以QPS也會略微下降。

 

消息轉發階段

參考另一篇博文：https://success.blog.csdn.net/article/details/105880390

 

消息消費階段

消費者端在開啓一個消費者時，可以通過將 autoAck 參數設置爲 false，此時只有消費成功後發送 basic.Ack 命令纔會將消息從服務端刪除；假如設置爲true，消費者獲取消息後就會從服務端刪除，假如消費失敗後就會丟失該條消息。