一、緣起

---

很多時候，業(yè)務有“在一段時間之后，完成一個工作任務”的需求。

例如：滴滴打車訂單完成后，如果用戶一直不評價，48小時后會將自動評價為5星。

一般來說怎么實現(xiàn)這類“48小時后自動評價為5星”需求呢？

常見方案：啟動一個cron定時任務，每小時跑一次，將完成時間超過48小時的訂單取出，置為5星，并把評價狀態(tài)置為已評價。

假設訂單表的結構為：t_order(oid, finish_time, stars, status, …)，更具體的，定時任務每隔一個小時會這么做一次：

select oid from t_order where finish_time > 48hours and status=0;

update t_order set stars=5 and status=1 where oid in[…];

如果數(shù)據(jù)量很大，需要分頁查詢，分頁update，這將會是一個for循環(huán)。

方案的不足：

（1）輪詢效率比較低

（2）每次掃庫，已經(jīng)被執(zhí)行過記錄，仍然會被掃描（只是不會出現(xiàn)在結果集中），有重復計算的嫌疑

（3）時效性不夠好，如果每小時輪詢一次，最差的情況下，時間誤差會達到1小時

（4）如果通過增加cron輪詢頻率來減少（3）中的時間誤差，（1）中輪詢低效和（2）中重復計算的問題會進一步凸顯

如何利用“延時消息”，對于每個任務只觸發(fā)一次，保證效率的同時保證實時性，是今天要討論的問題。 

二、高效延時消息設計與實現(xiàn)

---

高效延時消息，包含兩個重要的數(shù)據(jù)結構：

（1）環(huán)形隊列，例如可以創(chuàng)建一個包含3600個slot的環(huán)形隊列（本質是個數(shù)組）

（2）任務集合，環(huán)上每一個slot是一個Set<Task>

同時，啟動一個timer，這個timer每隔1s，在上述環(huán)形隊列中移動一格，有一個Current Index指針來標識正在檢測的slot。

Task結構中有兩個很重要的屬性：

（1）Cycle-Num：當Current Index第幾圈掃描到這個Slot時，執(zhí)行任務

（2）Task-Function：需要執(zhí)行的任務指針 

假設當前Current Index指向第一格，當有延時消息到達之后，例如希望3610秒之后，觸發(fā)一個延時消息任務，只需：

（1）計算這個Task應該放在哪一個slot，現(xiàn)在指向1，3610秒之后，應該是第11格，所以這個Task應該放在第11個slot的Set<Task>中

（2）計算這個Task的Cycle-Num，由于環(huán)形隊列是3600格（每秒移動一格，正好1小時），這個任務是3610秒后執(zhí)行，所以應該繞3610/3600=1圈之后再執(zhí)行，于是Cycle-Num=1

Current Index不停的移動，每秒移動到一個新slot，這個slot中對應的Set<Task>，每個Task看Cycle-Num是不是0：

（1）如果不是0，說明還需要多移動幾圈，將Cycle-Num減1

（2）如果是0，說明馬上要執(zhí)行這個Task了，取出Task-Funciton執(zhí)行（可以用單獨的線程來執(zhí)行Task），并把這個Task從Set<Task>中刪除

使用了“延時消息”方案之后，“訂單48小時后關閉評價”的需求，只需將在訂單關閉時，觸發(fā)一個48小時之后的延時消息即可：

（1）無需再輪詢全部訂單，效率高

（2）一個訂單，任務只執(zhí)行一次

（3）時效性好，精確到秒（控制timer移動頻率可以控制精度）

三、總結

---

環(huán)形隊列是一個實現(xiàn)“延時消息”的好方法，開源的MQ好像都不支持延遲消息，不妨自己實現(xiàn)一個簡易的“延時消息隊列”，能解決很多業(yè)務問題，并減少很多低效掃庫的cron任務。

另外，關于MQ的可達性、冪等性未來撰文另述。

如果對文章和配圖滿意的話，幫忙轉發(fā)一下哈。