Go bbolt 读事务内部启动写事务为什么会阻塞

Go bbolt 里，View 回调内部再次调用 Update，阻塞通常不是“写入太慢”，而是读写事务的生命周期互相等待。bbolt 同时允许多个只读事务，但同一时刻只有一个读写事务；写事务还可能需要重新映射数据文件，仍未结束的只读事务会让它无法完成这项工作。

官方地址：https://github.com/etcd-io/bbolt

先把读事务中要用的数据复制出来，结束 View，再在事务外启动独立的 Update。不要在同一个读事务生命周期里等待写事务完成。

先判断是不是读写事务嵌套

值班时先找三类信号：goroutine 卡在 db.Update，外层 db.View 回调迟迟不返回，以及同一调用链同时出现读事务和写事务。下面这种写法把两个生命周期叠在一起，读事务不结束，写事务就可能一直等。

// 错误示例：View 尚未返回时又等待 Update 完成。
err := db.View(func(tx *bolt.Tx) error {
    // 读取和判断可以在这里完成，但不要在这里启动写事务。
    b := tx.Bucket([]byte("jobs"))
    if b == nil || b.Get([]byte("pending")) == nil {
        return nil
    }
    // 写事务需要等待当前只读事务释放资源，形成相互等待风险。
    return db.Update(func(writeTx *bolt.Tx) error {
        return writeTx.Bucket([]byte("jobs")).Put([]byte("state"), []byte("done"))
    })
})
if err != nil {
    return err
}

快速判断时不要先改超时或盲目加锁。先确认 Update 是否由 View、游标回调或仍持有 *bolt.Tx 的函数间接触发；bbolt 官方 README 也明确提醒，事务通常不应在同一个 goroutine 中同时打开并相互依赖。

把读取结果复制到事务外

处理方式是拆开两个阶段：View 只负责读取和判断，并把后续需要的数据复制到事务外；回调返回后，外层再调用 Update。官方文档还提醒，Get 返回的字节只在事务打开期间有效，因此复制动作不能省略。

// markDone 先读取快照，再用独立写事务更新状态。
func markDone(db *bolt.DB, id []byte) error {
    var shouldWrite bool

    err := db.View(func(tx *bolt.Tx) error {
        // 只在读事务内判断条件，不把 tx 带到外层保存。
        bucket := tx.Bucket([]byte("jobs"))
        if bucket == nil {
            return fmt.Errorf("jobs bucket does not exist")
        }
        value := bucket.Get(id)
        // 只保存判断结果；若要保存字节，必须 append 到新切片。
        shouldWrite = value != nil && bytes.Equal(value, []byte("pending"))
        return nil
    })
    if err != nil || !shouldWrite {
        return err
    }

    return db.Update(func(tx *bolt.Tx) error {
        // View 已经返回，写事务拥有独立的生命周期。
        bucket := tx.Bucket([]byte("jobs"))
        if bucket == nil {
            return fmt.Errorf("jobs bucket does not exist")
        }
        // Put 的错误必须返回，让 Update 决定提交还是回滚。
        return bucket.Put(id, []byte("done"))
    })
}

如果需要把值带出事务，写成 copied := append([]byte(nil), value...)；不要把 value 的原切片直接交给异步 worker。这个示例只表达结构关系，图示和代码都不是本机运行证据。

处理步骤与回滚路径

发现线上 worker 阻塞时，可以按这个顺序处理：

1. 止住触发源：暂停会进入嵌套调用链的消费 worker，避免继续堆积新的阻塞 goroutine。
2. 保留现场：记录调用链、事务入口、最后一次业务键和阻塞开始时间；不要先强制删除数据库文件。
3. 拆分生命周期：把读取判断、数据复制、写入提交拆成不重叠的 View 与 Update。
4. 小流量恢复：先恢复一个 worker，确认写入耗时和队列长度回落，再恢复其余消费者。

如果补丁仍未准备好，回滚路径是恢复到“只读不写”的安全版本，或暂时关闭触发状态更新的功能开关。不要通过缩短数据库打开超时来掩盖事务嵌套；Open 的超时只适合处理数据库文件锁等待，不会修复一个已经进入回调的事务生命周期问题。

告警确认与复盘清单

告警至少观察四项：View/Update 持续时间、写事务排队时长、消费 worker 数量和业务队列积压。恢复后检查是否还有函数保存 *bolt.Tx、是否把 Get 返回的字节带出事务，以及每个手动 Begin 是否对应明确的 Rollback 或 Commit。

复盘时把“事务嵌套”加入代码评审清单：读回调只读，写回调只写；跨事务传递值时复制字节；业务副作用放在成功提交之后。这样比给数据库外围增加一层锁更容易解释，也更容易定位下一次阻塞。

相关问题

bbolt 可以同时打开多个只读事务吗？

可以，但每个事务以及由它创建的对象都要遵守生命周期边界，不能让一个事务依赖另一个同时打开的事务。

为什么把 Get 返回的字节复制出来？

因为返回值只在事务保持打开时有效。要交给事务外逻辑或异步 worker，应复制到独立切片。