1、背景
最近公司在遷移定時任務，以前老的定時任務是基於quartz搭建的分布式集群服務，遇到如下幾個瓶頸問題：
- 同一個任務只能有一個節點運行，其他節點不執行，導致性能低，資源也浪費
- 定時任務在搶占執行的時候(數據庫鎖)，誰先搶到誰執行，導致有些節點忙死，有些節點一直閑置。（沒有合理的調度策略）
- 當碰到大量短任務時，各個節點頻繁的競爭數據庫鎖，節點越多這種情況越嚴重。性能會很低下
- quartz 的分布式僅解決了集群高可用的問題，並沒有解決任務分片的問題，不能實現水平擴展（水平擴展的問題，其實通過任務分布式鎖的形式也能解決）
反正，最終選定了xxl-job。
想着寫寫xxl-job遷移說明的，但是網上太多了，官方指導手冊也挺多的，還是算了。就記錄下遇到的問題+解決方法吧。
2、問題
經過一番coding、配置 之后，在xxl-job任務調度中心界面上，點擊【執行一次】，調度日志顯示失敗，錯誤信息是這樣子的
xxl-rpc remoting error(Unexpected end of file from server), for url : http://10.25.31.45:9999/run
這個ip是我本機的，執行器注冊啥的都沒問題。
先說解決辦法
2.1、解決辦法
確認下netty的版本是否是4.1.48.Final。
Netty3、netty4可以共存，
但是每個只依賴一個主版本即可，netty4要4.1.48+
檢查下pom.xml，果然有貓膩
正常情況下，xxl-job-core 依賴的netty版本是 4.1.48.Final，在我這里變成了4.0.35~
看了下xxl-job.pom文件里面是使用的 ${netty-all.version} 屬性，這說明我的項目里面有別的地方也定義了這個值，覆蓋了xxl-job的4.1.48
在項目的pom文件里面定義netty-all.version 為 4.1.48.Final 就搞定了。
2.2、原因
mavan在處理依賴的時候，有如下兩個原則：
- 最短路徑優先
- 相同路徑下配置在前面的優先
那另外一個問題，你咋知道就是netty的問題呢？
（先賣個關子，后面再讀讀xxl-job的源碼）