inshocking 个人介绍 + 技术输出
JavaJVM排障性能优化 · 2025年07月18日 · 2 分钟阅读 ·

系统批量对接放开最大限制

一、项目现状分析 项目 内容 生产环境 8G 单实例服务器，（cpu 可扩展） 当前处理限制 前端限制 Excel 最多 20 个产品，后端同步处理 处理逻辑 Controller 直接调用 batchCopyChann…

一、项目现状分析

项目 内容

生产环境 8G 单实例服务器，（cpu 可扩展）

当前处理限制 前端限制 Excel 最多 20 个产品，后端同步处理

处理逻辑 Controller 直接调用 batchCopyChannelProduct(List) 并行处理分支入数据库

痛点

20 条时耗时过长，可能超过前端 timeout 时间 (30s)

二、需求形成

831 批量产品替换，市场替换方案不明确无规划，需要支持灵活快速上架新产品

  • 支持 Excel 中大量产品上传，不再限制数量
  • 前端提交后不等待处理，返回 taskId
  • 能看到处理进度、失败原因
  • 处理完通知创建人进入下一步操作
  • 尽量将校验提前至填写阶段，若用户数据填写错误，需支持错误信息回显、修正重试

三、方案设计（PlantUML图示）

无需等待的接口处理流程

四、完整技术方案

【数据表】 async_task + async_task_error

CREATE TABLE async_task (
  task_id VARCHAR(64) PRIMARY KEY,
  user_id VARCHAR(64),
  status VARCHAR(20),
  progress INT,
  message TEXT,
  result_json TEXT,
  created_time DATETIME,
  updated_time DATETIME
);

CREATE TABLE async_task_error (
  task_id VARCHAR(64),
  row_index INT,
  sale_product_name VARCHAR(128),
  error_msg TEXT
);

【后端设计】

  • 新增 TaskService

  • create(taskId, userId)

  • updateProgress(taskId, percent)

  • complete(taskId, success|fail, result)

  • appendError(taskId, rowIndex, message)

  • Controller

  • 原 save() 改为 createTask()

  • 新增 queryProgress(taskId)

  • 异步执行 Executor

  • 调用原 batchCopyChannelProduct()

  • 每条 try-catch，错误写入 async_task_error

  • 成功失败分别记录，任务总体状态保持

【前端设计】

  • Excel 上传后显示 “任务已提交 taskId: xxx”
  • 提供 taskId 进度查看 UI（轮询 / 按钮）
  • 处理完成后显示“创建成功”+失败行导出（Excel）+继续操作

五、如果不改代码怎样评估最大处理能力？

方案：手动压测 + JVM 监控

  • 递增 Excel 产品数量：20/40/60/80/100

  • 观察故障：

  • 是否超过前端 timeout

  • CPU 是否 100%

  • GC 是否频繁（用 jstat -gc 查看）

  • 结论：

  • 大概未经优化情况下，（数量）产品之后超时风险极高

评论