1.elastic-job是什麼？

elastic-job是噹噹內部應用框架ddframe中dd-job的作業模組中分離出來的分散式彈性作業框架。

2. 什麼是作業排程（定時任務）?

作業即定時任務。一般來說，系統可使用訊息傳遞代替部分使用作業的場景。兩者確有相似之處。可互相替換的場景，如隊列表。將待處理的資料放入隊列表，然後使用頻率極短的定時任務拉取隊列表的資料並處理。這種情況使用訊息中介軟體的推送模式可更好的處理實時性資料。而且基於資料庫的訊息儲存吞吐量遠遠小於基於檔案的順序追加訊息儲存。

3. elastic-job整體架構圖

elastic-job的主要分為註冊中心、資料分片、分散式協調，定時任務處理和多作業模式等模組。

註冊中心模組目前直接使用Zookeeper，用於記錄作業的配置，伺服器資訊以及作業執行狀態。Zookeeper目前的znode分四類，config，servers，execution，leader。config用於儲存分散式作業的全域性控制，如，分多少片，要不要執行misfire，cron表示式。servers用於註冊作業伺服器狀態和分片資訊。execution以分片的維度儲存作業執行時狀態。leader用於儲存主節點。elastic-job作業執行是無中心化的，但主節點起到協調的作用，如：重分片、清理上次執行時資訊等。

如果Zookeeper掛了，是否全部的任務都掛了不能執行包括已經執行過一次的，如果又恢復了，任務能正常執行嗎，還是業務應用服務也要重新啟動？

其實Zookeeper是不太容易掛的。畢竟Zookeeper是分散式高可用，一般不會是單臺。目前elastic-job做到的容錯是，連不上Zookeeper的作業伺服器將立刻停止執行作業，防止主節點已重新分片，而腦裂的伺服器還在執行。也就是說，Zookeeper掛掉，所有作業都將停止。而作業伺服器一旦與Zookeeper恢復連線，作業也將恢復執行。所以Zookeeper掛掉不會影響資料，而Zookeeper恢復，作業會繼續跑，不用重啟。

失效轉移中如何判斷失效？對任務本身實現有什麼限制？

失效轉移目前通過Zookeeper監聽分片項臨時節點判斷。elastic-job會經過註冊中心會話過期時間才能感知任務掛掉。失效轉移有兩種形式：1、任務掛掉，elastic-job會找空閒的作業伺服器（可能是未分配任務的，也可能是完成執行本次任務執行的）執行。2、如果當時沒有空閒伺服器，則將在某伺服器完成分配的任務時抓取未分配的分片項。

資料分片是elastic-job中實現分散式的重要概念，將真實資料和邏輯分片對應，用於解耦作業框架和資料的關係。作業框架只負責將分片合理的分配給相關的作業伺服器，而作業伺服器需要根據所分配的分片匹配資料進行處理。伺服器分片目前都儲存在註冊中心中，各個伺服器根據自己的IP地址拉取分片。

分散式協調模組用於處理作業伺服器的動態擴容縮容。一旦叢集中有伺服器發生變化，分散式協調將自動監測並將變化結果通知給各個仍存活的作業伺服器。協調時將會涉及主節點選舉，重分片等操作。目前使用的Zookeeper的臨時節點和監聽器實現主動檢查和通知功能。

定時任務處理根據cron表示式定時觸發任務，目前有防止任務同時觸發，錯過任務重出發等功能。主要還是使用Quartz本身的定時排程功能，為了便於控制，每個任務都使用獨立的執行緒池。

多作業模式將定時任務分為多種流程，有不經任何修飾的簡單任務；有用於處理資料的fetchData/processData的資料流任務；以後還將增加訊息流任務，檔案任務，工作流任務等。

5. 除了elastic-job還有哪些是作業排程框架呢？

Quartz：

Java事實上的定時任務標準。但Quartz關注點在於定時任務而非資料，並無一套根據資料處理而定製化的流程。雖然Quartz可以基於資料庫實現作業的高可用，但缺少分散式並行執行作業的功能。

TBSchedule：

阿里早期開源的分散式任務排程系統。程式碼略陳舊，使用timer而非執行緒池執行任務排程。眾所周知，timer在處理異常狀況時是有缺陷的。而且TBSchedule作業型別較為單一，只能是獲取/處理資料一種模式。還有就是文件缺失比較嚴重。

Crontab：

Linux系統級的定時任務執行器。缺乏分散式和集中管理功能。

6. elastic-job有什麼功能和優點呢？

主要功能

分散式：重寫Quartz基於資料庫的分散式功能，改用Zookeeper實現註冊中心。

並行排程：採用任務分片方式實現。將一個任務拆分為n個獨立的任務項，由分散式的伺服器並行執行各自分配到的分片項。

彈性擴容縮容：將任務拆分為n個任務項後，各個伺服器分別執行各自分配到的任務項。一旦有新的伺服器加入叢集，或現有伺服器下線，elastic-job將在保留本次任務執行不變的情況下，下次任務開始前觸發任務重分片。

集中管理：採用基於Zookeeper的註冊中心，集中管理和協調分散式作業的狀態，分配和監聽。外部系統可直接根據Zookeeper的資料管理和監控elastic-job。定製化流程型任務：作業可分為簡單和資料流處理兩種模式，資料流又分為高吞吐處理模式和順序性處理模式，其中高吞吐處理模式可以開啟足夠多的執行緒快速的處理資料，而順序性處理模式將每個分片項分配到一個獨立執行緒，用於保證同一分片的順序性，這點類似於kafka的分割槽順序性。

其他功能

失效轉移：彈性擴容縮容在下次作業執行前重分片，但本次作業執行的過程中，下線的伺服器所分配的作業將不會重新被分配。失效轉移功能可以在本次作業執行中用空閒伺服器抓取孤兒作業分片執行。同樣失效轉移功能也會犧牲部分效能。

Spring名稱空間支援：elastic-job可以不依賴於spring直接執行，但是也提供了自定義的名稱空間方便與spring整合。

運維平臺：提供web控制檯用於管理作業。

非功能需求

穩定性：在伺服器無波動的情況下，並不會重新分片；即使伺服器有波動，下次分片的結果也會根據伺服器IP和作業名稱雜湊值算出穩定的分片順序，儘量不做大的變動。

高效能：同一伺服器的批量資料處理採用自動切割並多執行緒並行處理。

靈活性：所有在功能和效能之間的權衡，都可通過配置開啟/關閉。如：elastic-job會將作業執行狀態的必要資訊更新到註冊中心。如果作業執行頻度很高，會造成大量Zookeeper寫操作，而分散式Zookeeper同步資料可能引起網路風暴。因此為了考慮效能問題，可以犧牲一些功能，而換取效能的提升。

冪等性：elastic-job可犧牲部分效能用以保證同一分片項不會同時在兩個伺服器上執行。

容錯性：作業伺服器和Zookeeper斷開連線則立即停止作業執行，用於防止分片已經重新分配，而腦裂的伺服器仍在繼續執行，導致重複執行。