elastic-job詳解（四）：失效轉移

elastic-job中最關鍵的特性之一就是失效轉移。配置了失效轉移以後，若是在任務執行過程當中有一個執行實例掛了，那麼以前被分配到這個實例的任務（或者分片）會在下次任務執行以前被從新分配到其餘正常節點實例上執行。

簡單的HA

當某一個任務實例節點宕機（離開與zookeeper的鏈接），會觸發elastic-job主節點的從新分片邏輯。elastic-job啓動任務節點之後生成的zookeeper中的instance節點是一個臨時節點EPHEMERAL。爲何要用EPHEMERAL節點，就是爲了能在任務實例出現問題與zookeeper斷開之後，能觸發zookeeper的節點移除的事件，從而從新調整分區或者運行節點。既然是EPHEMERAL節點，就能夠在zookeeper中配置sessionTimeoutMs參數。在使用spring的elastic-job配置中在以下地方配置：

若是在sessionTimeoutMs的時間段以內觸發任務，則異常分片的任務會丟失。舉個例子：假如sessionTimeoutMs被設置成1分鐘，而自己的任務是30秒執行一次，有三個任務實例在三臺機器各自執行分片1,2,3。當分片3所在的機器出現問題，和zk斷開了，那麼zk節點失效至少要到1分鐘之後。期間30秒執行一次的任務分片3，至少會少執行一次。1分鐘事後，zk節點失效，觸發ListenServersChangedJobListener類的dataChanged方法，在這裏方法中判斷instance節點變化，而後經過方法shardingService.setReshardingFlag設置從新分片標誌位，下次執行任務的時候，leader節點從新分配分片，分片3就會轉移到其餘好的機器上。

 

複雜的失效轉移

elastic-job的任務配置有個failover，若是開啓設置爲true的時候，會啓動真正的失效轉移：，elastic-job的任務又兩個配置failover（默認值爲false）和monitorExecution（默認值是true）。只有對monitorExecution爲true的狀況下才能夠開啓失效轉移。

所謂失效轉移，就是在執行任務的過程當中碰見異常的狀況，這個分片任務能夠在其餘節點再次執行。這個和上面的HA不一樣，對於HA，上面若是任務終止，那麼不會在其餘任務實例上再次從新執行。

Job的失效轉移監聽來源於FailoverListenerManager中JobCrashedJobListener的dataChanged方法。FailoverListenerManager監聽的是zk的instance節點刪除事件。若是任務配置了failover等於true，其中某個instance與zk失去聯繫或被刪除，而且失效的節點又不是自己，就會觸發失效轉移邏輯。

首先，在某個任務實例失效時，elastic-job會在leader節點下面建立failover節點以及items節點。items節點下會有失效任務實例的本來應該作的分片好。好比，失效的任務實例原來負責分片1和2。那麼items節點下就會有名字叫1的子節點，就表明分片1須要轉移到其餘節點上去運行。以下圖：

而後，因爲每一個存活着的任務實例都會收到zk節點丟失的事件，哪一個分片失效也已經在leader節點的failover子節點下。因此這些或者的任務實例就會爭搶這個分片任務來執行。爲了保證不重複執行，elastic-job使用了curator的LeaderLatch類來進行選舉執行。在得到執行權後，就會在sharding節點的分片上添加failover節點，並寫上任務實例，表示這個故障任務遷移到某一個任務實例上去完成。以下圖中的sharding節點上的分片1：

執行完成後，會把相應的節點和數據刪除，避免下一次重複執行。