elasticJob分片跑批
業務迅速發展帶來了跑批數據量的急劇增加。單機處理跑批數據已不能滿足需要，另考慮到企業處理數據的擴展能力，多機跑批勢在必行。多機跑批是指將跑批任務分發到多臺服務器上執行，多機跑批的前提是”數據分片”。elasticJob通過JobShardingStrategy支持分片跑批。
跑批配置需要做如下修改：
shardingTotalCount:作業分片總數。
jobShardingStrategyClass:作業分片策略實現類全路徑，elasticJob默認提供了如下三種分片策略，AverageAllocationJobShardingStrategy : 基於平均分配算法的分片策略。
RotateServerByNameJobShardingStrategy:根據作業名的哈希值對服務器列表進行輪轉的分片策略。
默認使用AverageAllocationJobShardingStrategy。
shardingItemParameters:分片序列號和個性化參數對照表。
分片序列號和參數用等號分隔, 多個鍵值對用逗號分隔。
分片序列號從0開始, 不可大於或等於作業分片總數。
分片的維度通常有狀態(state)、類型(accountType)、id分區等，需要按照業務合適選取。
以上例，跑批服務器起了兩臺，192.168.30.38(測試跑批服務器)和10.15.83.211(本地服務)。
作業分片總數為4，跑批服務器起了兩臺，根據AverageAllocationJobShardingStrategy ，每臺服務器分到的分片是: 1=[0,1], 2=[2,3]。這可以在Elastic Job Console上作業列表中可以看出。
本地服務器上也打印了shardingContext對象，以相互印證。
shardingContext:{"fetchDataCount":1,"jobName":"autoBidTransferLoanJob-1","jobParameter":"","monitorExecution":false,"offsets":{},"shardingItemParameters":{0:"NFM",1:"NFMF"},"shardingItems":[0,1],"shardingTotalCount":4} - 1
數據分片所需要做的，就是將shardingItemParameters作為參數傳入查詢跑批待處理數據列表的方法裏，sql查詢時增加一個動態in條件，例如：
And accountType in (‘NFM’, ‘NFMF’)- 1
分片方案
1、數據庫層面，對業務主鍵進行取模。
where mod(id, 4) in (1, 2)- 1
這種方式的問題是，在主鍵或者索引字段外套了一個函數，索引失效、全表掃描。改進方案是查詢條件中再增加一個索引字段。
where mod(id, 4) in (1, 2) and create_date > sysdate - 1- 1
2、數據庫層面，增加字段，在生成數據時，就為該行數據生成一個mod值。
做分片的初衷就是跑批數據量越來越大、單臺機器處理能力有限，通過擴展機器數來提升系統處理的能力。該mod值建議不要太小，至少要比分片項大。例如，生成的1000條數據的mod值只有0和1，而機器數加到了10，那最終只有兩臺機器在運行，造成資源浪費。當然，我們可以及時調整生成數據時的取模值，新生成的數據還是會分散到不同的機器上。
3、業務層面，選取狀態(state)、類型(accountType)等字段作為分區維度。
elasticJob分片跑批