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

創(chuàng)新互聯-專業(yè)網站定制、快速模板網站建設、高性價比徐水網站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式徐水網站制作公司更省心,省錢,快速模板網站建設找我們，業(yè)務覆蓋徐水地區(qū)。費用合理售后完善，10余年實體公司更值得信賴。

1.背景

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

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

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

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

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

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

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

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

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

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

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

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

2. 調研的基本原則

上面第一章講了我們框架的原因，不論你要引入或改進什么，都需要原因，因為做任何事都有成本，我經?？吹揭恍┖苄〉捻椖烤烷_始搞引入消息隊列，或者分布式事務等等，這樣做反而是本末倒置，比如可能有一些博客系統(tǒng)就搞個消息隊列削峰減流，這樣做有可能還沒有同步調用來得快。

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

• 簡單-對開發(fā)者接入簡單，對使用者使用簡單。

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

• 有管理界面，很方便執(zhí)行操作和統(tǒng)計數據。

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

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

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

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

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

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

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

3.調研框架

3.1 TBSchedule

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

3.2 elastic-job

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

這個框架大概在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等等，每一個的社區(qū)都很龐大，可能選擇是比較困難的。那么我們基本就還剩下兩個選擇，一個是自研，這種任務調度框架，再研發(fā)的困難程度上是遠遠比不上消息隊列的研發(fā)，所以其實很多公司都選擇了自研，比如：美團的Crane這些。但是對于一些消息隊列這些復雜的中間件可能會選擇二次開發(fā)，比如美團的mafka就是基于kafka二次開發(fā)，滴滴的DDMQ也是基于Rocketmq。而我們目前如果選擇自研再資源上來說是明顯不夠的，這里我們還是使用的是二次開發(fā)框架的策略。

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

xxl-job有下面一些特點：

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

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

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

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

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

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

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

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

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

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

• 任務進度監(jiān)控：支持實時監(jiān)控任務進度；

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

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

文章名稱：怎么選擇web分布式任務調度框架
URL網址：http://chinadenli.net/article30/poogpo.html

成都網站建設公司_創(chuàng)新互聯，為您提供靜態(tài)網站、全網營銷推廣、小程序開發(fā)、App開發(fā)、網站設計、標簽優(yōu)化

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯