Spring Batch处理4000万条记录的性能优化最佳方案咨询

现有方案问题根因 #

• 基于Partitioner的分区方案：处理阶段4000个并行REST调用的配置本身没问题，但写入阶段没有做流量管控，所有处理线程同时争抢数据库连接，连接池被打满后大量请求排队等待，最终触发连接超时。本质问题是读、API处理、写入三个阶段的并行度完全不匹配，处理侧的高并发直接压垮了写入侧的承载上限。
• 异步处理器+异步写入器方案：你调错核心参数了，throttle.limit只是框架层的任务限流阈值，不控制实际工作线程数。默认异步批处理组件的工作线程数和CPU核心数绑定，常规8核机器默认只会启动8~16个工作线程，就算把节流阈值拉满，实际同时发起的REST调用也只有十几个，当然耗时过长。

可落地实现方案（分阶段管控+背压流水线） #

核心思路是不要把三个阶段的并行度完全解耦，不要等单批次所有数据全处理完再写入，通过缓冲队列做流水线流转，每个阶段的资源配置匹配自身承载上限：

1. 前置资源配置 #

• 数据库连接池：目标库写入连接数不要盲目调大，常规OLTP数据库单实例最佳连接数区间为CPU核心数*2 + 磁盘有效线程数，一般设置16~32就足够，超过这个阈值只会增加上下文切换和锁争抢，反而降低写入性能。
• REST调用客户端：不要用JDK默认的同步客户端或者无限制的线程池，选用异步HTTP客户端（OkHttp、Apache AsyncHttpClient均可），配置全局最大连接数4000、单目标路由最大连接数4000，连接超时、读超时按接口SLA设置为3s~10s，同时配置最多2次重试（仅重试超时、5xx类服务端错误）。
• 批处理线程池：不要用框架默认的线程池，手动声明独立线程池，核心线程数设为4000，等待队列用SynchronousQueue（长度为0，不堆积任务），拒绝策略设为CallerRunsPolicy，避免任务无限制堆积打满内存。

2. 单批次执行逻辑 #

每批从源库读取4000条记录后，不要等所有API调用完成再启动写入，按流水线逻辑执行：

• 第一步：把4000条记录全部提交到自定义线程池发起REST调用，每个调用完成后，把加工好的结果直接放入容量为1000的阻塞队列（作为API处理和写入阶段的缓冲）。
• 第二步：启动独立的写入工作线程组（线程数量和数据库连接数一致，比如16个），循环从阻塞队列拉取处理完成的结果，攒够500条就执行一次JDBC批量写入，写完直接提交事务，不需要等4000条记录全部处理完。
• 第三步：监控当前批次的写入完成数，等4000条记录全部写入目标库后，记录当前批次的偏移量，再启动下一批次的读取，避免宕机导致数据重复处理或者丢失。

注意：处理和写入是完全并行的，API返回一部分结果就写入一部分，既不会让数据库连接被瞬时高并发打满，也不会让处理结果在内存中大量堆积触发OOM。

3. 容错配置 #

• REST调用失败的记录直接写入独立的失败记录表，标记失败原因，后续单独做补处理，不要阻塞整批流程。
• 写入失败的记录块最多重试3次，依然失败就记录当前偏移量，中断当前批次，不要卡死整个任务。
• 每处理完10个批次打印一次监控指标：当前处理速率、剩余待处理记录数、累计失败数，方便排查性能瓶颈。

4. 预期性能参考 #

如果REST接口平均响应时间在200ms左右，单批次4000条的处理耗时可以控制在10s以内；写入侧用批量插入的话，16_{32个数据库连接足够支撑每秒2万}3万条的写入速率，4000万全量数据跑完大概需要4~6小时，不会出现连接超时或者并发度不足的问题。

内容的提问来源于stack exchange，提问作者ssss