前段時間項目開發中用到了當當開源的elastic-job，使用過程遇到一些問題，雖然不見得會影響寫代碼，但作為一個致力於搬好每一塊磚的碼農，當碰到問題時，我們不應該逃避，應該本着有困難也要上，沒有困難創造困難也要上的精神沖上去搞定它，這樣才能更容易了解事情的本質，才能有利於以后搬好每一塊磚，佝僂者承蜩如是，我等搬磚亦復如是。
------------------------------------------------------------------------------------------------------------------------------------------------------------------
1、官方提到“同一台服務器只能運行一個相同作業實例，因為作業運行時是按照ip注冊和管理的”，那么：假如程序在同一台電腦上部署兩個作業實例，結果會如何，會進行正常分片么？
該問題測試結果為：分片參數以shardingItemParameters=0=A,1=B,2=C,3=D,4=E,5=F,6=G,7=H,8=I,9=J為例：
a：同一機器，運行兩個不同端口的tomcat--------不能分片，因tomcat端口未注冊到zk，程序無法識別這兩個tomcat，這兩個tomcat不會觸發分片，如果只部署一台機器，
兩個tomcat拿到的分片參數都是全部的分片參數0=A,1=B,2=C,3=D,4=E,5=F,6=G,7=H,8=I,9=J
b：同一機器，部署兩個docker(或者其它能提供ip的容器)，分別在其中用tomcat運行程序--------可以分片，兩個docker的不同的ip會被注冊到zk，從而觸發分片。
測試圖如下：
兩個鏡像：testdocker:v1根testdocker:v2
兩個docker中控制台日志截圖
對此問題，官方說明很清楚，作業是按照ip進行注冊和管理的，同一個ip只能運行一個相同name的作業。因為zk上區分不同的服務器就是靠ip來區分的，程序在zk上注冊的信息如下圖：
可以看到，zk中只有服務器ip，並無容器的端口之類信息，因此，，，，
2、運維界面中，【暫停】按鈕有何作用，因為官方說明中，運維程序只作監控，並不能操作任務的啟停，此處按鈕作用作何理解？（目前該部分說明已因改版而從官網刪除）
此處當時應為版本遺留問題，文檔未做更新導致，新版運維程序界面中有4個按鈕，比原來多了兩個，暫停、恢復等均為字面意思，不作解釋。該問題本地測試結果如下：
可以看到，藍色服務器在2016-07-23 15:19:50--15:20:09隔了19秒，這段時間只有白色服務器在運行。白色服務器並沒有受到藍色暫停的影響，分片參數仍按藍色正常進行計算。
在運維界面點擊【恢復】后，藍色服務器又開始運行。
此處注意，若暫停的為主節點服務器（主節點一欄為對號的），會暫停所有服務器的該任務，運維界面有提示文字說明該情況。
3、分片不均，服務器執行任務時間不等的情況下，是否會出現相互等待的情況？
測試結果為： A、B兩台服務器，都是5秒執行一次，A執行很快(認為是0s)B執行很慢(需要8秒)，A並不會等待B。驗證圖如下：
此問題，曾有小伙伴懷疑是否跟配置相關，並附代碼如下：
此處依據是否開啟monitorexecution，從而判斷是否等待其它服務器；但需要注意的是，這里是重新分片時候的操作，注釋中說的明白，如果要分片，且當前為主服務器，且開啟了monitorexecution，則等待，跟本小節討論的問題不是同一問題。因此，目前未發現與此問題相關的配置；當前版本是1.0.7。
4、失效轉移（failover）問題究竟怎么理解，對性能有何影響？
官網的解釋不多，此問題可以理解為：開啟失效轉移的情況下，如果任務執行過程中一台服務器失去連接，那么已經分配到該服務器的任務，將會在下次任務執行之前被當前集群中正常的服務器獲取分片並執行，執行結束后再進行下一次任務；未開啟失效轉移，那么服務器丟失后，程序將不作任務處理，任由其丟失，但下次任務會重新分片。
兩台機器(一個物理機，一個虛擬機)，10個分片，每1分鍾執行一次任務(每個任務sleep10s，模擬任務執行花費的時間)，執行過程中中斷虛擬機網絡，使其失去跟zk的連接，測試結果如下：
圖1：虛擬機日志截圖
圖2：物理機eclipse日志截圖
觀察兩圖，可以看到以下四個過程：
1、物理機先啟動並執行第一次任務，獲取全部分片；
2、然后虛擬機啟動，第二次任務執行時，兩台機器各分5個分片，該次任務兩台機器均正常執行；
3、第三次任務開始，兩台機器各獲取5分片，任務執行的10s內，虛擬機斷開跟物理機zk的連接：
這時候，斷開的虛擬機仍然正常執行自己已經獲得的分片任務，物理機開始階段也正常執行自己獲得的分片任務，但執行完畢后32s，又獲得了分片4=E，這時候可以看到時間並未
到達1分鍾，也就是並未達到下次任務開始時間；稍后又分多次獲取了本次分給虛擬機的其它分片，我們可以看到獲取到所有分片的時間已經超過了1分鍾；分片執行結束后，並未
等待，而是直接執行了下一次任務(原來都是1分鍾整點執行，這次是在22s執行)；
4、虛擬機丟失，物理機獲取所有分片信息，並且執行時間變成了從22s開始執行。
注意：該過程中，分片0-4對應的業務信息，實際被執行了兩次，可能會對業務數據產生影響。
failover對性能有影響有一個前提是開啟monitor-execution，這個監控是造成性能下降的關鍵。failover=true，monitor-execution=false的情況下，failover不會生效(本地測試結果如此，需要monitor-execution的支持)。
官方早起版本monitor-execution默認開啟，在我們當時用的1.07版本中，該屬性默認關閉。
對於該屬性，官方的觀點是短期執行的任務不建議開啟，會明顯影響性能。對於執行周期很長且業務需求的才建議開啟。若丟失的服務器，下次重新分片后，原來丟失的分片不影響業務，仍可以不開啟。
也就是說，開啟會造成性能問題；關閉，如果有服務器丟失：
1、跟zk斷開，跟其它沒斷開，本次任務仍然正常運行，不會對業務造成影響；
2、跟zk斷開，跟其它也斷開，本次任務出現異常（數據庫連接失敗等），會影響業務；需要程序處理異常或者事后人工處理；
3、跟zk沒斷，跟其它斷開，任務分片會正常過來，但任務執行異常，會影響業務，需要程序處理異常或者事后人工處理；
------------------------------------------------------------------------------------------------------------------------------------------------------------------
以上問題為實際開發過程中遇到的疑問，自己在本地測試的結果，難免有考慮不周的情況，有錯誤之處歡迎留言討論。
ps：今天看了下官網，發現官方已經推出elastic-job-cloud了！這是個什么東東？！看上去貌似很好很強大，稍后得看一下，努力追趕各路開源大神的腳步，，，，，