Go database/sql事务提交失败后的重试边界设计

Go 的 database/sql 事务提交失败后，不能简单地把原来的 Tx.Commit() 再调用一次。正确边界是：先丢弃旧事务，再判断错误是否允许“整笔业务事务”重试；如果数据库结果已经无法确认，就用业务幂等键查询，而不是盲目补写。

先把 Commit 失败分成三类

官方 database/sql 文档要求事务以 Commit 或 Rollback 结束；提交失败时，事务中的查询结果和更新结果都应丢弃。工程上还要继续问一句：数据库到底有没有接受这次提交？

第一类是上下文取消。BeginTx 使用的 Context 被取消时，包会尝试回滚，Commit 也会返回错误。这类错误通常先返回超时或取消，不要因为客户端已经放弃就立即补写。

第二类是驱动明确标记的瞬时错误，例如连接短暂断开、数据库明确返回可重试的序列化冲突。第三类是结果不确定：网络在提交确认前断开，应用只知道调用失败，却不知道服务端是否已经落盘。database/sql 不会替你把这三类统一分类，必须使用具体驱动的错误类型和业务约束。

重试放在整笔事务外层

重试函数应该包住 BeginTx、所有 ExecContext 和最后的 Commit。一次失败后，旧事务只做收尾，不再承载第二次写入；下一次尝试必须获得新的 Tx。

// runTx 只重试完整事务，避免在同一个 Tx 上重复提交。
func runTx(ctx context.Context, db *sql.DB, requestID string) error {
	const maxAttempts = 3 // 限制重试次数，避免故障时放大流量
	for attempt := 1; attempt 

retryableCommitError 不能只按字符串匹配。它应识别驱动暴露的、确实可重试的错误，并排除唯一键冲突、权限失败、语句错误和上下文取消。若驱动没有可靠分类，就把提交失败当作未知状态处理。

业务写入还应让 request_id 有唯一约束。重试再次执行插入时，可以得到“已存在”并转为查询确认；更新语句则应带上这个业务键或版本条件，避免把另一笔请求误更新。

提交未知时先查状态，再决定补偿

当网络断在 Commit 返回之前，最稳妥的流程是把请求标记为“待确认”，用同一个 request_id 查询幂等记录和业务表。如果记录已经存在，说明业务结果可被确认；如果没有记录，也只能在驱动和数据库都能证明未提交时才重试，否则应进入人工或后台补偿队列。

日志至少保留 request_id、attempt、错误分类、数据库驱动、超时原因和最终状态。不要只记录“commit failed”，否则后续无法判断是客户端取消、瞬时冲突还是确认链路丢失。

上线前的最小验证清单

• 让数据库返回一次明确的序列化冲突，确认只新建事务且最多重试三次。
• 在提交确认前断开连接，确认系统进入待确认而不是直接插入第二条记录。
• 验证唯一约束、幂等查询和超时取消都能留下相同的 request_id。

常见问题

Commit 返回错误后还能 Rollback 吗？

可以把回滚作为收尾尝试，但不要把它当成已成功撤销的证明；提交结果不确定时仍应查询业务状态。

为什么不只重试 Commit？

事务已经结束或不可用，重复调用既不能修复连接状态，也无法覆盖驱动已经丢失的确认信息。应重新开始整笔事务，并用幂等键防重复。

重试次数越多越安全吗？

不是。次数越多越可能放大数据库压力；通常应设置小上限、退避，并把无法分类的错误交给确认或补偿流程。