架构师自诉：如何做到百万数据半小时跑批结束( 三 ) _数据

下游接口 hold 住么分享此条优化之前，先大致介绍一下我们的业务背景
保费代扣的跑批任务中，我们是会借助流程编排这个框架，去异步发起我们的代扣，你可以理解为一笔代扣申请就是一个异步线程，代扣的数据全部在流程编排中进行传递
在我们进行优化完毕的时候，准备在UAT环境进行优化测试的时候，发现仅20w条保费数据，处理时间就非常的不尽入人意
监控系统环境，发现系统频频在进行 GC，我的第一反应，不会是发生内存泄露了吧，在准备 dump 文件的时候
我意外的发现，大部分申请都是卡在了对外扣费的这个节点，经过日志观察，发现下游接口给的响应时间过久，甚至部分出现了超时情况
那么这个GC就合理了，由于我们的代扣申请生成的速度非常快，并且是异步的线程调度，线程还未死亡，一直在尝试对外请求扣费，就导致所有的数据都堆在内存里，就导致了频繁GC
在和下游接口方进行核实之后，的确针对于该接口没有进行限流处理（太坑了）
优化的思路也很简单了，在业务可接受的情况，我们采取的是去发送 mq 请求后，就挂起流程编排（该线程会死亡），然后让消费者进行处理调用成功后唤醒流程进行后续处理即可，当然使用固定的线程池直接调外也是可以的，目的都是防止过多的线程处于 RUNNING，从而导致内存一直的堆积
还有一种对外调用的万金油处理方式，就是在业务可接受的情况下，采取一种 fast success 方式，举个例子，在进行保费扣费的时候，我们调用支付公司的接口之前，直接将我们的扣费状态更改为扣费中，然后直接挂起我们的业务，然后用定时任务去查证我们的扣费结果，收到扣费结果后，在继续我们扣费后的操作
机器利用方面给我打满针对于生产上面的机器我们通常不会是单机部署，那么如何可以尽可能去压榨我们服务器的资源呢
那就是利用xxl-job的「分片广播」和「动态分片」功能

文章插图

执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；
“分片广播” 以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
“分片广播” 和普通任务开发流程一致，不同之处在于可以获取分片参数，获取分片参数进行分片业务处理。

// 可参考Sample示例执行器中的示例任务"ShardingJobHandler"了解试用 int shardIndex = XxlJobHelper.getShardIndex();int shardTotal = XxlJobHelper.getShardTotal();

具体举个例子，比如我们做分户日结的时候，可以根据商户的编号对机器进行取模处理，然后每台机器只执行某些特定商户的数据
那么这边留一个问题给大家：如果发生数据倾斜，你会如何处理，即某个商户的数据量特别大，导致这台机器执行的任务非常的重，要是你，你会如何处理这种场景？
总结今天针对于大数据量的跑批，在项目中实践思考就到此结束了。
文章介绍了我们常见跑批任务中可能出现的风险和比较常用通用的一些优化思路进行了分享
关于线程池和缓存的运用我未在文章中提及，这两点也对我们的高效跑批具有极大的帮助，小伙伴们可以加以利用
当然文章只是引起大家针对于跑批任务的思考，更多的优化还需结合任务具体情况和项目本身环境进行处理

【架构师自诉：如何做到百万数据半小时跑批结束】