[TOC] ## 概述 常用業務在一段時間之后，完成一個工作任務 如:滴滴打車訂單完成后，如果用戶一直不評價，48小時后會將自動評價為5星 ## 用 cron 定時輪訓(不推薦方案) 方案的不足： 1. 輪詢效率比較低 1. 每次掃庫，已經被執行過記錄，仍然會被掃描（只是不會出現在結果集中），有重復計算的嫌疑 1. 時效性不夠好，如果每小時輪詢一次，最差的情況下，時間誤差會達到1小時 2. 如果通過增加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移動頻率可以控制精度）