使用事件驅動代替定時任務的優點有哪些

這篇文章主要講解了“使用事件驅動代替定時任務的優點有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“使用事件驅動代替定時任務的優點有哪些”吧！

一、定時任務的使用

目前的系統設計中，定時任務是被做為很重要的組件存在的。下面我舉兩個場景，做為貫穿本文的例子。

1. 單據明細的匯總#

比如某家電商超市的銷售明細，需要及時根據某些條件（地點，渠道，甚至供應商、商品等）對前一日的數據進行分類匯總出總的銷售額。

對于這種場景，使用定時任務幾乎是一種思維定式：選一個凌晨系統比較空閑的時間，通過定時任務調度拉取全部需要匯總的數據進行分類匯總。

2. 合同狀態的自動變更#

比如超市和供應商簽署返利合同，合同上面又生效時間字段和當前狀態字段。默認狀態是“待生效”，一旦當前時間達到生效時間后，合同狀態變更為“已生效”。

這種場景也具有明顯的按照時間一刀切的特點，所以使用定時任務幾乎也是唯一的選擇。

二、事件驅動的使用

使用定時任務有什么不好嗎？為什么這里我要推薦事件機制呢？

下面我將用更加符合我們思維方式的基于事件觸發的邏輯來重新設計前面例子中的功能。通過不同方式的對比，你應該能體會到他們直接明顯的差別。

1. 單據明細的匯總#

前面說過，匯總就是拿到需要處理的數據，根據特定的匯總條件，將數據分組然后壓縮。

這里面有幾個關鍵信息：①需要處理的數據，②根據條件分組壓縮。
所以我們先來思考第一個角度：哪些數據是需要處理的。不用想都知道，前一天還沒有匯總的數據就是需要匯總的！其實我想問的不是這個，而是如何拿到這些數據。能拿到才能處理。

很簡單，使用定時任務的話，我們可以通過時間段和是否被處理過的狀態過濾出這批數據。但是如何數據量很大，比如一天有幾千萬，甚至幾十億，想要一次性撈出來然后在內存里面分類匯總怕是有困難。
有人會說了：不怕，處理海量數據我們有經驗：分片處理。使用分片處理的話，我們可以通過一個基礎數據的接口獲取全部正在營業的門店，比如有10萬家，然后將它們按照某種規則分成幾組，各組分別在不同的程序實例中處理（或者同一個程序里順序處理）。如果是關系型數據庫的話，給門店加一個索引基本就能解決。
然后還有一個問題需要考慮：門店每天的銷售量并不固定，甚至有些門店是一天都沒有銷售量的；而給門店分片的策略是固定的，每天哪個分片是哪些門店都是固定的。這樣導致的問題是不同分片內的數據量差異可能很大，造成的分片計算壓力也不同。

如果不使用定時任務，我們還有以下方案可以選擇，而且我覺得比定時任務要好。

a. 延時匯總#

每當一個門店向系統中寫入數據的時候，系統需要判斷當前數據是否是當天的第一次寫入。如果是第一次寫入，則創建一個延時匯總事件（具體的實現可以是定時mq或者定時線程池，但是最好不要使用數據庫，否則我們又需要一個定時任務去掃庫）；這樣的話，沒有業務量的門店就不會被匯總。
為了降低系統壓力，我們具體的延時時間也可以分列開來，不用所有門店都聚集在一起。

但是使用這種方案，相應的一定要做補償。比如使用Java線程池或者akka acotr，如果系統重啟信息就都丟失了；如果使用mq，消息也可能消費失敗。所以我們需要監控和告警機制來輔助。

b. 實時匯總#

每當數據寫入的時候，都判斷一下該數據低匯總維度，然后寫入匯總記錄。如果匯總記錄已經存在了，就直接更新。

這個過程主要要考慮的問題是并發安全，我們可以使用分布式鎖或者數據庫樂觀鎖，甚至mysql的on duplicate key update（參考[https://www.manxi.info/mysqlDuplicate]）。其他問題，比如消峰，可以結合場景判斷。

2. 合同狀態的變更#

這種場景使用定時任務的標志是按某個時間點所有命中某規則的記錄都要被處理。所以我們可以創建一個每天凌晨的定時任務，判斷一下是否有合同在今天需要變成有效（或者標記過期）。但是實際上一年365天可能只有一天這個任務能真正發揮作用，因為其他日期完全命不中記錄 —— 這不是很浪費資源嘛！

針對這種場景，我們可以學習redis對過期鍵的清理策略之懶惰清理。我們不需要一種機制在精準（準精準）的時機變更合同狀態，而是如果這個合同不需要被命中，那么它的狀態在數據庫中一直是之前的狀態：哪怕過了生效期，我們連到數據庫中查看依然是沒有生效。只有當業務邏輯命中這條合同的時候，返回的數據中才需要找到這種合同進行修改。

這種方法可以有效降低系統邏輯中的輪空，但是查詢記錄的時候需要把前一種狀態的記錄也查找到。因為本來我們需要命中的合同是已經生效的，使用懶惰策略就需要把待生效的合同也一起找到，然后從已經生效的合同中剔除已經過期的合同，從待生效的合同中找到已生效的合同；這時候，就需要把已過期和已生效的合同狀態都改掉。當然我們可以使用異步邏輯去處理狀態變更，因為即使處理失敗依然不影響下一次的查詢結果。

事件驅動的好處

從上面的例子中我們可以感受到使用事件觸發機制代替定時任務實際上有利有弊。正向點是事件機制是按需的，有需求就來，沒需要就別來。弊端是為了維護事件機制的正常運行一般需要一套輔助邏輯：但是又有哪種邏輯不需要補償機制呢？只不過有些是成熟的、現成的，有些是需要我們重新開發的。

從本質上講，定時任務是一種無狀態的行為，也就不符合面向對象的思想。而事件觸發是模擬了人去處理一件事的流程。
比如記錄的匯總，在有管信之前運維人員是怎么處理的呢？如果等到第二天把前一天擠壓的單子一起處理，這就是定時任務。如果單子量很大，人工一下子處理不完，就需要多個人一起處理，這就是分布式任務。如果多個人一時半會也處理不好，需要比較長的時間（人工的壓力上來了），他們可能會變通為來一單處理一單，不然一天中大部分的時間也是閑著，這樣壓力就降下來了。對于系統也一樣，實時處理可以有效降低系統壓力驟升。

實際上人工處理積壓單據依然不是定時任務的原型，這樣處理僅僅是因為人工能夠處理得過來，是人性的表現而非模型的轉換。定時任務難以在人身上找到原型，雖然人類現在也在使用鬧鐘，但鬧鐘的任務是提醒而重復任務

再模擬一下合同的處理。
假設沒有管信，合同查找員估計會有幾個格子，一個放待生效的，一個放生效中的，一個放已過期的。當需要找合同的時候，他就去前兩個格子中尋找并把已生效的從第一個格子放到第二個，把已過期的從第二個挪到第三個。
那他可不可能提前挪這些合同呢？可能的，但完全沒必要：這依然是人性 —— 他太懶了。而且他今天挪過以后，可能今天一整天都沒有出現過需要使用合同的時候，那他為什么不在明天挪呢？所以沒有一個合適的時間去挪，干脆用的時候挪。

感謝各位的閱讀，以上就是“使用事件驅動代替定時任務的優點有哪些”的內容了，經過本文的學習后，相信大家對使用事件驅動代替定時任務的優點有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！