elasticJob分片跑批

業務迅速發展帶來了跑批數據量的急劇增長。單機處理跑批數據已不能知足須要，另考慮到企業處理數據的擴展能力，多機跑批勢在必行。多機跑批是指將跑批任務分發到多臺服務器上執行，多機跑批的前提是」數據分片」。elasticJob經過JobShardingStrategy支持分片跑批。

跑批配置須要作以下修改： 

shardingTotalCount:做業分片總數。

jobShardingStrategyClass:做業分片策略實現類全路徑，elasticJob默認提供了以下三種分片策略，AverageAllocationJobShardingStrategy : 基於平均分配算法的分片策略。 
OdevitySortByNameJobShardingStrategy:根據做業名的哈希值奇偶數決定IP升降序算法的分片策略。 
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

分片方案

一、數據庫層面，對業務主鍵進行取模。

where mod(id, 4) in (1, 2)

• 1

這種方式的問題是，在主鍵或者索引字段外套了一個函數，索引失效、全表掃描。改進方案是查詢條件中再增長一個索引字段。

where mod(id, 4) in (1, 2) and create_date > sysdate - 1

• 1

二、數據庫層面，增長字段，在生成數據時，就爲該行數據生成一個mod值。 
作分片的初衷就是跑批數據量愈來愈大、單臺機器處理能力有限，經過擴展機器數來提高系統處理的能力。該mod值建議不要過小，至少要比分片項大。例如，生成的1000條數據的mod值只有0和1，而機器數加到了10，那最終只有兩臺機器在運行，形成資源浪費。固然，咱們能夠及時調整生成數據時的取模值，新生成的數據仍是會分散到不一樣的機器上。

三、業務層面，選取狀態(state)、類型(accountType)等字段做爲分區維度。