時間輪資料庫

『壹』 建議不要使用，redis過期監聽實現關閉訂單

在電商、支付等領域，往往會有這樣的場景，用戶下單後放棄支付了，那這筆訂單會在指定的時間段後進行關閉操作，細心的你一定發現了像某寶、某東都有這樣的邏輯，而且時間很准確，誤差在1s內；那他們是怎麼實現的呢？

一般實現的方法有幾種：

有一些方案雖然廣為流傳但存在著致命缺陷，不要用來實現延時任務

在 Redis 官方手冊的keyspace-notifications: timing-of-expired-events中明確指出：

redis 自動過期的實現方式是：定時任務離線掃描並刪除 部分 過期鍵；在訪問鍵時惰性檢查是否過期並刪除過期鍵。redis 從未保證會在設定的過期時間立即刪除並發送過期通知。實際上，過期通知晚於設定的過期時間數分鍾的情況也比較常見。

這是一種比定時掃描資料庫更 「LOW」 的解決方案，請不要使用。

有另一位大佬做了測試 請勿過度依賴Redis的過期監聽, 有興趣的朋友可以自行查閱。

死信(Dead Letter) 是 rabbitmq 提供的一種機制。當一條消息滿足下列條件之一那麼它會成為死信：

若配置了死信隊列，死信會被 rabbitmq 投到死信隊列中。

在 rabbitmq 中創建死信隊列的操作流程大概是：

死信隊列的設計目的是為了存儲沒有被正常消費的消息，便於排查和重新投遞。 死信隊列同樣也沒有對投遞時間做出保證，在第一條消息成為死信之前，後面的消息即使過期也不會投遞為死信 。

為了解決這個問題，rabbit 官方推出了延遲投遞插件 rabbitmq-delayed-message-exchange ，推薦使用官方插件來做延時消息。

時間輪是一種很優秀的定時任務的數據結構，然而絕大多數時間輪實現是純內存沒有持久化的。運行時間輪的進程崩潰之後其中所有的任務都會灰飛煙滅，所以奉勸各位勇士謹慎使用。

redisson delayqueue 是一種基於 redis zset 結構的延時隊列實現。delayqueue 中有一個名為 timeoutSetName 的有序集合，其中元素的 score 為投遞時間戳。delayqueue 會定時使用 zrangebyscore 掃描已到投遞時間的消息，然後把它們移動到就緒消息列表中。

delayqueue 保證 redis 不崩潰的情況下不會丟失消息，在沒有更好的解決方案時不妨一試。

在資料庫索引設計良好的情況下，定時掃描資料庫中未完成的訂單產生的開銷並沒有想像中那麼大。在使用 redisson delayqueue 等定時任務中間件時可以同時使用掃描資料庫的方法作為補償機制，避免中間件故障造成任務丟失。

文章來自https://www.cnblogs.com/Finley/p/16395466.html