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)等字段做为分区维度。