作者：Finley
來源：https://www.cnblogs.com/Finley/p/16395466.html
前言
日前拜讀阿牛老師的大作《領導：誰再用定時任務實作關閉訂單，立馬滾蛋！》發現其方案有若干瑕疵，特此拋磚引玉討論一二，
https://juejin.cn/post/6987233263660040206
在電商、支付等領域，往往會有這樣的場景，用戶下單后放棄支付了，那這筆訂單會在指定的時間段后進行關閉操作，
細心的你一定發現了像某寶、某東都有這樣的邏輯，而且時間很準確，誤差在 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的過期監聽》，有興趣的朋友可以自行查閱，
https://juejin.cn/post/6844904158227595271
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，作業中還是盡量不要濫用中間件，用專業的組件做專業的事，
Spring Boot 基礎就不介紹了，推薦看這個免費教程：
https://github.com/javastacks/spring-boot-best-practice
時間輪
時間輪是一種很優秀的定時任務的資料結構，然而絕大多數時間輪實作是純記憶體沒有持久化的，
運行時間輪的行程崩潰之后其中所有的任務都會灰飛煙滅，所以奉勸各位勇士謹慎使用，
| 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 過期監聽實作定時任務，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/509290.html
標籤：其他
上一篇：Redis與Python連接實體
下一篇：Rust-函式