17370845950

事务失败不能盲目重试，需区分可重试（如死锁、超时）与不可重试错误（如主键冲突），结合事务边界、保存点、补偿机制和幂等设计构建可靠容错体系。

SQL事务失败时，不能只靠“重试”硬扛，关键得看失败原因、事务边界和数据一致性要求。盲目重试可能造成重复扣款、状态错乱或死锁加剧。

区分失败类型：哪些能重试，哪些必须终止

不是所有SQL错误都适合重试：

• 可重试错误：如数据库连接超时、死锁（Deadlock）、临时网络抖动、锁等待超时（Lock wait timeout）。这类问题短暂、外部、非业务逻辑错误，重试1–3次常能成功。
• 不可重试错误：如主键冲突（Duplicate entry）、外键约束失败、数据类型不匹配、空值插入非空字段、语法错误。这些是逻辑或数据问题，重试只会反复失败，需先修正输入或调整业务流程。

在应用层实现带策略的重试（以Java + Spring为例）

避免在SQL语句里写重试逻辑，应在服务层控制：

• 用@Transactional明确事务边界，确保整个业务操作原子性；
• 捕获特定异常（如DeadlockLoserDataAccessException），对死锁自动重试；
• 配合@Retryable（Spring Retry）设置最大重试次数、退避间隔（如指数退避）；
• 记录重试日志（含事务ID、重试次数、SQL摘要），便于排查是否因并发导致高频重试。

数据库侧辅助：用保存点（Savepoint）缩小回滚范围

长事务中部分步骤失败，不必全滚，可用SAVEPOINT精细控制：

BEGIN TRANSACTION;
INSERT INTO orders (...) VALUES (...); -- 步骤1
SAVEPOINT order_saved;
UPDATE inventory SET stock = stock - 1 WHERE id = 123; -- 步骤2，可能失败
-- 若此处报错，只回滚到 savepoint，保留订单插入
ROLLBACK TO SAVEPOINT order_saved;
-- 后续可补发通知、走补偿流程等
COMMIT;

注意：Savepoint不能跨事务，且不同数据库语法略有差异（MySQL/PostgreSQL支持良好，Oracle需用PL/SQL块）。

终极兜底：事务补偿 + 幂等设计

对无法简单重试的关键操作（如支付、发券），采用“正向执行 + 异步校对 + 补偿”模式：

• 写入业务表同时，落库一条事务快照（含操作类型、参数、状态为“处理中”）；
• 主流程失败后，触发定时任务扫描超时“处理中”记录；
• 通过幂等Key（如order_id + action_type）查最新状态，决定是重试还是发起逆向操作（如退款、回滚库存）；
• 所有对外接口必须校验幂等Token，防止补偿过程引发重复动作。

基本上就这些。重试不是银弹，它只是容错链条中的一环——前面要判错因，中间要控边界，后面要有兜底。设计时多问一句：“如果重试3次还失败，系统还能自愈吗？”