日前拜讀阿牛老師的大作 領導：誰再用定時任務實現關閉訂單，立馬滾蛋！ 發現其方案有若干瑕疵，特此拋磚引玉討論一二。
在電商、支付等領域，往往會有這樣的場景，使用者下單後放棄支付了，那這筆訂單會在指定的時間段後進行關閉操作，細心的你一定發現了像某寶、某東都有這樣的邏輯，而且時間很準確，誤差在1s內；那他們是怎麼實現的呢？
一般實現的方法有幾種：
- 使用 rocketmq、rabbitmq、pulsar 等訊息佇列的延時投遞功能
- 使用 redisson 提供的 DelayedQueue
有一些方案雖然廣為流傳但存在著致命缺陷，不要用來實現延時任務
- 使用 redis 的過期監聽
- 使用 rabbitmq 的死信佇列
- 使用非持久化的時間輪
redis 過期監聽
在 Redis 官方手冊的keyspace-notifications: timing-of-expired-events中明確指出：
Basically expired events are generated when the Redis server deletes the key and not when the time to live theoretically reaches the value of zero
redis 自動過期的實現方式是：定時任務離線掃描並刪除部分過期鍵；在訪問鍵時惰性檢查是否過期並刪除過期鍵。redis 從未保證會在設定的過期時間立即刪除併傳送過期通知。實際上，過期通知晚於設定的過期時間數分鐘的情況也比較常見。
此外來鍵空間通知採用的是傳送即忘(fire and forget)策略，並不像訊息佇列一樣保證送達。當訂閱事件的客戶端會丟失所有在斷線期間所有分發給它的事件。
這是一種比定時掃描資料庫更 “LOW” 的解決方案，請不要使用。
有另一位大佬做了測試 請勿過度依賴Redis的過期監聽, 有興趣的朋友可以自行查閱。
rabbitmq 死信
死信(Dead Letter) 是 rabbitmq 提供的一種機制。當一條訊息滿足下列條件之一那麼它會成為死信：
- 訊息被否定確認（如channel.basicNack) 並且此時requeue 屬性被設定為false。
- 訊息在佇列的存活時間超過設定的TTL時間
- 訊息佇列的訊息數量已經超過最大佇列長度
若配置了死信佇列，死信會被 rabbitmq 投到死信佇列中。
在 rabbitmq 中建立死信佇列的操作流程大概是：
- 建立一個交換機作為死信交換機
- 在業務佇列中配置 x-dead-letter-exchange 和 x-dead-letter-routing-key，將第一步的交換機設為業務佇列的死信交換機
- 在死信交換機上建立佇列，並監聽此佇列
死信佇列的設計目的是為了儲存沒有被正常消費的訊息，便於排查和重新投遞。死信佇列同樣也沒有對投遞時間做出保證，在第一條訊息成為死信之前，後面的訊息即使過期也不會投遞為死信。
為了解決這個問題，rabbit 官方推出了延遲投遞外掛 rabbitmq-delayed-message-exchange ，推薦使用官方外掛來做延時訊息。
這裡說點題外話，使用 redis 過期監聽或者 rabbitmq 死信佇列做延時任務都是以設計者預想之外的方式使用中介軟體，這種出其不意必自斃的行為通常會存在某些隱患，比如缺乏一致性和可靠性保證，吞吐量較低、資源洩漏等。比較出名的一個事例是很多人使用 redis 的 list 作為訊息佇列，以致於最後作者看不下去寫了 disque 並最後演變為 redis stream。工作中還是儘量不要濫用中介軟體，用專業的元件做專業的事
時間輪
時間輪是一種很優秀的定時任務的資料結構，然而絕大多數時間輪實現是純記憶體沒有持久化的。執行時間輪的程式崩潰之後其中所有的任務都會灰飛煙滅，所以奉勸各位勇士謹慎使用。
redisson delayqueue
redisson delayqueue 是一種基於 redis zset 結構的延時佇列實現。delayqueue 中有一個名為 timeoutSetName 的有序集合，其中元素的 score 為投遞時間戳。delayqueue 會定時使用 zrangebyscore 掃描已到投遞時間的訊息，然後把它們移動到就緒訊息列表中。
delayqueue 保證 redis 不崩潰的情況下不會丟失訊息，在沒有更好的解決方案時不妨一試。
在資料庫索引設計良好的情況下，定時掃描資料庫中未完成的訂單產生的開銷並沒有想象中那麼大。在使用 redisson delayqueue 等定時任務中介軟體時可以同時使用掃描資料庫的方法作為補償機制，避免中介軟體故障造成任務丟失。
結論
- 首先推薦使用 rocketmq、pulsar 等擁有定時投遞功能的訊息佇列。
- 在不方便獲得專業訊息佇列時可以考慮使用 redisson delayqueue 等基於 redis 的延時佇列方案，但要為 redis 崩潰等情況設計補償保護機制。
- 在無法使用 redisson delayqueue 等方案時可以考慮使用時間輪。由於時間輪重啟遠比 redis 重啟要頻繁，定時掃庫等保護機制更為重要。
- 永遠不要使用 redis 過期監聽實現定時任務。