旁邊的女乘客太吵，我實在忍無可忍，便對她說：“你能不能讓我睡會兒？”
她揮手就給了我一個耳光：“你個臭流氓！”
我頓時就清醒了，理論到：“你讓我睡一會怎麼了嗎”
她害羞的低下了頭，說道：“人家不是随便的人”
我：“我也不是随便的人，下一站我們下車把話說清楚”
相信大家對任務排程都不陌生，說的通熟一點就是定時任務；這個在我們的項目中或多或少都存在，我們可以用 JDK 自帶的（Timer、ScheduledExecutor）來實作，也可以用 Spring 的 Scheduler 來實作，不管用以上哪種方式，我們都是在單機上跑，如果我們以叢集的方式部署，會不會出現什麼問題 ？
叢集中的各個節點都會執行定時排程，會有重複執行的問題，那怎麼辦？ 我們可以加配置，隻啟動某個節點的定時任務，但是這時候又會出現單點問題
那有沒有什麼辦法，既能避免重複執行，又不會出現單點問題呢？ 分布式排程應運而生，常見的分布式任務排程架構有：quartz 、cronsun、Elastic-job、saturn、lts、TBSchedule、xxl-job 等
quartz 我已經簡單講過，有興趣的可以去看看：請點我，你們會發現：樓主壓根就沒講 quartz 的叢集模式。你們發現的很對，我就是沒講，就問你氣不氣 ？
既然你們對 quartz 已經有了一定的了解了 ，那麼它的叢集模式交給你們自己了
今天我們就一起來了解下另外一個分布式排程平台：xxl-job
關于 xxl-job 是什麼、有什麼特性、發展曆程、接入了哪些公司、各個版本的新特性等等問題，我都不會去講，因為官方文檔已經說的非常清楚了。xxl-job 是國産的，如果文檔還看不懂，那就需要回學校再造了。但是我還是想強調下它的架構圖
通過這個架構圖，我們可以對其有個大緻的了解；大體上分為排程中心 和 執行器，排程中心通過排程規則（cron表達式）對執行器中的任務進行排程，執行器收到排程後，執行具體的任務（Job）
既然官方文檔都說的非常細緻了，那我還能講什麼呢 ？ 好像确實麼什麼可以說的了， 那今天就到這吧，大家散會！
大家先别急着走，雖然下面的内容在官方文檔中已經存在，但是卻很容易被我們忽略；我會在搭建的過程中來穿插着一些問題，來鞏固我們容易忽略的點
我們先搭一個簡單的，排程中心 和 執行器 都先搭建成單節點
按照官方的文檔來，一步一步很容易搭建成功
源碼位址：xxl-job，可以 git clone 也可以 Download ZIP ，不管何種方式，我們拿到了源碼，導入到 IDEA，結構如下
SQL 腳本在源碼中已存在，路徑： xxl-job-master\doc\db\tables_xxl_job.sql ，執行此腳本，建立資料庫和表，如下圖
配置檔案： appliction.properties ，内容如下
View Code
需要改的地方不多，端口号可能需要根據實際情況進行修改，然後就是資料庫的位址、使用者名和密碼需要改成自己的，email伺服器最好配上（告警用的上），排程中心與執行器之間的安全通路 token（ xxl.job.accessToken ） 最好也配置上
出于示範，改下資料庫的配置就好，其他的保持預設；我們啟動排程中心，通路： http://localhost:8080/xxl-job-admin ，預設登入賬号 “admin/123456”, 登入後運作界面如下圖所示
“排程中心” 已經部署成功
配置檔案： application.properties ，内容如下
端口号配置一個未被使用的端口，排程中心位址配置成我們之前部署的排程中心的位址即可；至于 xxl.job.accessToken ，和排程中心配置成一樣即可
配置檔案中各個配置的注釋寫的非常清楚，大家根據實際情況進行配置即可
執行器的示例有好幾個，我們啟動 springboot 版本的；啟動不報錯就行了，它會自動注冊到排程中心，如下圖
排程中心通過排程規則對執行器中的任務進行排程，現在排程中心和執行器都部署好了，就缺排程規則和任務了
任務在示例代碼中已經存在了， SampleXxlJob.java ：
是一個任務集，裡面每一個被 @XxlJob 修飾的都是一個任務，我們以名為： demoJobHandler 的任務來做示範
任務已經定好，目前就隻差排程規則了，我們去排程中心管理界面進行配置；預設情況下，xxl-job 會幫我們自動配置好一個任務，如下
直接用它是可以的，但是為了清楚怎麼配置，我們重新配置一個
各個配置項的具體含義大家可以去看官方文檔，裡面都有詳細的介紹；
簡單點來說上圖的配置，就是每隔 3 秒，排程中心會去排程 示例執行器 的 demoJobHandler 任務
配置和部署都已完成，現在差的就是啟動排程了，我們啟動它
然後我們就可以在排程日志頁面檢視排程中心的排程日志了，如下所示
現在不管是排程中心，還是執行器，都是單節點的，都存在單節點問題
那如何解決了，單節點的解決方案往往就是叢集，我們可以将排程中心和執行器都部署成叢集，而 xxl-job 又是支援的，而且叢集部署非常簡單、友善
叢集架構圖簡單如下
nginx 隻是對排程中心的請求（排程中心管理頁面的操作）做負載均衡，它不涉及任務的排程與回調，這裡就不配置 nginx 了， 我們重點來看下排程中心叢集與執行器叢集的搭建
排程中心叢集的搭建非常簡單，隻需要注意兩點：DB配置保持一緻，叢集機器時鐘保持一緻（單機叢集忽視）
出于示範，我們就做單機叢集處理，那麼我們隻需要在 IDEA 中再啟動一個排程中心節點就好，端口号配置不一樣就好；排程中心共啟動兩個節點，之前的端口号是8080， 這個我們改成 8088
啟動之後，我們就可以從http://localhost:8080/xxl-job-admin，http://localhost:8088/xxl-job-admin 對排程中心控制台進行通路了，具體就不示範了， 大家可以自行去操作
生産環境下，會通過 nginx 對外暴露唯一位址，由 nginx 對這兩個（或者多個）進行負載均衡
搭建同樣非常簡單，隻需要注意兩點
1、執行器回調位址（xxl.job.admin.addresses）需要保持一緻；執行器根據該配置進行執行器自動注冊等操作。
2、同一個執行器叢集内AppName（xxl.job.executor.appname）需要保持一緻；排程中心根據該配置動态發現不同叢集的線上執行器清單
由于是單機叢集搭建，端口的唯一性也需要注意
啟動之後，去排程中心修改路由政策為輪訓，再啟動任務排程，然後就可以去檢視排程日志了
這個就不示範了，大家自行去測試，停掉某個節點，整個排程是否能正常完成
1、排程中心叢集部署，任務排程的時候，會不會每個節點都發起排程請求，進而産生重複排程的問題
這個問題在官方文檔中有說明：基于資料庫的叢集方案，資料庫選用Mysql；叢集分布式并發環境中進行定時任務排程時，會在各個節點會上報任務，存到資料庫中，執行時會從資料庫中取出觸發器來執行，如果觸發器的名稱和執行時間相同，則隻有一個節點去執行此任務。
是以對同一個排程，不會産生重複排程問題
2、執行器叢集收到排程請求後，會不會每個節點都去執行任務
這個問題不成立，我們不是配置了路由政策嗎，排程中心會根據路由政策将排程請求發送給具體的某個執行器了，那何來每個執行器都執行任務呢 ？
如果官方文檔看的細的話，我們會發現有如下一段話
不隻異步排程和異步執行，其實還包括異步回調，xxl-job 中用到了大量的隊列、異步處理
當然還有一些其他的疑問，絕大部分在官方文檔都能找到答案，是以需要大家多讀、細讀
1、單機模式，大家了解就好，生産環境肯定都是叢集模式的；但 xxl-job 的叢集部署也非常簡單
2、xxl-job 的全異步化&輕量級設計，可以保證使用有限的線程支撐大量的JOB并發運作
3、通篇都是在 xxl-job 的源碼上進行的，如何将它應用進我們的實戰項目中了 ？ 實戰篇，我們下期見
XXL-JOB