背景

近期看到一篇文章，真的感嘆作者的洞察力，在開發(fā)時(shí)有可能就會(huì)犯這樣的錯(cuò)誤，所以一定要多學(xué)習(xí)，多實(shí)踐。其問題就是你在提交事務(wù)時(shí)，如果中間有其他業(yè)務(wù)就取消操作，那么事務(wù)也關(guān)閉了嗎？

事務(wù)實(shí)踐

服務(wù)端在進(jìn)行和數(shù)據(jù)庫交互時(shí)，對(duì)于一些場(chǎng)景我們可能會(huì)使用事務(wù)來保證數(shù)據(jù)的冪等性。比如在一個(gè)更新的場(chǎng)景時(shí)基本操作流程時(shí)如下：

• 開啟數(shù)據(jù)庫事務(wù)
• 通過 ID 獲取數(shù)據(jù)記錄
• 確認(rèn)是否可以進(jìn)行更新操作
• 如果可以更新操作就更新記錄
• 提交事務(wù)
• 如果遇到錯(cuò)誤，就回滾事務(wù)

在從數(shù)據(jù)庫中獲取數(shù)據(jù)時(shí)，可以通過鎖行的方式防止其他服務(wù)或者程序也對(duì)這條記錄進(jìn)行操作，比如使用 select ... for update 方式獲取數(shù)據(jù)并鎖定該記錄。以下是簡(jiǎn)單的使用事務(wù)操作數(shù)據(jù)的的方法：

func (user *UserResp) DeleteUser(ctx context.Context, id string) error {
	tx, err := user.db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer func() {
		if err != nil {
			tx.Rollback()
		}
	}()
	result, err := user.handler.getById(id)
	if err != nil {
		return err
	}
	if result.IsDeleted {
		return nil
	}
	if err = user.handler.Delete(id); err != nil {
		return err
	}
	if err = tx.Commit(); err != nil {
		return err
	}
	return nil
}

事務(wù)說明

從上面的源碼整體看起來沒什么問題。在進(jìn)行相關(guān)的操作時(shí)只要正常刪除從db 中刪除數(shù)據(jù)后就完成提交事務(wù)，但是如果在期間如果發(fā)生問題就會(huì)返回error就會(huì)引發(fā) rollback 操作。

但還有一個(gè)需要注意的點(diǎn)，當(dāng)獲取到的數(shù)據(jù)時(shí)，判斷到該記錄已經(jīng)被刪除時(shí)，就會(huì)結(jié)束操作，但是結(jié)束操作卻沒有對(duì)事務(wù)進(jìn)行釋放操作，所以就會(huì)造成一個(gè)很大的問題：數(shù)據(jù)量大的時(shí)候就會(huì)造成整個(gè)后續(xù)所有的請(qǐng)求都超時(shí)，導(dǎo)致所有的請(qǐng)求都不能完成操作。

tx.releaseConn(err)

可以看下事務(wù)實(shí)現(xiàn)的源碼，無論在 rollback 還是 commit 都會(huì)有 releaseConn 釋放連接，所以之前的例子中 defer 函數(shù)僅在出現(xiàn)錯(cuò)誤的時(shí)才調(diào)用回滾，如果不提交也不回滾就會(huì)導(dǎo)致事務(wù)一直處于活躍的狀態(tài)，就會(huì)一直持有該事務(wù)，其請(qǐng)求再過來時(shí)達(dá)到最大值時(shí)就會(huì)造成事務(wù)超時(shí)。

優(yōu)化方案

解決問題有一個(gè)很簡(jiǎn)單的的方案就是每個(gè)判斷 error 的條件下都進(jìn)行回滾。也可以直接在 defer 函數(shù)改成回滾事務(wù)，提交事務(wù)后再執(zhí)行回滾也不會(huì)執(zhí)行任何操作。

	defer func() {
			tx.Rollback()
	}()

但是沒有任何更改也進(jìn)行提交，然后只有發(fā)生錯(cuò)誤才進(jìn)行回滾可能會(huì)影響代碼的可讀性。在開啟事務(wù)的方法中你會(huì)看到在調(diào)用 beginDC 的方法中有使用 context 服務(wù)上下文進(jìn)行回滾事務(wù)。所以還有一個(gè)方案就是通過取消上下文來讓事務(wù)結(jié)束從而釋放鎖。

// 方法 beginDC 中的代碼片段
ctx, cancel := context.WithCancel(ctx)
	tx = &Tx{
		db:                 db,
		dc:                 dc,
		releaseConn:        release,
		txi:                txi,
		cancel:             cancel,
		keepConnOnRollback: keepConnOnRollback,
		ctx:                ctx,
	}
	go tx.awaitDone()

所以我們可以直接使用取消上下文的方法，可以先創(chuàng)建一個(gè)新的取消上下文，如果沒有回滾或者提交時(shí)，最后執(zhí)行cancel 就會(huì)通知事務(wù)已完成，然后就會(huì)關(guān)閉事務(wù)。

func (user *UserResp) DeleteUser(ctx context.Context, id string) error {
ctx, cancel := context.WithCancel(ctx)
    defer cancel()
    tx, err := s.db.BeginTxx(ctx, nil)
    if err != nil {
        return nil, err
    }
    defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
......
}

總結(jié)

所以在使用事務(wù)處理業(yè)務(wù)的時(shí)候，一定要注意業(yè)務(wù)邏輯，如果在業(yè)務(wù)邏輯中出現(xiàn)某些條件場(chǎng)景不進(jìn)行操作數(shù)據(jù)庫時(shí)，結(jié)束這次業(yè)務(wù)處理時(shí)也要記得關(guān)閉事務(wù)。要么就關(guān)閉事務(wù)，要么就是無論有沒有處理都提交事務(wù)。這可能只是一個(gè)小小的問題，但是如果在交易的場(chǎng)景中如果沒有注意就可能造成很大的問題。

參考資料：

• itnext.io/a-billion-d…

以上就是Go事務(wù)中止時(shí)是否真的結(jié)束事務(wù)解析的詳細(xì)內(nèi)容，更多關(guān)于Go事務(wù)中止結(jié)束的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論