SQL任务重试记录机制_SQL保证最终一致方案

sql任务重试需通过唯一业务键查成功状态、事务内写入 processing 预置状态、乐观锁更新 success 终态、失败留痕并设超时兜底，确保幂等与数据一致。

SQL 任务重试时，若不记录状态或缺乏幂等控制，极易导致重复执行、数据错乱或丢失。核心思路是：用 数据库 自身事务能力 + 显式状态标记 + 幂等设计，让重试安全可控，最终达成一致。

重试前先查状态（基于唯一业务键）

每次任务触发前，先根据业务唯一标识（如 order_id、task_id、external_no）查询是否已存在成功记录。不是查“有没有执行过”，而是查“是否已成功完成”。成功标志建议是明确的状态字段（如 status = ‘success’）或带时间戳的完成记录。

• select 1 FROM task_log WHERE biz_key = ? AND status = ‘success’ LIMIT 1
• 查到结果 → 直接跳过，返回成功；没查到 → 继续执行
• 避免用 count(*) 或模糊条件，防止幻读或性能问题

执行中写入预置状态（事务内落库）

真正执行业务逻辑前，在同一数据库事务中插入或更新一条“待处理”记录（如 status = ‘processing’），并带上唯一 biz_key 和当前时间。这条记录既是锁，也是日志。

• INSERT INTO task_log (biz_key, status, created_at) VALUES (?, ‘processing’, NOW()) ON CONFLICT (biz_key) DO NOTHING
• PostgreSQL 可用 upsert；mysql 用 INSERT … ON DUPLICATE KEY UPDATE
• 失败回滚时，该记录也不会残留，保证状态干净

成功后原子更新为终态（含校验）

业务逻辑执行完毕且提交前，将对应记录更新为 success，并校验原状态是否仍为 processing（防 并发 覆盖）。可用 WHERE 子句做乐观锁式更新：

• UPDATE task_log SET status = ‘success’, updated_at = NOW() WHERE biz_key = ? AND status = ‘processing’
• 检查影响行数：若为 0，说明已被其他实例抢先完成，当前重试应终止
• 不依赖额外锁表或 SELECT for UPDATE，减少阻塞

异常时留痕并设超时兜底

执行失败需记录 error_msg、retry_count、next_retry_at（如 5 秒后），并限制最大重试次数（如 3 次）。对长时间卡在 processing 的记录，加定时任务扫描清理或告警：

• UPDATE task_log SET status = ‘failed’, error_msg = ?, retry_count = retry_count + 1 WHERE biz_key = ? AND status = ‘processing’
• 定时 SQL：SELECT * FROM task_log WHERE status = ‘processing’ AND updated_at
• 失败后可人工介入，或触发补偿流程（如发消息通知下游核对）

基本上就这些。不复杂但容易忽略的是：状态字段必须有索引，biz_key 必须唯一约束，所有写操作必须走事务。靠数据库保证原子性，比应用层加锁或外部协调器更轻量、更可靠。