跑批设计-如何才能让跑批更加高速

article/2025/10/16 5:28:07

跑批的应用场景

在开发过程中跑批经常使用的地方：

消息类：到期失效以及到期批量通知客户
计算类：在财务中的罚息、计提、计息
文件类：对账信息、还款信息同步以及报表生成

跑批数据特点

数据量非常大
实时性并不是特别高，有比较宽裕的时间处理问题
性能要求并不是特别高，要求在

跑批中的隐患

数据量非常大，有时会全部读写到内存开销较大

批量循环更新数据库

一整个事务贯穿始终

多个节点操作时，设计的缺点导致只会命中一个节点操作数据，导致其他节点资源浪费

优化思考

数据量比较大的思路：

1.数据分片处理：最简单实用的方法是实用分页limit

limit在分页的情况下，注意如果数据量非常大的情况差limit效率非常低

limit 的偏移量越大，执行时间越长。limit a, b会查询前a+b条数据，然后丢弃前a条数据，select * 会查询所有的列，会有回表操作，其中a条回表操作时无效的

针对上面的问题，我们需要的操作时尽量减少无效的回表策略，limit a,b,直接获取a+1到a+b条数据的id，再根据这些id查询数据这样就减少了回表的操

另一种有缺陷的搜索：

当然还有一种有缺陷的方法是基于排序做条件过滤。

比如像上面的示例 user 表，我要使用 limit 分页得到1000001到1000010条数据，可以这样写 SQL：

select * from user where sex = 1 and id > (select id from user where sex = 1 limit 1000000, 1) limit 10;

这种操作需要id必须有序，如果无序这种操作将没有任何意义，适用面比较小

2.分片数据的高效实用

单机：利用线程池执行不同的分片数据

集群：将数据分布到不同的节点处理数据

1.基于xxl-job路由策略，分片路由策略，可以实现不同的分片数据分不到不同的节点执行，xxl-job基于的是静态分片

@Component
public class Demo2Handler {@XxlJob(value = "demo3Job")public ReturnT<String> demo3JobHandler(String param) throws Exception{// 分片参数ShardingUtil.ShardingVO shardingVO = ShardingUtil.getShardingVo();// 业务逻辑for (int i = 0; i < shardingVO.getTotal(); i++) {if (i == shardingVO.getIndex()) {System.out.println("demo3");XxlJobLogger.log("第 {} 片, 命中分片开始处理", i);} else {XxlJobLogger.log("第 {} 片, 忽略", i);}}return ReturnT.SUCCESS;}
}

2.SchedulerX 2.0与PowerJob基于MapReduce动态分片,PowerJob以及Schedulerx2.0分布式计算原理&最佳实践

数据批量更新操作

尽可能将所有的结果汇总进行批量的更新或者插入的操作

insert into table_name(column1,column2,column3) values ('column11','column12','column13'),('column21','column22','column23')···update table_name set column_name = 'column1'  where column_name2 = 'column2';update table_name set column_name = 'column3' where column_name2 = 'column4';···