谈谈跑批系统容量控制

背景

在公司初搭建一套主要用于跑批的系统，系统主要在T+1根据日新增交易和存量交易状态跑出结果，每日数据10G，每日全量数据20G；

采用技术为spring batch partition进行分片处理，按3-10万每片处理，片线程数没做限制，系统运行前几个月无异常，在数据量达到5G以上后导致跑批性能下降并出现部分分片跑批失败。如下图：

原因分析

数据库

在跑批失败日志中有很大部分由于数据库ltocktimeout错误，分析由于并行任务过大导致读写数据库非常大，导致数据库拿锁失败。

公共变量操作

由于跑批过程中需要对部分公共变量进行读写操作，在读写过程也会出现加锁或操作失败。

任务并行

在跑批过程中有多个并行任务，导致数据库、io(达到290M/s)资源竞争很大，很多任务处理等待，操作冲突等情况。

解决

经分析跑批系统可分解成任务、step、partition执行chunk，如图：

出现资源竞争主要是发生在并行上，只要控制了并发就可以控制资源强占，上图有两个地方可以并行，多个job和多个partition；

这两个并行的数量需根据资源数量进行计算；如一个job执行单step使用单片处理所占用的cpu、内存、共享变量访问、数据库读写、io读写流量，在多job并分片处理下，所占资源就是以n*n的流量，需控制流量就得控制job和分片的partition数量；

为了更好控制和业务对处理时效性要求不高的特点，系统采用job池和partition处理池，如果池内满了就把任务等候状态，待处理池空闲时继续加入处理直至处理完成。如下图：