（Situation）背景
在系统中，我们支持批量处理产品对接与修改。随着业务发展，用户希望一次批量操作上百甚至上千个产品。但我们发现，在和流程引擎联动进行批量任务时，系统出现了数据库连接池耗尽、发布失败的问题，影响了用户体验并造成流程失败。
一、后台系统 与 流程引擎的系统交互梳理
1.1 系统关系概述
- flowable（流程引擎）：负责流程任务调度、任务变量传递、打包发布、同步执行控制。
- 后端系统（配置系统）：接收 流程 调用，实现渠道产品的配置、复制等逻辑。
1.2 实际调用关系梳理
1.3 调用模式确认
- ✅ 流程引擎 是串行调用 后台 接口的：每个产品单独发起一次调用，等待 IAC 响应后再处理下一个。
- ⚠️ 系统 内部存在并发处理问题：使用了 parallelStream / CompletableFuture 一次性并发处理全部产品，容易压垮连接池。
T（Task）任务目标
- 分析问题根源：找出为什么批量处理会失败。
- 设计优化方案：在不影响流程引擎调用逻辑的前提下，实现大规模产品对接的能力。
- 最终目标：支持上千产品的稳定对接，并提升系统性能与可维护性。
二、存在问题分析
问题点 描述 风险
❌ 系统并发处理产品 柳成荫串行调用 后端系统，但 后端系统 内部存在 并发处理多个产品的逻辑（如 parallelStream / CompletableFuture） 导致一个流程调用同时处理几十个产品，占满连接池，数据库连接池耗尽，接口阻塞
❌ 无事务优化 每个产品涉及 27 次数据库操作 无批处理，事务控制不统一
❌ 无任务状态跟踪 用户感知不到处理进度 可观测性差，无法失败重试
A（Action）采取的行动
三、整改优化（基于 流程引擎 串行调用）
3.1 后端系统 优化（重点）
✅ 代码层优化
- 移除 parallelStream / CompletableFuture 的全量并发处理
- 每次只处理当前这个产品，不在 IAC 内部并发多个产品
✅ 数据层优化
- 涉及 27 张表的读写 每个产品在 copy 时会操作多个表：渠道产品表、展示信息表、扩展配置表…..and so on
- 多表写入统一事务，避免碎片化连接调用
✅ 耗时监控
- 增加日志记录每个产品处理耗时，用于后续定位瓶颈
Q&A
Q1：为什么现在有连接耗尽问题？
后端 内部对 流程引擎 发起的单个调用，错误地并发处理了全部产品，导致连接池耗尽。
Q2：为什么不是 流程引擎 的问题？
后端系统 是串行执行，每个产品逐个调用 后端系统 并等待完成，没有并发行为。
Q3：那应该怎么改？
保证每次调用只处理一个产品，移除并发逻辑，提升单次处理性能，配合数据库批处理优化。
Q4：是否可以无上限处理？
理论上可以，串行处理只需保证单次产品处理性能足够，系统资源充足即可；但建议仍设上限以避免极端数据导致接口处理超时。如果一次批量修改产品过多，需等待时间稍长，但是一个产品 处理2-3s 也不慢了。
R（Result）成果效果
指标/结果 优化前 优化后
接口并发量 全部产品同时执行 每次只处理 1 个产品
数据库连接 耗尽/阻塞 连接池保持正常
流程打包耗时 超时/失败 稳定处理，串行打包每个产品
系统稳定性 存在雪崩风险 明显提升，任务顺利推进
经验成长
- 更清晰理解 调用链责任边界：流程引擎 负责流程调度，后端系统 专注单产品处理；
- 提升了对 连接池/事务/线程池资源消耗 的认知；
评论