Go Badger 事务提交报冲突时应该怎样重新执行

Go Badger 事务提交时报 badger.ErrConflict 时，不要再次调用原来的 Txn.Commit()。正确做法是把完整的读写闭包放进有限次重试循环，每次重试都重新创建事务，让读取和写入基于新的快照执行；达到上限仍失败，再把冲突交给上层处理。

Badger 的冲突是并发事务之间的读写竞争，不等于数据库损坏。可重试的只是明确的 ErrConflict，业务校验失败、事务过大和数据库关闭都应该直接返回。

• 提交失败后不要复用旧 Txn，因为提交路径会丢弃它。
• 重试闭包必须重新读取参与计算的键，不能拿第一次的旧值继续写。
• 只做有限次数重试，并记录冲突次数、热点键和最终失败原因。

先判断 Badger 冲突发生在哪里

Badger 官方文档说明，DB.Update 会创建并管理一个读写事务；闭包返回的错误会被继续返回，闭包成功后才进入提交。事务提交时，如果此前读取的键已经被其他事务更新，Badger 返回 ErrConflict。因此冲突可能出现在闭包已经执行成功之后，调用方不能只检查 Set 是否返回 nil。

下面这段分类逻辑适合放在重试入口。ErrConflict 可以重试；数据格式、权限、业务状态等错误需要让调用方修正，ErrTxnTooBig 则应该拆小本次写入。

func retryableBadgerError(err error) bool {
	// 只把并发提交冲突视为瞬时错误，避免吞掉业务失败。
	return errors.Is(err, badger.ErrConflict)
}

每次重试都创建一笔新事务

最稳妥的写法是直接使用 db.Update，把“读取旧值、计算新值、写回新值”全部放进闭包。外层循环只负责判断提交结果。这样第 2 次尝试会重新读取最新版本，而不是沿用第 1 次尝试的 Item、计数器或已经失败的 Txn。

package main

import (
	"errors"
	"fmt"
	"time"

	"github.com/dgraph-io/badger/v4"
)

func updateWithRetry(db *badger.DB, key, delta []byte) error {
	const maxAttempts = 4

	for attempt := 1; attempt 

示例中的 append 仅用于演示“读取后计算再写回”的事务边界；真实业务应把增量合并写成幂等操作，避免调用方重试时产生重复副作用。若值不存在，业务还要明确初始化规则，而不是把所有缺失都当成空字节串。

退避次数、热点键和事务大小怎么定

重试次数不应无限增长。4 次只是一个可观察的起点：低延迟接口可以使用更短的退避，后台任务可以略微放宽上限，但都应该把最终失败返回给队列或上层。不要用固定大睡眠掩盖热点；如果同一组键持续冲突，应检查是否把多个无关对象放进同一事务，或是否需要按业务键分片。

还要区分 ErrTxnTooBig。Badger 官方 quickstart 建议遇到事务过大时提交已积累的部分写入，再开始新事务；这不是用重试同一事务能解决的问题。对大量写入，应按批次拆分，并把每批的边界记录清楚。

CommitWith 的持久化边界不能误判

如果使用 Txn.CommitWith，提交方法在完成冲突检查后可能立即返回，真正写入在后台进行，回调收到 nil 才表示写入完成。需要把“已通过冲突检查”和“已经持久化”区分开：依赖写入完成的后续动作应放在成功回调中，并在回调中记录最终错误。

普通的 DB.Update 更适合本文的有限重试场景，因为闭包和提交结果都在一次调用中返回。无论使用哪种方式，都应为每次尝试记录 attempt、key 分片或业务请求号，并确保最终错误可以被监控系统识别。

常见问题

ErrConflict 能不能直接再次调用旧事务的 Commit？

不建议。提交流程会丢弃事务，应该重新调用 DB.Update 或 NewTransaction(true) 创建新事务。

为什么闭包里的 Set 成功，Update 仍然返回冲突？

Set 只是把写入放进当前事务，冲突检查发生在提交阶段；并发更新了本事务读取过的键时，最终提交仍会失败。

把 DetectConflicts 关闭能解决问题吗？

它会改变冲突检测语义，不能作为通用修复。只有在已经证明业务允许盲写、并理解一致性取舍时，才应单独评估该选项。