elasticJob分片跑批

业务迅速发展带来了跑批数据量的急剧增加。单机处理跑批数据已不能满足需要,另考虑到企业处理数据的扩展能力,多机跑批势在必行。多机跑批是指将跑批任务分发到多台服务器上执行,多机跑批的前提是”数据分片”。elasticJob通过JobShardingStrategy支持分片跑批。

跑批配置需要做如下修改:
elasticJob分片跑批

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上作业列表中可以看出。
elasticJob分片跑批

本地服务器上也打印了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

elasticJob分片跑批

分片方案

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

上一篇:c# 求两个数中最大的值


下一篇:【Deep Learning】Hinton. Reducing the Dimensionality of Data with Neural Networks Reading Note