Java容错批量重试核心是分离成败项、仅重试失败子集、防重复执行、指数退避控节奏、保留上下文；须按记录粒度标记状态，隔离失败项异步重试，依托唯一约束/业务ID保障幂等，并通过死信表、日志、监控实现可观测与人工干预。
Java 中实现健壮的容错批量重试机制，核心在于：**分离成功与失败项、按需重试失败子集、避免重复执行、控制重试节奏、保留原始上下文**。不能简单用 try-catch 包裹整个 batchUpdate 就完事——那只是“兜底”，不是“容错”。
1. 按记录粒度拆分并标记执行状态
Spring JDBC 的 batchUpdate 或 MyBatis 的 foreach 批量插入本身不返回每条记录的成败详情。必须改用可感知单条结果的方式：
- 用
JdbcTemplate.batchUpdate(String sql, BatchPreparedStatementSetter)+ 自定义BatchPreparedStatementSetter，并在其setValues(PreparedStatement ps, int i)中记录每条数据索引与原始对象映射 - 配合
updateCount数组（int[]返回值）判断每条是否成功（注意：某些数据库驱动对批量更新的updateCount支持不一致，如 MySQL 默认关闭，需加参数allowMultiQueries=true&useServerPrepStmts=false） - 封装执行结果为
List<batchresult>></batchresult>，其中BatchResult包含：originalData（原始对象）、success（布尔）、error（异常或 SQLState）、retryCount
2. 失败项隔离 + 指数退避重试
重试不是把整个批次再跑一遍，而是只重试失败的子集，并防止雪崩：
- 提取所有
success == false的记录，组成新批次；若为空则直接结束 - 重试前 sleep：使用指数退避（如
Thread.sleep((long) Math.pow(2, retryCount) * 100)），上限建议 2–5 秒 - 限制最大重试次数（通常 3 次足够），第 N 次失败后不再重试，转为落库到「死信表」或发告警
- 避免线程阻塞：高并发场景下建议用
ScheduledExecutorService异步调度重试任务，而非同步 sleep
3. 幂等性保障是容错前提
重试必然带来重复执行风险，必须从设计上杜绝重复写入：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 业务主键或唯一约束：在数据库表中为关键字段（如订单号+操作类型）建唯一索引，让重复插入直接报
SQLState = 23505（PostgreSQL）或ER_DUP_ENTRY（MySQL），便于识别幂等失败 - 乐观锁/版本号：更新类操作带上
version字段，失败即说明已被其他流程修改，不应盲目重试 - 状态机校验：插入前查库确认当前状态是否允许该操作（如“订单只能从「待支付」转为「已支付」”，不可重复提交）
- 不依赖自增 ID 做幂等：应使用业务 ID（如 UUID、Snowflake ID）作为主键或唯一标识
4. 可观测性与人工干预入口
健壮 ≠ 黑盒，要让失败可追溯、可干预：
- 每次重试前记录日志：包含批次 ID、失败数量、失败原因摘要、重试序号、下次预计执行时间
- 将最终失败项持久化到独立表（如
batch_retry_dead_letter），字段包括：batch_id、data_json、error_stack、create_time、last_retry_time、retry_count - 提供管理接口：支持按 batch_id 查询重试历史、手动触发某条死信重试、标记为忽略
- 对接监控：失败率突增、重试超时等指标上报 Prometheus，触发企业微信/钉钉告警
不复杂但容易忽略——真正的容错不在“多试几次”，而在“知道哪几次该试、为什么试、试完怎么收场”。
