*作者：凱易、明鍛*

## 引言

Apache RocketMQ 誕生至今，歷經十餘年大規模業務穩定性打磨，服務了 100% 阿里集團內部業務以及阿里雲數以萬計的企業客戶。作為金融級可靠的業務訊息方案，RocketMQ 從建立之初就一直專注於業務整合領域的非同步通訊能力構建。

本篇將繼續業務訊息整合的場景，從使用場景、應用案例、功能原理以及最佳實踐等角度介紹 RocketMQ 的定時訊息功能。

***點選下方連結，檢視直播講解：***

<https:>

## 概念：什麼是定時訊息

在業務訊息整合場景中，定時訊息是，生產者將一條訊息傳送到訊息佇列後並不期望這條訊息馬上會被消費者消費到，而是期望到了指定的時間，消費者才可以消費到。

相似地，延遲訊息其實是對於定時訊息的另外一種解釋，指的是生產者期望訊息延遲一定時間，消費者才可以消費到。可以理解為定時到當前時間加上一定的延遲時間。

對比一下定時訊息和普通訊息的流程。普通訊息，可以粗略的分為訊息傳送，訊息儲存和訊息消費三個過程。當一條訊息傳送到 Topic 之後，那麼這條訊息就可以馬上處於等待消費者消費的狀態了。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dbacaf8be2954413a5234877851e8c87~tplv-k3u1fbpfcp-zoom-1.image "1.png")

而對於定時/延時訊息來說，其可以理解為在普通訊息的基礎上疊加了定時投遞到消費者的特性。生產者傳送了一條定時訊息之後，訊息並不會馬上進入使用者真正的Topic裡面，而是會被 RocketMQ 暫存到一個系統 Topic 裡面，當到了設定的時間之後，RocketMQ 才會將這條訊息投遞到真正的 Topic 裡面，讓消費者可以消費到。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/89a4591d894542d7af344f7d7ad03bf3~tplv-k3u1fbpfcp-zoom-1.image "2.png")

## 場景：為什麼需要使用定時訊息

在分散式定時排程觸發、任務超時處理等場景，需要實現精準、可靠的定時事件觸發。往往這類定時事件觸發都會存在以下訴求：

-   高效能吞吐：需要大量事件觸發，不能有效能瓶頸。
-   高可靠可重試：不能丟失事件觸發。
-   分散式可擴充套件：定時排程不能是單機系統，需要能夠均衡的排程到多個服務負載。

傳統的定時排程方案，往往基於資料庫的任務表掃描機制來實現。大概的思路就是將需要定時觸發的任務放到資料庫，然後微服務應用定時觸發掃描資料庫的操作，實現任務撈取處理。

這類方案雖然可以實現定時排程，但往往存在很多不足之處：

-   重複掃描：在分散式微服務架構下，每個微服務節點都需要去掃描資料庫，帶來大量冗餘的任務處理，需要做去重處理。
-   定時間隔不準確：基於定時掃描的機制無法實現任意時間精度的延時排程。
-   橫向擴充套件性差：為規避重複掃描的問題，資料庫掃表的方案裡往往會按照服務節點拆分表，但每個資料表只能被單節點處理，這樣會產生效能瓶頸。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4d0e9d9832cb4764aad6b2ca87a376be~tplv-k3u1fbpfcp-zoom-1.image "3.png")

在這類定時排程類場景中，使用 RocketMQ 的定時訊息可以簡化定時排程任務的開發邏輯，實現高效能、可擴充套件、高可靠的定時觸發能力。

-   精度高、開發門檻低：基於訊息通知方式不存在定時階梯間隔。可以輕鬆實現任意精度事件觸發，無需業務去重。
-   高效能可擴充套件：傳統的資料庫掃描方式較為複雜，需要頻繁呼叫介面掃描，容易產生效能瓶頸。訊息佇列 RocketMQ 版的定時訊息具有高併發和水平擴充套件的能力。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/df1e76b819f94c70b79f93c31ce48ae3~tplv-k3u1fbpfcp-zoom-1.image "4.png")

## 案例：使用定時訊息實現金融支付超時需求

利用定時訊息可以實現在一定的時間之後才進行某些操作而業務系統不用管理定時的狀態。下面介紹一個典型的案例場景：金融支付超時。現在有一個訂單系統，希望在使用者下單 30 分鐘後檢查使用者的訂單狀態，如果使用者還沒有支付，那麼就自動取消這筆訂單。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/95a93ca215664c9c86a6625d9f245df0~tplv-k3u1fbpfcp-zoom-1.image "5.png")

基於 RocketMQ 定時訊息，我們可以在使用者下單之後傳送一條定時到 30 分鐘之後的定時訊息。同時，我們可以使用將訂單 ID 設定為 MessageKey。當 30 分鐘之後，訂單系統收到訊息之後，就可以透過訂單 ID 檢查訂單的狀態。如果使用者超時未支付，那麼就自動的將這筆訂單關閉。

## 原理：RocketMQ 定時訊息如何實現

### 固定間隔定時訊息

如前文介紹，定時訊息的核心是如何在特定的時間把處於系統定時 Topic 裡面的訊息轉移到使用者的 Topic 裡面去。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b0908ad7c2254f068e339b32e598a0f5~tplv-k3u1fbpfcp-zoom-1.image "6.png")

Apache RocketMQ 4.x 的版本的定時訊息是先將定時訊息放到按照 DelayLevel 放到 SCHEDULE_TOPIC_XXXX 這個系統的不同 Queue 裡面，然後為每一個 Queue 啟動一個定時任務，定時的拉取訊息並將到了時間的訊息轉投到使用者的 Topic 裡面去。這樣雖然實現簡單，但也導致只能支援特定 DelayLevel 的定時訊息。

當下，支援定時到任意秒級時間的定時訊息的實現的 pr 提出到了社群，下面簡單的介紹一下其基本的實現原理。

### 時間輪演算法

在介紹具體的實現原理之前，先介紹一下經典的時間輪演算法，這是定時訊息實現的核心演算法。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0d45f9f0f3b64b07952b8bceda0e786a~tplv-k3u1fbpfcp-zoom-1.image "7.png")

如上所示，這是一個一圈定時為 7 秒的時間輪，定時的最小精度的為秒。同時，時間輪上面會有一個指向當前時間的指標，其會定時的移向下一個刻度。

現在我們想定時到 1 秒以後，那麼就將資料放到 “1” 這個刻度裡面，同時如果有多個資料需要定時到同一個時間，

那麼會以連結串列的方式新增到後面。當時間輪轉到 “1” 這個刻度之後，就會將其讀取並從連結串列出隊。那如果想定到超過時間輪一圈的時間怎麼處理呢？例如我們想定時到 14 秒，由於一圈的時間是 7 秒，那麼我們將其放在“6”這個刻度裡面。當第一次時間輪轉到“6” 時，發現當前時間小於期望的時間，那麼忽略這條資料。當第二次時間輪轉到“6”時，這個時候就會發現已經到了我們期望的 14 秒了。

### 任意秒級定時訊息

在 RocketMQ 中，使用 TimerWheel 對於時間輪進行描述和儲存，同時使用一個 AppendOnly 的 TimerLog 記錄時間輪上面每一個刻度所對應的所有的訊息。

TimerLog 記錄了一條定時訊息的一些重要的後設資料，用於後面定時的時間到了之後，將訊息轉移到使用者的 Topic 裡面去。其中幾個重要的屬性如下：

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6924d1654a3048f2b72fef8eabfce9a0~tplv-k3u1fbpfcp-zoom-1.image "8.png")

對於 TimerWheel 來說，可以抽象的認為是一個定長的陣列，陣列中的每一格代表時間輪上面的一個“刻度”。TimerWheel 的一個“刻度”擁有以下屬性。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0415054cf87f4987a2b1cde2f0745dfd~tplv-k3u1fbpfcp-zoom-1.image "9.png")

TimerWheel 和 TimerLog 直接的關係如下圖所示：

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c32512ccaf1744dba9cd02d9a7218f59~tplv-k3u1fbpfcp-zoom-1.image "10.png")

TimerWheel 中的每一格代表著一個時間刻度，同時會有一個 firstPos 指向這個刻度下所有定時訊息的首條 TimerLog 記錄的地址，一個 lastPos 指向這個刻度下所有定時訊息最後一條 TimerLog 的記錄的地址。並且，對於所處於同一個刻度的的訊息，其 TimerLog 會透過 prevPos 串聯成一個連結串列。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cca9d344d1ec42adab21c2f285c98f64~tplv-k3u1fbpfcp-zoom-1.image "11.png")

當需要新增一條記錄的時候，例如現在我們要新增一個 “1-4”。那麼就將新記錄的 prevPos 指向當前的 lastPos，即 “1-3”，然後修改 lastPos 指向 “1-4”。這樣就將同一個刻度上面的 TimerLog 記錄全都串起來了。

有了 TimerWheel 和 TimerLog 之後，我們再來看一下一條定時訊息從傳送到 RocketMQ 之後是怎麼最終投遞給使用者的。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/92ca52d6c67b4035b9467a6b8c1ace51~tplv-k3u1fbpfcp-zoom-1.image "12.png")

首先，當發現使用者傳送的是一個定時訊息過後，RocketMQ 實際上會將這條訊息傳送到一個專門用於處理定時訊息的系統 Topic 裡面去

然後在 TimerMessageStore 中會有五個 Service 進行分工合作，但整體可以分為兩個階段：入時間輪和出時間輪

對於入時間輪：

-   TimerEnqueueGetService 負責從系統定時 Topic 裡面拉取訊息放入 enqueuePutQueue 等待 TimerEnqueuePutService 的處理
-   TimerEnqueuePutService 負責構建 TimerLog 記錄，並將其放入時間輪的對應的刻度中

對於出時間輪：

-   TimerDequeueGetService 負責轉動時間輪，並取出當前時間刻度的所有 TimerLog 記錄放入 dequeueGetQueue
-   TimerDequeueGetMessageService 負責根據 TimerLog 記錄，從 CommitLog 中讀取訊息
-   TimerDequeuePutMessageService 負責判斷佇列中的訊息是否已經到期，如果已經到期了，那麼將其投入使用者的 Topic 中，等待消費消費；如果還沒有到期，那麼重新投入系統定時 Topic，等待重新進入時間輪。

## 實戰：使用定時訊息

瞭解了 RocketMQ 秒級定時訊息的原理後，我們看下如何使用定時訊息。首先，我們需要建立一個 “定時/延時訊息” 型別的 Topic，可以使用控制檯或者 CLi 命令建立。

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fb7d5bd7b23b42b5afd000aee90d1e90~tplv-k3u1fbpfcp-zoom-1.image "13.png")

從前面可以看出，對於定時訊息來說，是在傳送訊息的時候 “做文章”。所以，對於生產者，相對於傳送普通訊息，我們可以在傳送的時候設定期望的投遞時間。

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9b028d8380b94817864be2422c817774~tplv-k3u1fbpfcp-zoom-1.image "14.png")

當定時的時間到了之後，這條訊息其實就是一條投遞到使用者 Topic 的普通訊息而已。所以對於消費者來說，和普通訊息的消費沒有區別。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/15bea3d82e8849619f53b2e6b0cec732~tplv-k3u1fbpfcp-zoom-1.image "15.png")

注意：定時訊息的實現邏輯需要先經過定時儲存等待觸發，定時時間到達後才會被投遞給消費者。因此，如果將大量定時訊息的定時時間設定為同一時刻，則到達該時刻後會有大量訊息同時需要被處理，會造成系統壓力過大。所以一般建議儘量不要設定大量相同觸發時刻的訊息。

點選[此處](https://www.aliyun.com/product/rocketmq)，進入官網瞭解更多詳情～</https:>

RocketMQ 訊息整合：多型別業務訊息——定時訊息

相關文章