RabbitMQ 高級篇八 消費端ACK與重回隊列

RabbitMQ消息中間件技術精講15 高級篇八 消費端ACK與重回隊列

消費端的簽收方式：

分為自動簽收和手動簽收。

自動簽收：channel.basicConsume方法的第二個參數(autoAck)設置為true即可;

手動簽收：將第二個參數設置為false即可。

手動簽收又分為兩種方式：

手動Ack和Nack。

兩者之間的區別：

Ack表示手工簽收後消息處理成功；

Nack表示手動簽合後消息處理失敗。這個時候broker會自動重新發送消息。

使用場景：

場景一：

假設我們設置的自動重複消息次數是3次，那麼在Nack後，broker會重複發送三次消息。如果三次之後，還是Nack的，這種情況下，我們不可能一直重複發送，此時就可以設置為Ack,然後在消費端進行消費的時候，如果由於業務處理而產生的異常，我們可以進行日誌的記錄或者給開發人員發送警報郵件，然後進行補償。

場景二：

如果由於伺服器宕機等嚴重性的問題，此時是不可能收到ack或者Nack,這種情況下也會一直重複發送消息的，那麼我們就需要手工的Ack,來保證消費端消費成功。在伺服器重啟之後，會自動的消費之前未消費成功的消息的。

以上兩個案例，就體現了消費端ACK或者NACK的重要性。

下面我們來看看消費端的重回隊列

消費端的重回隊列：

是為了對沒有處理成功的消息，把消息重新返回給broker.

注意，在一般我們在實際的應用中，都會關閉重回隊列，也就是設置未false.

代碼演示：

模擬需求：

我們在properties的handers中設置for循環的num。假設如果num等於1，就重回隊列。

生產者中，添加properties信息：

在消息處理的類：MyConsumer類中添加重回隊列的判斷：

我們開源看到，調用的是nack方法。參數說明：

修改完成之後，啟動消費者和生產者，查看運行效果：『

我們可以看到控制台列印的，第0個不斷重複被列印。說明，下標為0的被重回到隊列中了。

下節預告：TTL隊列/消息

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！