領導：誰再用 Redis 過期監(jiān)聽實現(xiàn)關閉訂單，立馬滾蛋！

日前拜讀阿牛老師的大作 領導：誰再用定時任務實現(xiàn)關閉訂單，立馬滾蛋！[1] 發(fā)現(xiàn)其方案有若干瑕疵，特此拋磚引玉討論一二。

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

一般實現(xiàn)的方法有幾種：

• 使用 rocketmq、rabbitmq、pulsar 等消息隊列的延時投遞功能
• 使用 redisson 提供的 DelayedQueue

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

• 使用 redis 的過期監(jiān)聽
• 使用 rabbitmq 的死信隊列
• 使用非持久化的時間輪

redis 過期監(jiān)聽

在 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 自動過期的實現(xiàn)方式是：定時任務離線掃描并刪除部分過期鍵；在訪問鍵時惰性檢查是否過期并刪除過期鍵。redis 從未保證會在設定的過期時間立即刪除并發(fā)送過期通知。實際上，過期通知晚于設定的過期時間數(shù)分鐘的情況也比較常見。

此外鍵空間通知采用的是發(fā)送即忘(fire and forget)策略，并不像消息隊列一樣保證送達。當訂閱事件的客戶端會丟失所有在斷線期間所有分發(fā)給它的事件。

這是一種比定時掃描數(shù)據(jù)庫更 “LOW” 的解決方案，請不要使用。

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

rabbitmq 死信

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

• 消息被否定確認（如channel.basicNack) 并且此時requeue 屬性被設置為false。
• 消息在隊列的存活時間超過設置的TTL時間
• 消息隊列的消息數(shù)量已經(jīng)超過最大隊列長度

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

在 rabbitmq 中創(chuàng)建死信隊列的操作流程大概是：

• 創(chuàng)建一個交換機作為死信交換機
• 在業(yè)務隊列中配置 x-dead-letter-exchange 和 x-dead-letter-routing-key，將第一步的交換機設為業(yè)務隊列的死信交換機
• 在死信交換機上創(chuàng)建隊列，并監(jiān)聽此隊列

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

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

這里說點題外話，使用 redis 過期監(jiān)聽或者 rabbitmq 死信隊列做延時任務都是以設計者預想之外的方式使用中間件，這種出其不意必自斃的行為通常會存在某些隱患，比如缺乏一致性和可靠性保證，吞吐量較低、資源泄漏等。比較出名的一個事例是很多人使用 redis 的 list 作為消息隊列，以致于最后作者看不下去寫了 disque 并最后演變?yōu)?redis stream。工作中還是盡量不要濫用中間件，用專業(yè)的組件做專業(yè)的事

時間輪

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

redisson delayqueue

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

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

在數(shù)據(jù)庫索引設計良好的情況下，定時掃描數(shù)據(jù)庫中未完成的訂單產(chǎn)生的開銷并沒有想象中那么大。在使用 redisson delayqueue 等定時任務中間件時可以同時使用掃描數(shù)據(jù)庫的方法作為補償機制，避免中間件故障造成任務丟失。

結論

• 首先推薦使用 rocketmq、pulsar 等擁有定時投遞功能的消息隊列。
• 在不方便獲得專業(yè)消息隊列時可以考慮使用 redisson delayqueue 等基于 redis 的延時隊列方案，但要為 redis 崩潰等情況設計補償保護機制。
• 在無法使用 redisson delayqueue 等方案時可以考慮使用時間輪。由于時間輪重啟遠比 redis 重啟要頻繁，定時掃庫等保護機制更為重要。
• 永遠不要使用 redis 過期監(jiān)聽實現(xiàn)定時任務。

參考：

1. https://juejin.cn/post/6987233263660040206

2. https://juejin.cn/post/6844904158227595271

來源：cnblogs.com/Finley/p/16395466.html