使用 RabbitMQ 和 RocketMQ 的人是幸運的，因為這兩個 MQ 自身提供了延遲隊列的實現，不像用 Kafka 的同學那么苦逼，還要自己實現延遲隊列。當然，這都是題外話，今天咱們重點來聊聊 RabbitMQ 延遲隊列的實現原理，以及 RabbitMQ 實現延遲隊列的優(yōu)缺點有哪些？

很多人知道使用 RabbitMQ 是可以實現延遲隊列的，但對于 RocketMQ 自身也提供了延遲隊列這件事卻持有不同態(tài)度，這是因為網上有些資料說 RocketMQ 和 Kafka 沒有內置延遲隊列。其實這種說法是因為，RocketMQ 在早期版本中確實沒有內置延遲隊列，但在 4.x 就內置了 18 個級別的延遲隊列了（最長支持 2 小時的延遲隊列），5.x 就支持隨機延遲時間的延遲隊列了，所以這里需要特殊強調一下。

1.什么是延遲隊列？

延遲隊列（Delay Queue）是一種特殊類型的隊列，它的主要特點是可以讓進入隊列的元素在指定的延遲時間之后才被取出進行處理。

延遲隊列的主要使用場景有以下這些：

• 訂單超時處理：在電商系統(tǒng)中，如果用戶下單后未在一定時間內支付，訂單可能會被自動取消。可以將訂單放入延遲隊列，在設定的延遲時間（如 30 分鐘）后取出處理取消操作。
• 任務重試：當某個任務執(zhí)行失敗時，將其放入延遲隊列，等待一段時間（如 5 分鐘）后重新執(zhí)行。
• 消息延遲發(fā)送：某些消息不需要立即發(fā)送，而是在指定的延遲時間后發(fā)送，例如定時提醒消息。
• 緩存過期處理：緩存中的數據可能有一定的有效期，將即將過期的數據放入延遲隊列，到期后進行刪除或更新操作。

2.延遲任務實現方法

那么延遲隊列的實現方式有哪些呢？

延遲隊列的實現方式通常有以下幾種：

• 基于 JDK 提供的 DelayQueue 來實現：它是內存級別的延遲隊列，重啟應用之后消息會丟失，并且只支持單機版延遲隊列，所以一般不用。
• 基于 MQ 的延遲隊列：例如使用 RabbitMQ 來實現延遲隊列，他們適合處理動態(tài)和臨時延遲任務，不像定時任務一樣，適合處理正式的、固定的延遲任務。
• 基于定時任務組件實現延遲任務：例如 XXLJob 或 Quartz 等框架來實現延遲任務，他們適合處理固定（執(zhí)行）頻率的延遲任務。

我們通常會使用延遲隊列來存儲（和實現）延遲消息，所以大部分時候，我們說的延遲隊列和延遲消息其實是一回事。

3.使用RabbitMQ實現延遲隊列

使用 RabbitMQ 實現延遲隊列有以下兩種實現方式：

• 通過死信隊列實現延遲任務：將正常的消息放到沒有消息訂閱者的消息隊列（消息自然就會過期），等消息過期之后會進入死信隊列，通過訂閱死信隊列消費消息，從而實現延遲隊列，如下圖所示：

• 通過官方提供的延遲插件實現延遲功能。

早期大部分公司都會采用第一種方式，而隨著 RabbitMQ 3.5.7（2015 年底發(fā)布）的延遲插件的發(fā)布，因為其使用更簡單、更方便，所以它現在才是大家普通會采用的，實現延遲隊列的方式。

（1）實現原理分析

使用延遲插件的實現原理是通過創(chuàng)建一個延遲交換機（Delay Exchange），延遲消息首先會把消息投遞到延遲交換機，并不是直接將消息投遞業(yè)務隊列（所以不會立即執(zhí)行），由延遲交換機控制消息在延遲一段時間后，再將消息投遞到真正的隊列中進行消費，從而實現延遲隊列，它的實現流程如下圖所示：

其中 Mnesia 可以理解為基于文件存儲的數據庫。

（2）優(yōu)缺點分析

使用死信隊列實現延遲任務有個缺點，它不能實現隨機延遲任務，每個無消費者的隊列上只能設置一個 ttl（消息過期時間），所以只能實現固定過期時間的延遲任務。

使用延遲插件實現延遲任務有以下兩個缺點：

• 消息丟失問題：消息在真的被投遞到目標消息隊列之前，是存放在接收到了這個消息的服務端本地的 Mnesia 里面。也就是說，如果這個時候還沒有刷新磁盤，那么消息就會丟失；如果這個節(jié)點不可用了，那么消息也同樣會丟失。
• 高并發(fā)問題：這種實現方式不支持高并發(fā)場景，因為它只有一個延遲交換機，當高并發(fā)或數據量比較大時執(zhí)行效率就會比較低。