這篇文章主要講解了“怎么選擇web分布式任務(wù)調(diào)度框架”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么選擇web分布式任務(wù)調(diào)度框架”吧！

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

1.背景

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

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

• 一臺(tái)機(jī)器，我們可以將一些不太重要的定時(shí)任務(wù)，可以使用一個(gè)專門的服務(wù)臺(tái)承載，然后使用單機(jī)跑，就算掛了只要我們?cè)倏山邮艿臅r(shí)間之內(nèi)將其恢復(fù)，我們的業(yè)務(wù)也不會(huì)受到影響。

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

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

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

• 首先是單機(jī)問題，如何劃分一個(gè)業(yè)務(wù)不是很重要，這一塊本來就比較復(fù)雜，有可能每個(gè)人都說自己的業(yè)務(wù)都重要，其次是如果單機(jī)掛了 這個(gè)掛有可能是宕機(jī)，有可能是其他的一些情況，這個(gè)時(shí)間如何能保證我們?cè)倏山邮艿姆秶g恢復(fù)，這些都是難點(diǎn)。

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

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

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

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

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

2. 調(diào)研的基本原則

上面第一章講了我們框架的原因，不論你要引入或改進(jìn)什么，都需要原因，因?yàn)樽鋈魏问露加谐杀?，我?jīng)?？吹揭恍┖苄〉捻?xiàng)目就開始搞引入消息隊(duì)列，或者分布式事務(wù)等等，這樣做反而是本末倒置，比如可能有一些博客系統(tǒng)就搞個(gè)消息隊(duì)列削峰減流，這樣做有可能還沒有同步調(diào)用來得快。

當(dāng)我們有了原因之后，就可以著手做一些調(diào)研或者技術(shù)方案的設(shè)計(jì)。這里我講一下我的調(diào)研框架一些基本原則，如果大家以后有類似的調(diào)研框架的需求都可以往這個(gè)里面來套。

• 簡(jiǎn)單-對(duì)開發(fā)者接入簡(jiǎn)單，對(duì)使用者使用簡(jiǎn)單。

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

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

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

• 框架輕量級(jí)，方便根據(jù)自己的需求進(jìn)行定制化。

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

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

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

• 能否解決當(dāng)前的痛點(diǎn)：這個(gè)是最重要的，如果連你問題都解決不了那使用這個(gè)還有什么意義呢？

當(dāng)我們有了上述的幾大原則之后，我們接下來可以進(jìn)入調(diào)研。

3.調(diào)研框架

3.1 TBSchedule

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

3.2 elastic-job

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

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

3.3 一些比較小眾的

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

3.4 XXL-JOB

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

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

xxl-job有下面一些特點(diǎn)：

• 簡(jiǎn)單：支持通過Web頁面對(duì)任務(wù)進(jìn)行CRUD操作，操作簡(jiǎn)單，一分鐘上手；

• 動(dòng)態(tài)：支持動(dòng)態(tài)修改任務(wù)狀態(tài)、啟動(dòng)/停止任務(wù)，以及終止運(yùn)行中任務(wù)，即時(shí)生效；

• 調(diào)度中心HA（中心式）：調(diào)度采用中心式設(shè)計(jì)，“調(diào)度中心”自研調(diào)度組件并支持集群部署，可保證調(diào)度中心HA；

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

• 注冊(cè)中心: 執(zhí)行器會(huì)周期性自動(dòng)注冊(cè)任務(wù), 調(diào)度中心將會(huì)自動(dòng)發(fā)現(xiàn)注冊(cè)的任務(wù)并觸發(fā)執(zhí)行。同時(shí)，也支持手動(dòng)錄入執(zhí)行器地址；

• 彈性擴(kuò)容縮容：一旦有新執(zhí)行器機(jī)器上線或者下線，下次調(diào)度時(shí)將會(huì)重新分配任務(wù)；

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

• 故障轉(zhuǎn)移：任務(wù)路由策略選擇"故障轉(zhuǎn)移"情況下，如果執(zhí)行器集群中某一臺(tái)機(jī)器故障，將會(huì)自動(dòng)Failover切換到一臺(tái)正常的執(zhí)行器發(fā)送調(diào)度請(qǐng)求。

• 阻塞處理策略：調(diào)度過于密集執(zhí)行器來不及處理時(shí)的處理策略，策略包括：?jiǎn)螜C(jī)串行（默認(rèn)）、丟棄后續(xù)調(diào)度、覆蓋之前調(diào)度；

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

• 任務(wù)進(jìn)度監(jiān)控：支持實(shí)時(shí)監(jiān)控任務(wù)進(jìn)度；

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

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