CSS單標(biāo)簽實(shí)現(xiàn)轉(zhuǎn)轉(zhuǎn)logo
轉(zhuǎn)轉(zhuǎn)品牌升級(jí)后更新了全新的Logo，今天我們用純CSS來實(shí)現(xiàn)轉(zhuǎn)轉(zhuǎn)的新Logo，為了有一定的挑戰(zhàn)性，這里我們只使用一個(gè)標(biāo)簽實(shí)現(xiàn)，將最大化的使用CSS能力完成Logo的繪制與動(dòng)畫效果。新logo
這里還是老樣子，為了保證文章的完整性和連貫性，方便那些沒有使用過的小伙伴更加容易接受文章的內(nèi)容，快速講一講Xxl-Job中的概念和使用
如果你已經(jīng)使用過了，可直接跳過本節(jié)和下一節(jié)，快進(jìn)到后面原理部分講解
調(diào)度中心是一個(gè)單獨(dú)的Web服務(wù)，主要是用來觸發(fā)定時(shí)任務(wù)的執(zhí)行
它提供了一些頁面操作，我們可以很方便地去管理這些定時(shí)任務(wù)的觸發(fā)邏輯
調(diào)度中心依賴數(shù)據(jù)庫，所以數(shù)據(jù)都是存在數(shù)據(jù)庫中的
調(diào)度中心也支持集群模式，但是它們所依賴的數(shù)據(jù)庫必須是同一個(gè)
所以同一個(gè)集群中的調(diào)度中心實(shí)例之間是沒有任何通信的，數(shù)據(jù)都是通過數(shù)據(jù)庫共享的
圖片
執(zhí)行器是用來執(zhí)行具體的任務(wù)邏輯的
執(zhí)行器你可以理解為就是平時(shí)開發(fā)的服務(wù)，一個(gè)服務(wù)實(shí)例對(duì)應(yīng)一個(gè)執(zhí)行器實(shí)例
每個(gè)執(zhí)行器有自己的名字，為了方便，你可以將執(zhí)行器的名字設(shè)置成服務(wù)名
任務(wù)什么意思就不用多說了
一個(gè)執(zhí)行器中也是可以有多個(gè)任務(wù)的
總的來說，調(diào)用中心是用來控制定時(shí)任務(wù)的觸發(fā)邏輯，而執(zhí)行器是具體執(zhí)行任務(wù)的，這是一種任務(wù)和觸發(fā)邏輯分離的設(shè)計(jì)思想，這種方式的好處就是使任務(wù)更加靈活，可以隨時(shí)被調(diào)用，還可以被不同的調(diào)度規(guī)則觸發(fā)。
圖片
調(diào)度中心搭建很簡(jiǎn)單，先下載源碼
https://github.com/xuxueli/xxl-job.git
然后改一下數(shù)據(jù)庫連接信息，執(zhí)行一下在項(xiàng)目源碼中的/doc/db下的sql文件
圖片
啟動(dòng)可以打成一個(gè)jar包，或者本地啟動(dòng)就是可以的
啟動(dòng)完成之后，訪問下面這個(gè)地址就可以訪問到控制臺(tái)頁面了
http://localhost:8080/xxl-job-admin/toLogin
用戶名密碼默認(rèn)是 admin/123456
添加一個(gè)名為sanyou-xxljob-demo執(zhí)行器
圖片
任務(wù)添加
圖片
執(zhí)行器選擇我們剛剛添加的，指定任務(wù)名稱為TestJob，corn表達(dá)式的意思是每秒執(zhí)行一次
創(chuàng)建完之后需要啟動(dòng)一下任務(wù)，默認(rèn)是關(guān)閉狀態(tài)，也就不會(huì)執(zhí)行
圖片
創(chuàng)建執(zhí)行器和任務(wù)其實(shí)就是CRUD，并沒有復(fù)雜的業(yè)務(wù)邏輯
按照如上配置的整個(gè)Demo的意思就是
每隔1s，執(zhí)行一次sanyou-xxljob-demo這個(gè)執(zhí)行器中的TestJob任務(wù)
引入依賴
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>2.2.5.RELEASE</version> </dependency> <dependency> <groupId>com.xuxueli</groupId> <artifactId>xxl-job-core</artifactId> <version>2.4.0</version> </dependency></dependencies>配置XxlJobSpringExecutor這個(gè)Bean
@Configurationpublic class XxlJobConfiguration { @Bean public XxlJobSpringExecutor xxlJobExecutor() { XxlJobSpringExecutor xxlJobSpringExecutor = new XxlJobSpringExecutor(); //設(shè)置調(diào)用中心的連接地址 xxlJobSpringExecutor.setAdminAddresses("http://localhost:8080/xxl-job-admin"); //設(shè)置執(zhí)行器的名稱 xxlJobSpringExecutor.setAppname("sanyou-xxljob-demo"); //設(shè)置一個(gè)端口，后面會(huì)講作用 xxlJobSpringExecutor.setPort(9999); //這個(gè)token是保證訪問安全的，默認(rèn)是這個(gè)，當(dāng)然可以自定義， // 但需要保證調(diào)度中心配置的xxl.job.accessToken屬性跟這個(gè)token是一樣的 xxlJobSpringExecutor.setAccessToken("default_token"); //任務(wù)執(zhí)行日志存放的目錄 xxlJobSpringExecutor.setLogPath("./"); return xxlJobSpringExecutor; }}XxlJobSpringExecutor這個(gè)類的作用，后面會(huì)著重講
通過@XxlJob指定一個(gè)名為TestJob的任務(wù)，這個(gè)任務(wù)名需要跟前面頁面配置的對(duì)應(yīng)上
@Componentpublic class TestJob { private static final Logger logger = LoggerFactory.getLogger(TestJob.class); @XxlJob("TestJob") public void testJob() { logger.info("TestJob任務(wù)執(zhí)行了。。。"); }}所以如果順利的話，每隔1s鐘就會(huì)打印一句TestJob任務(wù)執(zhí)行了。。。
啟動(dòng)項(xiàng)目，注意修改一下端口，因?yàn)檎{(diào)用中心默認(rèn)也是8080，本地起會(huì)端口沖突
最終執(zhí)行結(jié)果如下，符合預(yù)期
圖片
講完概念和使用部分，接下來就來好好講一講Xxl-Job核心的實(shí)現(xiàn)原理
前面Demo中使用到了一個(gè)很重要的一個(gè)類
XxlJobSpringExecutor
這個(gè)類就是整個(gè)執(zhí)行器啟動(dòng)的入口
圖片
這個(gè)類實(shí)現(xiàn)了SmartInitializingSingleton接口
所以經(jīng)過Bean的生命周期，一定會(huì)調(diào)用afterSingletonsInstantiated這個(gè)方法的實(shí)現(xiàn)
這個(gè)方法干了很多初始化的事，這里我挑三個(gè)重要的講，其余的等到具體的功能的時(shí)候再提
JobHandler是個(gè)什么？
所謂的JobHandler其實(shí)就是一個(gè)定時(shí)任務(wù)的封裝
圖片
一個(gè)定時(shí)任務(wù)會(huì)對(duì)應(yīng)一個(gè)JobHandler對(duì)象
當(dāng)執(zhí)行器執(zhí)行任務(wù)的時(shí)候，就會(huì)調(diào)用JobHandler的execute方法
JobHandler有三種實(shí)現(xiàn)：
MethodJobHandler是通過反射來調(diào)用方法執(zhí)行任務(wù)
圖片
所以MethodJobHandler的任務(wù)的實(shí)現(xiàn)就是一個(gè)方法，剛好我們demo中的例子任務(wù)其實(shí)就是一個(gè)方法
所以Demo中的任務(wù)最終被封裝成一個(gè)MethodJobHandler
GlueJobHandler比較有意思，它支持動(dòng)態(tài)修改任務(wù)執(zhí)行的代碼
當(dāng)你在創(chuàng)建任務(wù)的時(shí)候，需要指定運(yùn)行模式為GLUE(Java)
圖片
之后需要在操作按鈕點(diǎn)擊GLUE IDE編寫Java代碼
圖片
代碼必須得實(shí)現(xiàn)IJobHandler接口，之后任務(wù)執(zhí)行的時(shí)候就會(huì)執(zhí)行execute方法的實(shí)現(xiàn)
如果你需要修改任務(wù)的邏輯，只需要重新編輯即可，不需要重啟服務(wù)
ScriptJobHandler，通過名字也可以看出，是專門處理一些腳本的
運(yùn)行模式除了BEAN和GLUE(Java)之外，其余都是腳本模式
而本節(jié)的主旨，所謂的初始化JobHandler就是指，執(zhí)行器啟動(dòng)的時(shí)候會(huì)去Spring容器中找到加了@XxlJob注解的Bean
解析注解，然后封裝成一個(gè)MethodJobHandler對(duì)象，最終存到XxlJobSpringExecutor成員變量的一個(gè)本地的Map緩存中
圖片
緩存key就是任務(wù)的名字
圖片
至于GlueJobHandler和ScriptJobHandler都是任務(wù)觸發(fā)時(shí)才會(huì)創(chuàng)建
除了上面這幾種，你也自己實(shí)現(xiàn)JobHandler，手動(dòng)注冊(cè)到JobHandler的緩存中，也是可以通過調(diào)度中心觸發(fā)的
除了初始化JobHandler之外，執(zhí)行器還會(huì)創(chuàng)建一個(gè)Http服務(wù)器
這個(gè)服務(wù)器端口號(hào)就是通過XxlJobSpringExecutor配置的端口，demo中就是設(shè)置的是9999，底層是基于Netty實(shí)現(xiàn)的
圖片
這個(gè)Http服務(wù)端會(huì)接收來自調(diào)度中心的請(qǐng)求
當(dāng)執(zhí)行器接收到調(diào)度中心的請(qǐng)求時(shí)，會(huì)把請(qǐng)求交給ExecutorBizImpl來處理
圖片
這個(gè)類非常重要，所有調(diào)度中心的請(qǐng)求都是這里處理的
ExecutorBizImpl實(shí)現(xiàn)了ExecutorBiz接口
當(dāng)你翻源碼的時(shí)候會(huì)發(fā)現(xiàn)，ExecutorBiz還有一個(gè)ExecutorBizClient實(shí)現(xiàn)
圖片
ExecutorBizClient的實(shí)現(xiàn)就是發(fā)送http請(qǐng)求，所以這個(gè)實(shí)現(xiàn)類是在調(diào)度中心使用的，用來訪問執(zhí)行器提供的http接口
圖片
當(dāng)執(zhí)行器啟動(dòng)的時(shí)候，會(huì)啟動(dòng)一個(gè)注冊(cè)線程，這個(gè)線程會(huì)往調(diào)度中心注冊(cè)當(dāng)前執(zhí)行器的信息，包括兩部分?jǐn)?shù)據(jù)
前面提到每個(gè)服務(wù)實(shí)例都會(huì)對(duì)應(yīng)一個(gè)執(zhí)行器實(shí)例，所以調(diào)用中心會(huì)保存每個(gè)執(zhí)行器實(shí)例的地址
圖片
這里你可以把調(diào)度中心的功能類比成注冊(cè)中心
弄明白執(zhí)行器啟動(dòng)時(shí)干了哪些事，接下來講一講Xxl-Job最最核心的功能，那就是任務(wù)觸發(fā)的原理
任務(wù)觸發(fā)原理我會(huì)分下面5個(gè)小點(diǎn)來講解
調(diào)度中心在啟動(dòng)的時(shí)候，會(huì)開啟一個(gè)線程，這個(gè)線程的作用就是來計(jì)算任務(wù)觸發(fā)時(shí)機(jī)，這里我把這個(gè)線程稱為調(diào)度線程
這個(gè)調(diào)度線程會(huì)去查詢xxl_job_info這張表
這張表存了任務(wù)的一些基本信息和任務(wù)下一次執(zhí)行的時(shí)間
調(diào)度線程會(huì)去查詢下一次執(zhí)行的時(shí)間 <= 當(dāng)前時(shí)間 + 5s的任務(wù)
這個(gè)5s是XxlJob寫死的，被稱為預(yù)讀時(shí)間，提前讀出來，保證任務(wù)能準(zhǔn)時(shí)觸發(fā)
舉個(gè)例子，假設(shè)當(dāng)前時(shí)間是2023-11-29 08:00:10，這里的查詢就會(huì)查出下一次任務(wù)執(zhí)行時(shí)間在2023-11-29 08:00:15之前執(zhí)行的任務(wù)
圖片
查詢到任務(wù)之后，調(diào)度線程會(huì)去將這些任務(wù)根據(jù)執(zhí)行時(shí)間劃分為三個(gè)部分：
圖片
對(duì)于第一部分的已經(jīng)超過5s以上時(shí)間的任務(wù)，會(huì)根據(jù)任務(wù)配置的調(diào)度過期策略來選擇要不要執(zhí)行
圖片
調(diào)度過期策略就兩種，就是字面意思
對(duì)于第二部分的超時(shí)時(shí)間在5s以內(nèi)的任務(wù)，就直接立馬執(zhí)行一次，之后如果判斷任務(wù)下一次執(zhí)行時(shí)間就在5s內(nèi)，會(huì)直接放到一個(gè)時(shí)間輪里面，等待下一次觸發(fā)執(zhí)行
對(duì)于第三部分任務(wù)，由于還沒到執(zhí)行時(shí)間，所以不會(huì)立馬執(zhí)行，也是直接放到時(shí)間輪里面，等待觸發(fā)執(zhí)行
當(dāng)這批任務(wù)處理完成之后，不論是前面是什么情況，調(diào)度線程都會(huì)去重新計(jì)算每個(gè)任務(wù)的下一次觸發(fā)時(shí)間，然后更新xxl_job_info這張表的下一次執(zhí)行時(shí)間
到此，一次調(diào)度的計(jì)算就算完成了
之后調(diào)度線程還會(huì)繼續(xù)重復(fù)上面的步驟，查任務(wù)，調(diào)度任務(wù)，更新任務(wù)下次執(zhí)行時(shí)間，一直死循環(huán)下去，這就實(shí)現(xiàn)了任務(wù)到了執(zhí)行時(shí)間就會(huì)觸發(fā)的功能
這里在任務(wù)觸發(fā)的時(shí)候還有一個(gè)很有意思的細(xì)節(jié)
由于調(diào)度中心可以是集群的形式，每個(gè)調(diào)度中心實(shí)例都有調(diào)度線程，那么如何保證任務(wù)在同一時(shí)間只會(huì)被其中的一個(gè)調(diào)度中心觸發(fā)一次？
我猜你第一時(shí)間肯定想到分布式鎖，但是怎么加呢？
XxlJob實(shí)現(xiàn)就比較有意思了，它是基于八股文中常說的通過數(shù)據(jù)庫來實(shí)現(xiàn)的分布式鎖的
在調(diào)度之前，調(diào)度線程會(huì)嘗試執(zhí)行下面這句sql
圖片
就是這個(gè)sql
select * from xxl_job_lock where lock_name = 'schedule_lock' for update
一旦執(zhí)行成功，說明當(dāng)前調(diào)度中心成功搶到了鎖，接下來就可以執(zhí)行調(diào)度任務(wù)了
當(dāng)調(diào)度任務(wù)執(zhí)行完之后再去關(guān)閉連接，從而釋放鎖
由于每次執(zhí)行之前都需要去獲取鎖，這樣就保證在調(diào)度中心集群中，同時(shí)只有一個(gè)調(diào)度中心執(zhí)行調(diào)度任務(wù)
最后畫一張圖來總結(jié)一下這一小節(jié)
圖片
當(dāng)任務(wù)達(dá)到了觸發(fā)條件，并不是由調(diào)度線程直接去觸發(fā)執(zhí)行器的任務(wù)執(zhí)行
調(diào)度線程會(huì)將這個(gè)觸發(fā)的任務(wù)交給線程池去執(zhí)行
所以上圖中的最后一部分觸發(fā)任務(wù)執(zhí)行其實(shí)是線程池異步去執(zhí)行的
那么，為什么要使用線程池異步呢？
主要是因?yàn)橛|發(fā)任務(wù)，需要通過Http接口調(diào)用具體的執(zhí)行器實(shí)例去觸發(fā)任務(wù)
圖片
這一過程必然會(huì)耗費(fèi)時(shí)間，如果調(diào)度線程去做，就會(huì)耽誤調(diào)度的效率
所以就通過異步線程去做，調(diào)度線程只負(fù)責(zé)判斷任務(wù)是否需要執(zhí)行
并且，Xxl-Job為了進(jìn)一步優(yōu)化任務(wù)的觸發(fā)，將這個(gè)觸發(fā)任務(wù)執(zhí)行的線程池劃分成快線程池和慢線程池兩個(gè)線程池
圖片
在調(diào)用執(zhí)行器的Http接口觸發(fā)任務(wù)執(zhí)行的時(shí)候，Xxl-Job會(huì)去記錄每個(gè)任務(wù)的觸發(fā)所耗費(fèi)的時(shí)間
注意并不是任務(wù)執(zhí)行時(shí)間，只是整個(gè)Http請(qǐng)求耗時(shí)時(shí)間，這是因?yàn)閳?zhí)行器執(zhí)行任務(wù)是異步執(zhí)行的，所以整個(gè)時(shí)間不包括任務(wù)執(zhí)行時(shí)間，這個(gè)后面會(huì)詳細(xì)說
當(dāng)任務(wù)一次觸發(fā)的時(shí)間超過500ms，那么這個(gè)任務(wù)的慢次數(shù)就會(huì)加1
如果這個(gè)任務(wù)一分鐘內(nèi)觸發(fā)的慢次數(shù)超過10次，接下來就會(huì)將觸發(fā)任務(wù)交給慢線程池去執(zhí)行
所以快慢線程池就是避免那種頻繁觸發(fā)并且每次觸發(fā)時(shí)間還很長(zhǎng)的任務(wù)阻塞其它任務(wù)的觸發(fā)的情況發(fā)生
上一節(jié)說到，當(dāng)任務(wù)需要觸發(fā)的時(shí)候，調(diào)度中心會(huì)向執(zhí)行器發(fā)送Http請(qǐng)求，執(zhí)行器去執(zhí)行具體的任務(wù)
那么問題來了
由于一個(gè)執(zhí)行器會(huì)有很多實(shí)例，那么應(yīng)該向哪個(gè)實(shí)例請(qǐng)求？
這其實(shí)就跟任務(wù)配置時(shí)設(shè)置的路由策略有關(guān)了
圖片
從圖上可以看出xxljob支持多種路由策略
除了分片廣播，其余的具體的算法實(shí)現(xiàn)都是通過ExecutorRouter的實(shí)現(xiàn)類來實(shí)現(xiàn)的
圖片
這里簡(jiǎn)單講一講各種算法的原理，有興趣的小伙伴可以去看看內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)
第一個(gè)、最后一個(gè)、輪詢、隨機(jī)都很簡(jiǎn)單，沒什么好說的
一致性Hash講起來比較復(fù)雜，你可以先看看這篇文章，再去查看Xxl-Job的代碼實(shí)現(xiàn)
https://zhuanlan.zhihu.com/p/470368641
最不經(jīng)常使用（LFU：Least Frequently Used）：Xxl-Job內(nèi)部會(huì)有一個(gè)緩存，統(tǒng)計(jì)每個(gè)任務(wù)每個(gè)地址的使用次數(shù)，每次都選擇使用次數(shù)最少的地址，這個(gè)緩存每隔24小時(shí)重置一次
最近最久未使用（LRU：Least Recently Used）：將地址存到LinkedHashMap中，它利用LinkedHashMap可以根據(jù)元素訪問（get/put）順序來給元素排序的特性，快速找到最近最久未使用（未訪問）的節(jié)點(diǎn)
故障轉(zhuǎn)移：調(diào)度中心都會(huì)去請(qǐng)求每個(gè)執(zhí)行器，只要能接收到響應(yīng)，說明執(zhí)行器正常，那么任務(wù)就會(huì)交給這個(gè)執(zhí)行器去執(zhí)行
忙碌轉(zhuǎn)移：調(diào)度中心也會(huì)去請(qǐng)求每個(gè)執(zhí)行器，判斷執(zhí)行器是不是正在執(zhí)行當(dāng)前需要執(zhí)行的任務(wù)（任務(wù)執(zhí)行時(shí)間過長(zhǎng)，導(dǎo)致上一次任務(wù)還沒執(zhí)行完，下一次又觸發(fā)了），如果在執(zhí)行，說明忙碌，不能用，否則就可以用
分片廣播：XxlJob給每個(gè)執(zhí)行器分配一個(gè)編號(hào)，從0開始遞增，然后向所有執(zhí)行器觸發(fā)任務(wù)，告訴每個(gè)執(zhí)行器自己的編號(hào)和總共執(zhí)行器的數(shù)據(jù)
我們可以通過XxlJobHelper#getShardIndex獲取到編號(hào)，XxlJobHelper#getShardTotal獲取到執(zhí)行器的總數(shù)據(jù)量
分片廣播就是將任務(wù)量分散到各個(gè)執(zhí)行器，每個(gè)執(zhí)行器只執(zhí)行一部分任務(wù)，加快任務(wù)的處理
舉個(gè)例子，比如你現(xiàn)在需要處理30w條數(shù)據(jù)，有3個(gè)執(zhí)行器，此時(shí)使用分片廣播，那么此時(shí)可將任務(wù)分成3分，每份10w條數(shù)據(jù)，執(zhí)行器根據(jù)自己的編號(hào)選擇對(duì)應(yīng)的那份10w數(shù)據(jù)處理
圖片
當(dāng)選擇好了具體的執(zhí)行器實(shí)例之后，調(diào)用中心就會(huì)攜帶一些觸發(fā)的參數(shù)，發(fā)送Http請(qǐng)求，觸發(fā)任務(wù)
相信你一定記得我前面在說執(zhí)行器啟動(dòng)是會(huì)創(chuàng)建一個(gè)Http服務(wù)器的時(shí)候提到這么一句
當(dāng)執(zhí)行器接收到調(diào)度中心的請(qǐng)求時(shí)，會(huì)把請(qǐng)求交給ExecutorBizImpl來處理
所以前面提到的故障轉(zhuǎn)移和忙碌轉(zhuǎn)移請(qǐng)求執(zhí)行器進(jìn)行判斷，最終執(zhí)行器也是交給ExecutorBizImpl處理的
執(zhí)行器處理觸發(fā)請(qǐng)求是這個(gè)ExecutorBizImpl的run方法實(shí)現(xiàn)的
圖片
當(dāng)執(zhí)行器接收到請(qǐng)求，在正常情況下，執(zhí)行器會(huì)去為這個(gè)任務(wù)創(chuàng)建一個(gè)單獨(dú)的線程，這個(gè)線程被稱為JobThread
每個(gè)任務(wù)在觸發(fā)的時(shí)候都有單獨(dú)的線程去執(zhí)行，保證不同的任務(wù)執(zhí)行互不影響
之后任務(wù)并不是直接交給線程處理的，而是直接放到一個(gè)內(nèi)存隊(duì)列中，線程直接從隊(duì)列中獲取任務(wù)
圖片
這里我相信你一定有個(gè)疑惑
為什么不直接處理，而是交給隊(duì)列，從隊(duì)列中獲取任務(wù)呢？
那就得講講不正常的情況了
如果調(diào)度中心選擇的執(zhí)行器實(shí)例正在處理定時(shí)任務(wù)，那么此時(shí)該怎么處理呢？**
這時(shí)就跟阻塞處理策略有關(guān)了
圖片
阻塞處理策略總共有三種：
單機(jī)串行的實(shí)現(xiàn)就是將任務(wù)放到隊(duì)列中，由于隊(duì)列是先進(jìn)先出的，所以就實(shí)現(xiàn)串行，這也是為什么放在隊(duì)列的原因
丟棄調(diào)度的實(shí)現(xiàn)就是執(zhí)行器什么事都不用干就可以了，自然而然任務(wù)就丟了
覆蓋之前調(diào)度的實(shí)現(xiàn)就很暴力了，他是直接重新創(chuàng)建一個(gè)JobThread來執(zhí)行任務(wù)，并且嘗試打斷之前的正在處理任務(wù)的JobThread，丟棄之前隊(duì)列中的任務(wù)
打斷是通過Thread#interrupt方法實(shí)現(xiàn)的，所以正在處理的任務(wù)還是有可能繼續(xù)運(yùn)行，并不是說一打斷正在運(yùn)行的任務(wù)就終止了
這里需要注意的一點(diǎn)就是，阻塞處理策略是對(duì)于單個(gè)執(zhí)行器上的任務(wù)來生效的，不同執(zhí)行器實(shí)例上的同一個(gè)任務(wù)是互不影響的
比如說，有一個(gè)任務(wù)有兩個(gè)執(zhí)行器A和B，路由策略是輪詢
任務(wù)第一次觸發(fā)的時(shí)候選擇了執(zhí)行器實(shí)例A，由于任務(wù)執(zhí)行時(shí)間長(zhǎng)，任務(wù)第二次觸發(fā)的時(shí)候，執(zhí)行器的路由到了B，此時(shí)A的任務(wù)還在執(zhí)行，但是B感知不到A的任務(wù)在執(zhí)行，所以此時(shí)B就直接執(zhí)行了任務(wù)
所以此時(shí)你配置的什么阻塞處理策略就沒什么用了
如果業(yè)務(wù)中需要保證定時(shí)任務(wù)同一時(shí)間只有一個(gè)能運(yùn)行，需要把任務(wù)路由到同一個(gè)執(zhí)行器上，比如路由策略就選擇第一個(gè)
當(dāng)任務(wù)處理完成之后，執(zhí)行器會(huì)將任務(wù)執(zhí)行的結(jié)果發(fā)送給調(diào)度中心
圖片
如上圖所示，這整個(gè)過程也是異步化的
到此，一次任務(wù)的就算真正處理完成了
最后我從官網(wǎng)撈了一張Xxl-Job架構(gòu)圖
圖片
奈何作者不更新吶，導(dǎo)致這個(gè)圖稍微有點(diǎn)老了，有點(diǎn)跟現(xiàn)有的架構(gòu)對(duì)不上
比如說圖中的自研RPC（xxl-rpc）部分已經(jīng)替換成了Http協(xié)議，這主要是擁抱生態(tài)，方便跨語言接入
但是不要緊，大體還是符合現(xiàn)在的整個(gè)的架構(gòu)
從架構(gòu)圖中也可以看出來，本文除了日志部分的內(nèi)容沒有提到，其它的整個(gè)核心邏輯基本上都講到了
而日志部分其實(shí)是個(gè)輔助的作用，讓你更方便查看任務(wù)的運(yùn)行情況，對(duì)任務(wù)的觸發(fā)邏輯是沒有影響的，所以就沒講了
所以從本文的講解再到官方架構(gòu)圖，你會(huì)發(fā)現(xiàn)整個(gè)Xxl-Job不論是使用還是實(shí)現(xiàn)都是比較簡(jiǎn)單的，非常的輕量級(jí)
本文鏈接：http://www.tebozhan.com/showinfo-26-35891-0.html8000字 + 25圖探秘Xxl-Job核心架構(gòu)原理
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 用戶注冊(cè)這樣玩，保你平安
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)