1背景
分布式批量系统指的是采用分布式数据库架构，主体功能由批量程序实现的系统。分布式系统批量程序的性能测试，除了和联机交易性能测试一样关注服务器资源使用率是否合理、是否存在性能异常外，在测试执行阶段需要关注是否因数据分布不均衡导致部分并发子程序执行时间过长，成为整体批量程序的“短板”，从而影响批量程序的整体时间。
下面我主要介绍一种分布式系统批量程序性能优化的思路，并结合实际测试效果说明。
2分布式系统分片和批量并发规则
被测系统数据库为分布式数据库，存储并处理某公司各个机构的业务数据，包括若干个数据库分片、500多个分片键（分布式表的一个主键字段，用来区分数据存放的分片），分片键值是由机构ID号（以下简称机构号）按照一定规则映射而来。每个分片包含若干分片键，某个分片键对应若干机构的数据。
批量程序执行时，根据系统相关配置表中的静态配置，500多个子程序并发分别处理对应分片键下的业务数据。各个子程序处理逻辑相同，所以当某些子程序待处理的数据量相对其他子程序过多时（即该分片键下机构数据明显多于其他分片键下数据），这些耗时长的子程序会拖慢整体程序的效率。
图1分片与分片键对应关系
3抢任务方式优化数据分布不均衡的批量程序
3.1由静态并发改造抢任务模式
根据系统按分片键静态并发的特点，当批量程序子程序间处理数据分布不均衡时，部分子程序执行时间过长，成为整体批量程序的“短板”，从而影响批量的整体时间。为解决上述问题，本系统采取了“抢任务”的动态并发优化方法。
图2抢任务改造前后批量程序逻辑对比
1）将待处理表中的所有数据，按照一定的维度（如机构号+该表的某个参数值）划分成若干个任务，单个任务就是某个机构下某参数值对应的数据。
2）在实际处理数据程序执行之前，添加一个生成任务程序，执行该程序就会在任务表中添加全部任务的记录，所有任务当前处于初始化状态。
3）生成任务程序执行后，自动调起数据处理程序，改造后的程序不再按照静态并发，而是去查询任务表中状态为初始化且数据量大（优先级高）的任务，任务结束时，处理状态改为已完成，子程序查找下一个未处理的任务，直到任务表没有状态为初始化的任务，所有子程序成功执行完成。
实际测试场景执行时采用1600万条数据对某批量程序（该程序处理的业务数据，各个分片键下的数据极不均衡，经分析适用于本优化方法）进行测试数据准备，按照优先级处理任务300个子程序动态并发执行，按当前维度共生成11万个任务，所有子程序均在33分钟内完成，无明显过长的子程序，总体执行时间32分21秒，系统资源和数据库资源利用率均正常。
3.2优化任务处理数据量
按前述优化的生成任务维度，有个别任务处理数据量仍然很大，如果不进行进一步拆分还是存在一定“短板”，且生成的任务过多，大量任务都是小数据量任务，处理数据程序频繁抢“小任务”并更新数据的效率较低。为解决上述问题，程序进行了第二次优化。
1）生成任务时增加限制任务处理数据量的参数，该参数作用是规定单个任务的最大数据处理数，当同一分片键维度的任务处理数据量未达到这个值时，将这几个任务合并为一个更大的任务，如果分片键发生了切换，则生成下一个任务。
2）对于原有维度拆分出来的大任务，通过增加维度的字段，使单个维度的处理数据量降低，这样一个维度包含的数据更小，同时也参照上述参数限定任务最大数据处理数。
上述优化主要目标即控制个别“大任务”的处理数据量，合并多数“小任务”，使任务总量变少，减少抢任务造成的时间成本，并且任务之间处理数据量更均衡。
按上述策略优化的生成任务程序和数据处理程序，并发数不变，仍然采用同样数据进行准备并执行测试，由于生成任务的规则变化，生成的任务量由原来的10万以上降低到1000以内，生成任务时间增为2分40秒，执行数据处理程序时间降低为12分33秒，生成任务和处理数据的总执行时间比第一次优化明显提升。下表是两次优化执行性能测试执行时间对比。
该批量程序按上述策略两次优化后，生产环境中处理时间由优化前的近4小时缩短到15分钟左右，时间减少90%以上，且系统资源运行平稳，无性能瓶颈。
4总结及展望
通过分布式系统的性能测试实践，我们根据系统特点在批量程序性能优化方面积累了一定经验。抢任务性能优化方式解决了批量程序不同分片键处理数据量不均衡导致的执行时间过长问题，在项目测试中取得了明显的优化效果。
未来我还将持续探索分布式系统的批量测试技术和测试方法，加强系统分析与调优能力，为提升分布式批量系统效率及可靠性继续努力。
文末了：
可以到我的个人号：atstudy-js，可以免费领取一份10G软件测试工程师面试宝典文档资料。同时我邀请你进入我们的软件测试学习交流平台，大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，了解测试行业的最新趋势，助你快速进阶Python自动化测试/测试开发，稳住当前职位同时走向高薪之路。
