怎么選擇web分布式任務調度框架

這篇文章主要講解了“怎么選擇web分布式任務調度框架”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么選擇web分布式任務調度框架”吧！

1.背景

定時任務是大家再開發中一個不可避免的業務，比如在一些電商系統中可能會定時給用戶發送生日券，一些對賬系統中可能會定時去對賬。大概再很久以前每個服務可能就一臺機器，再這臺機器上直接搞個Timerschedule基本上就能滿足我們的業務需求，但是隨著時代的變遷，單臺機器已經遠遠不能滿足我們的需要，這個時候我們可能需要10臺，20臺甚至更多機器來運行我們的業務，接受我們的流量，這就是我們所說的橫向擴展。但是這里就有個問題，這么多臺機器如果還用我們的Timerschedule去做會發生什么呢？再上面的電商系統中有可能會給某個用戶發很多張生日券，對公司造成很多損失，所以我們需要一些其他方法，讓定時任務在多臺機器上只執行一次。

這里想問下大家在沒有了解過或使用過分布式任務調度框架之前大家是如何做定時任務的呢？在Spring項目中大家肯定都知道Spring-Scheduler，只需要在Spring中的bean的對應方法上加上@Scheduler注解即可完成我們的定時任務，但是光是用這個注解還遠遠不能保證定時任務執行多次，我們需要一些其他手段的保證，一般來說方法可能不外乎下面幾種（都是基于Spring的項目來說）：

• 一臺機器，我們可以將一些不太重要的定時任務，可以使用一個專門的服務臺承載，然后使用單機跑，就算掛了只要我們再可接受的時間之內將其恢復，我們的業務也不會受到影響。

• 多臺機器，加分布式鎖，只要我們執行任務的時候首先獲取一把分布式鎖，如果獲取失敗那么久證明有其他服務已經再運行，如果獲取成功那么證明沒有服務在運行定時任務，那么就可以執行。

• 多臺機器，利用ZooKeeper對Leader機器執行定時任務，有很多業務已經使用了ZK，那么執行定時任務的時候判斷自己是否是Leader，如果不是則不執行，如果是則執行業務邏輯，這樣也能達到我們的目的。

目前我們公司做定時任務也是使用的上面三種方法，在業務初期使用這些方法基本也能大體滿足，但是隨著時間的遷移，我們遇到的問題越來越多，這里和大家分享一下：

• 首先是單機問題，如何劃分一個業務不是很重要，這一塊本來就比較復雜，有可能每個人都說自己的業務都重要，其次是如果單機掛了 這個掛有可能是宕機，有可能是其他的一些情況，這個時間如何能保證我們再可接受的范圍之間恢復，這些都是難點。

• 目前我們使用定時任務的時候，如果想讓它馬上執行一次，這個時候可能就需要額外再寫一個Rest接口或者再另外寫一個單獨的Job。

• 還有個是我們需要更改定時任務執行時間，比如現在有個需求是從每12個小時執行一次變成每6小時執行一次，我們又得修改代碼，提交pr，然后打包上線，只是修改一個時間又得花費我們很多時間。

• 無法暫停我們的定時任務，當我們的定時任務可能出現一些問題，比如一些定時報警的需求，當報警突然變得很多，這個時候需要暫停一下讓其停止發送報警，這個時候可能我們可以用一些分布式配置的開關去做，再邏輯中判斷定時任務開關是否打開，然后來做。這樣做雖然也比較簡單，但是我們這樣需要新添加一些與任務無關的邏輯。

• 缺少對定時任務的監控，任務失敗之后開發人員無從得知，有人說不是有Error日志嗎，如果一個Error日志就一次報警那你們的服務能受得了嗎，一般來說連續幾次Error才會觸發報警，而我們定時任務的周期性的特性是不容易觸發連續的Error。

當然還有一些或多或少的小問題這里就不一一列舉了，如果大家有這種經歷可以自己慢慢體會發現。

2. 調研的基本原則

上面第一章講了我們框架的原因，不論你要引入或改進什么，都需要原因，因為做任何事都有成本，我經常看到一些很小的項目就開始搞引入消息隊列，或者分布式事務等等，這樣做反而是本末倒置，比如可能有一些博客系統就搞個消息隊列削峰減流，這樣做有可能還沒有同步調用來得快。

當我們有了原因之后，就可以著手做一些調研或者技術方案的設計。這里我講一下我的調研框架一些基本原則，如果大家以后有類似的調研框架的需求都可以往這個里面來套。

• 簡單-對開發者接入簡單，對使用者使用簡單。

• 豐富的文檔，有很多開源的項目文檔少之又少，當然還有一些開源項目只有英文文檔，如果你英文不是很行，那可能需要考慮中文居多的文檔。

• 有管理界面，很方便執行操作和統計數據。

• 支持主流框架：比如Spring,Springboot等，當然這個至少要支持你們業務中的主流框架。

• 框架輕量級，方便根據自己的需求進行定制化。

• 高性能，高可靠，高可用：不能讓框架成為業務中的瓶頸。

• 代碼更新頻率和社區使用情況：使用的公司越多證明其越受更多人的喜愛，代碼更新頻率越高證明出現問題就會越少，最好是由大廠開源并且維護。

• 多語言需求：如果在你們業務中有多語言需求，比如你們公司用的開發語言很多，都需要調度框架那么你需要使用多語言支持。比如Rpc支持多語言的代表就是Thrift。

• 能否解決當前的痛點：這個是最重要的，如果連你問題都解決不了那使用這個還有什么意義呢？

當我們有了上述的幾大原則之后，我們接下來可以進入調研。

3.調研框架

3.1 TBSchedule

一般調研Java系的一些框架，可以先看看阿里是不是有開源的，畢竟最近這幾年阿里在開源這一塊做得是非常的好，再網上搜索到阿里在12年開源了一個調度框架叫TBSchedule，現在再去搜索代碼，發現已經人走茶涼，代碼都被清理干凈了。當然還有一個個人項目將其Fork出來再不斷維護，但是使用者實在是少這里就不說明了。 github地址：https://github.com/taobao/TBSchedule

3.2 elastic-job

elastic-Job 是當當開源的一個分布式調度解決方案，由兩個相互獨立的子項目 Elastic-Job-Lite 和 Elastic-Job-Cloud 組成。定位為輕量級無中心化解決方案，使用 jar 包的形式提供分布式任務的協調服務。支持分布式調度協調、彈性擴容縮容、失效轉移、錯過執行作業重觸發、并行調度、自診斷和修復等等功能特性。

這個框架大概在2年前很火，當時使用的公司很多，想必很多人也聽過了，但是很可惜現在已經不在維護了，代碼已經有2年沒有更新了，這里違反了更新頻率的原則，如果出現問題可能都沒什么人幫助你，所以我們并不是很推薦使用。 github地址：https://github.com/elasticjob/elastic-job-lite

3.3 一些比較小眾的

在網上有一些比較小眾的github star很少，更新頻率也很少： Uncode-Schedule，LTS,openCron等等，這些也不符合我們的原則，都不予以考慮

3.4 XXL-JOB

由于分布式定時任務現在還沒有基金會比如CNCF,Apache等，抉擇起來可能不是那么難。不像消息隊列再Apache里面就有好幾個:Kafka,rocketmq,plusar等等，每一個的社區都很龐大，可能選擇是比較困難的。那么我們基本就還剩下兩個選擇，一個是自研，這種任務調度框架，再研發的困難程度上是遠遠比不上消息隊列的研發，所以其實很多公司都選擇了自研，比如：美團的Crane這些。但是對于一些消息隊列這些復雜的中間件可能會選擇二次開發，比如美團的mafka就是基于kafka二次開發，滴滴的DDMQ也是基于Rocketmq。而我們目前如果選擇自研再資源上來說是明顯不夠的，這里我們還是使用的是二次開發框架的策略。

當然這里還剩下一個XXL-Job:http://www.xuxueli.com/xxl-job 的選擇，其基本符合我們的原則，目前代碼也在持續更新，issue作者也在積極的回復，使用的公司也有200多家,其中包括之前的點評，同時其他的原則也很符合。一般來說當你決定選擇某個框架的時候需要詳細的列舉一下優點，好讓其他人得以信服。

xxl-job有下面一些特點：

• 簡單：支持通過Web頁面對任務進行CRUD操作，操作簡單，一分鐘上手；

• 動態：支持動態修改任務狀態、啟動/停止任務，以及終止運行中任務，即時生效；

• 調度中心HA（中心式）：調度采用中心式設計，“調度中心”自研調度組件并支持集群部署，可保證調度中心HA；

• 執行器HA（分布式）：任務分布式執行，任務"執行器"支持集群部署，可保證任務執行HA；

• 注冊中心: 執行器會周期性自動注冊任務, 調度中心將會自動發現注冊的任務并觸發執行。同時，也支持手動錄入執行器地址；

• 彈性擴容縮容：一旦有新執行器機器上線或者下線，下次調度時將會重新分配任務；

• 路由策略：執行器集群部署時提供豐富的路由策略，包括：第一個、最后一個、輪詢、隨機、一致性HASH、最不經常使用、最近最久未使用、故障轉移、忙碌轉移等；

• 故障轉移：任務路由策略選擇"故障轉移"情況下，如果執行器集群中某一臺機器故障，將會自動Failover切換到一臺正常的執行器發送調度請求。

• 阻塞處理策略：調度過于密集執行器來不及處理時的處理策略，策略包括：單機串行（默認）、丟棄后續調度、覆蓋之前調度；

• 事件觸發：除了"Cron方式"和"任務依賴方式"觸發任務執行之外，支持基于事件的觸發任務方式。調度中心提供觸發任務單次執行的API服務，可根據業務事件靈活觸發。

• 任務進度監控：支持實時監控任務進度；

• Rolling實時日志：支持在線查看調度結果，并且支持以Rolling方式實時查看執行器輸出的完整的執行日志

感謝各位的閱讀，以上就是“怎么選擇web分布式任務調度框架”的內容了，經過本文的學習后，相信大家對怎么選擇web分布式任務調度框架這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！