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

分片方案

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