很多時候,業務有“在一段時間之后,完成一個工作任務”的需求。
例如:滴滴打車訂單完成后,如果用戶一直不評價,48小時后會將自動評價為5星。
一般來說怎么實現這類“48小時后自動評價為5星”需求呢?
常見方案:啟動一個cron定時任務,每小時跑一次,將完成時間超過48小時的訂單取出,置為5星,並把評價狀態置為已評價。
假設訂單表的結構為: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[…];
如果數據量很大,需要分頁查詢,分頁update,這將會是一個for循環。
方案的不足:
(1)輪詢效率比較低
(2)每次掃庫,已經被執行過記錄,仍然會被掃描(只是不會出現在結果集中),有重復計算的嫌疑
(3)時效性不夠好,如果每小時輪詢一次,最差的情況下,時間誤差會達到1小時
(4)如果通過增加cron輪詢頻率來減少(3)中的時間誤差,(1)中輪詢低效和(2)中重復計算的問題會進一步凸顯
如何利用“延時消息”,對於每個任務只觸發一次,保證效率的同時保證實時性,是今天要討論的問題。
二、高效延時消息設計與實現
高效延時消息,包含兩個重要的數據結構:
(1)環形隊列,例如可以創建一個包含3600個slot的環形隊列(本質是個數組)
(2)任務集合,環上每一個slot是一個Set<Task>
同時,啟動一個timer,這個timer每隔1s,在上述環形隊列中移動一格,有一個Current Index指針來標識正在檢測的slot。
Task結構中有兩個很重要的屬性:
(1)Cycle-Num:當Current Index第幾圈掃描到這個Slot時,執行任務
(2)Task-Function:需要執行的任務指針
假設當前Current Index指向第一格,當有延時消息到達之后,例如希望3610秒之后,觸發一個延時消息任務,只需:
(1)計算這個Task應該放在哪一個slot,現在指向1,3610秒之后,應該是第11格,所以這個Task應該放在第11個slot的Set<Task>中
(2)計算這個Task的Cycle-Num,由於環形隊列是3600格(每秒移動一格,正好1小時),這個任務是3610秒后執行,所以應該繞3610/3600=1圈之后再執行,於是Cycle-Num=1
Current Index不停的移動,每秒移動到一個新slot,這個slot中對應的Set<Task>,每個Task看Cycle-Num是不是0:
(1)如果不是0,說明還需要多移動幾圈,將Cycle-Num減1
(2)如果是0,說明馬上要執行這個Task了,取出Task-Funciton執行(可以用單獨的線程來執行Task),並把這個Task從Set<Task>中刪除
使用了“延時消息”方案之后,“訂單48小時后關閉評價”的需求,只需將在訂單關閉時,觸發一個48小時之后的延時消息即可:
(1)無需再輪詢全部訂單,效率高
(2)一個訂單,任務只執行一次
(3)時效性好,精確到秒(控制timer移動頻率可以控制精度)
三、總結
環形隊列是一個實現“延時消息”的好方法,開源的MQ好像都不支持延遲消息,不妨自己實現一個簡易的“延時消息隊列”,能解決很多業務問題,並減少很多低效掃庫的cron任務。
另外,關於MQ的可達性、冪等性未來撰文另述。