CTO 說了:誰再用 Redis 過期監聽實現定時任務,立馬滾蛋!

作者: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開發手冊(嵩山版)》最新發布,速速下載!

覺得不錯,別忘了隨手點贊+轉發哦!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章