Golang后端学习笔记 — 7. Golang如何处理数据库事务锁

最新推荐文章于 2024-08-25 21:50:20 发布
最新推荐文章于 2024-08-25 21:50:20 发布
阅读量1.1k 收藏 2
点赞数
分类专栏： Golang后端学习笔记 文章标签： Golang
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/8665048/article/details/124093496
版权

上一节，学习了如何实现一个简单的转账事务，但是，我们还没做更新账户余额的操作，因为，它稍复杂一些，需要小心处理并发事务以避免死锁。

本节，将实现这个功能，顺便学习一下数据库锁，以及如何调试死锁的情况。(有点硬核，需要耐心学习，最好自己手动操作一遍，以便深入理解)

测试驱动开发(TDD)

这次，将使用一种不同的实现方式，即测试驱动开发(TDD)。
思路是：首先编写测试，然后逐渐改进功能代码直到测试通过。

接着上一节的store_test.go，需要TODO的地方，检查更新后的账户余额

		// 3. 为`ToAccount`创建一个账目记录，金额为`+10`
		result.ToEntry, err = q.CreateEntry(ctx, CreateEntryParams{
			AccountID: arg.ToAccountID,
			Amount:    arg.Amount,
		})
		if err != nil {
			return err
		}

		// TODO: 更新账户余额操作后面再做

要完成这个单元测试，需要先检查钱是从哪转出来的，然后，检查钱转到哪个账户里面去了。

		// 首先，检查钱是从哪转出来的，
		fromAccount := result.FromAccount
		require.NotEmpty(t, fromAccount)
		require.Equal(t, account1.ID, fromAccount.ID)

		// 然后，检查钱转到哪个账户里面去了
		toAccount := result.ToAccount
		require.NotEmpty(t, toAccount)
		require.Equal(t, account2.ID, toAccount.ID)

接着，计算一下，转出的金额 = account1.Balance - fromAccount.Balance，转入的金额 = toAccount.Balance - account2.Balance，需要检查以下几项:

  • 转出的金额应该和转入的金额相等
  • 并且转出的金额必须大于0
  • 转出的金额应该可以被每笔交易的金额整除。因为，如果产生了5次转账，这里设置的是每次转出10，总共转出了50，所以，50除以10是可以整除的。
  • 转出总金额除以每次转出的金额等于转出次数k，k必须是大于等于1，并且小于等于n的
  • 此外，每笔交易的 k 必须是唯一的，意思是第1笔交易时，k应该等于1，第2笔交易时，k应该等于2…
		// 转账方：转出的金额
		diff1 := account1.Balance - fromAccount.Balance
		// 收钱方：转入的金额
		diff2 := toAccount.Balance - account2.Balance
		// 这两个值应该相同
		require.Equal(t, diff1, diff2)
		// 转出来的钱应该大于0
		require.True(t, diff1 > 0)
		// 转出的金额应该可以被每笔交易的金额整除
		require.True(t, diff1%amount == 0)

最后，在最后在 for 循环外面,检查这两个账户的最终余额:

	// 最后在 for 循环外面,检查这两个账户的最终余额
	updateAccount1, err := testQueries.GetAccount(context.Background(), account1.ID)
	require.NoError(t, err)

	updateAccount2, err := testQueries.GetAccount(context.Background(), account2.ID)
	require.NoError(t, err)

	fmt.Println(">> after:", updateAccount1.Balance, updateAccount2.Balance)
	// account1的余额减去转账次数乘以每次转账的金额，必须等于最终的余额
	require.Equal(t, account1.Balance-int64(n)*amount, updateAccount1.Balance)
	require.Equal(t, account2.Balance+int64(n)*amount, updateAccount2.Balance)

完整的代码如下：

package db

import (
	"context"
	"fmt"
	"testing"

	"github.com/stretchr/testify/require"
)

func TestTransferTx(t *testing.T) {
	store := NewStore(testDB)

	account1 := createRandomAccount(t)
	account2 := createRandomAccount(t)
	fmt.Println(">> before:", account1.Balance, account2.Balance)

	n := 5
	amount := int64(10)

	errs := make(chan error)
	results := make(chan TransferTxResult)

	for i := 0; i < n; i++ {
		go func() {
			result, err := store.TransferTx(context.Background(), TransferTxParams{
				FromAccountID: account1.ID,
				ToAccountID:   account2.ID,
				Amount:        amount,
			})

			errs <- err
			results <- result
		}()
	}

	// 检查结果
	existed := make(map[int]bool)

	for i := 0; i < n; i++ {
		err := <-errs
		require.NoError(t, err)

		result := <-results
		require.NotEmpty(t, result)

		// check transfer
		transfer := result.Transfer
		require.NotEmpty(t, transfer)
		require.Equal(t, account1.ID, transfer.FromAccountID)
		require.Equal(t, account2.ID, transfer.ToAccountID)
		require.Equal(t, amount, transfer.Amount)
		require.NotZero(t, transfer.ID)
		require.NotZero(t, transfer.CreatedAt)

		_, err = store.GetTransfer(context.Background(), transfer.ID)
		require.NoError(t, err)

		// check entries
		formEntry := result.FromEntry
		require.NotEmpty(t, formEntry)
		require.Equal(t, account1.ID, formEntry.AccountID)
		require.Equal(t, -amount, formEntry.Amount)
		require.NotZero(t, formEntry.ID)
		require.NotZero(t, formEntry.CreatedAt)

		_, err = store.GetEntry(context.Background(), formEntry.ID)
		require.NoError(t, err)

		toEntry := result.ToEntry
		require.NotEmpty(t, toEntry)
		require.Equal(t, account2.ID, toEntry.AccountID)
		require.Equal(t, amount, toEntry.Amount)
		require.NotZero(t, toEntry.ID)
		require.NotZero(t, toEntry.CreatedAt)

		_, err = store.GetEntry(context.Background(), toEntry.ID)
		require.NoError(t, err)

		// 首先，检查钱是从哪转出来的，
		fromAccount := result.FromAccount
		require.NotEmpty(t, fromAccount)
		require.Equal(t, account1.ID, fromAccount.ID)

		// 然后，检查钱转到哪个账户里面去了
		toAccount := result.ToAccount
		require.NotEmpty(t, toAccount)
		require.Equal(t, account2.ID, toAccount.ID)

		// 检查更新后的账户余额
		fmt.Println(">> tx:", fromAccount.Balance, toAccount.Balance)
		// 转账方：转出的金额
		diff1 := account1.Balance - fromAccount.Balance
		// 收钱方：转入的金额
		diff2 := toAccount.Balance - account2.Balance
		// 这两个值应该相同
		require.Equal(t, diff1, diff2)
		// 转出来的钱应该大于0
		require.True(t, diff1 > 0)
		// 转出的金额应该可以被每笔交易的金额整除
		require.True(t, diff1%amount == 0)

		// 计算 k = diff1 除以 每笔交易的金额，k 必须是大于等于1，并且小于等于n的
		// 此外，每笔交易的 k 必须是唯一的，意思是第1笔交易时，k应该等于1，第2笔交易时，k应该等于2...
		// 上面，需要定义一个新变量，existed
		k := int(diff1 / amount)
		require.True(t, k >= 1 && k <= n)
		// 检查这个map,不应该包含 k
		require.NotContains(t, existed, k)
		// 之后，给这个 map 赋值
		existed[k] = true
	}
	// 最后在 for 循环外面,检查这两个账户的最终余额
	updateAccount1, err := testQueries.GetAccount(context.Background(), account1.ID)
	require.NoError(t, err)

	updateAccount2, err := testQueries.GetAccount(context.Background(), account2.ID)
	require.NoError(t, err)

	fmt.Println(">> after:", updateAccount1.Balance, updateAccount2.Balance)
	// account1的余额减去转账次数乘以每次转账的金额，必须等于最终的余额
	require.Equal(t, account1.Balance-int64(n)*amount, updateAccount1.Balance)
	require.Equal(t, account2.Balance+int64(n)*amount, updateAccount2.Balance)
}

运行，run test，可以看到如下错误，
run test 错误

这是因为具体的功能实现还没写，好，接着打开store.go文件，来编写未实现的功能。

更新账户的余额（错误的方法）

首先，从数据库中获取该account，然后从余额中增加或减去一些金额，然后更新到数据库。但是，如果没有适当的锁机制，这通常会出现错误。像这样：

		// 从数据库中获取 account -> 更新账户余额
		account1, err := q.GetAccount(ctx, arg.FromAccountID)
		if err != nil {
			return err
		}

		result.FromAccount, err = q.UpdateAccount(ctx, UpdateAccountParams{
			ID:      arg.FromAccountID,
			Balance: account1.Balance - arg.Amount,
		})
		if err != nil {
			return err
		}

		account2, err := q.GetAccount(ctx, arg.ToAccountID)
		if err != nil {
			return err
		}

		result.ToAccount, err = q.UpdateAccount(ctx, UpdateAccountParams{
			ID:      arg.ToAccountID,
			Balance: account2.Balance + arg.Amount,
		})
		if err != nil {
			return err
		}

运行一下单元测试run test，来看一下，发生了错误：
数据库事务异常
在日志中，可以看到，前两笔转账交易是正确的，到第3笔转账，出现了问题，account1账户的余额并没有减10,仍然是166。

要了解具体的原因，让我们看一下GetAccount的SQL语句：

-- name: GetAccount :one
SELECT * FROM accounts
WHERE id = $1 LIMIT 1;

它就是普通的SQL查询语句，它不会阻止来自其他转账交易同时读取相同账户的数据。所以，2个并发交易可以得到account1相同的值，导致并发的情况出错。

为了演示一下，这个是怎么发生的，让我们打开两个终端，都进入到postgres控制台：

docker exec -it postgres14 psql -U root -d simple_bank

进入postgres控制台

不加锁查询的情况

让我们在两个不同的终端运行2个并行事务。

  • 在第一个控制台输入BEGIN;开启第一个事务
  • 在第二个控制台输入BEGIN;开启第二个事务
  • 在第一个控制台输入select * from accounts where id=1;
  • 在第二个控制台也输入select * from accounts where id=1;

可以看到，相同账户的数据在两个事务里，会立即返回出来，并不会被阻止。因此，我们先在这两个控制台里输入ROLLBACK;回滚这两个事务，并学习一下如何修复它。

加锁查询的情况

  • 在第一个控制台输入BEGIN;开启第一个事务
  • 在第二个控制台输入BEGIN;开启第二个事务
  • 在第一个控制台输入select * from accounts where id=1 for update;
  • 在第二个控制台输入select * from accounts where id=1 for update;，可以看到，它不返回结果了，被阻塞住了，必须等待第一个事务提交或回滚。
  • 在第一个控制台输入update accounts set balance=500 where id=1;，切换到第二个控制台，看到它仍然阻塞
  • 在第一个控制台输入COMMIT;,切换到第二个控制台，可以看到返回出来结果了，balance是500

加锁更新账户余额

知道问题在哪里了，我们回到account.sql文件，再增加一条sql语句GetAccountForUpdate：

-- name: GetAccountForUpdate :one
SELECT * FROM accounts
WHERE id = $1 LIMIT 1
FOR UPDATE;

然后，在项目终端下运行make sqlc来重新生成代码，然后，可以看到account.sql.go文件里新增加了个GetAccountForUpdate函数。

在store.go里面就可以用到它了，把更新账户余额的操作修改一下：

		// 从数据库中获取 account -> 更新账户余额
		account1, err := q.GetAccountForUpdate(ctx, arg.FromAccountID)
		if err != nil {
			return err
		}

		result.FromAccount, err = q.UpdateAccount(ctx, UpdateAccountParams{
			ID:      arg.FromAccountID,
			Balance: account1.Balance - arg.Amount,
		})
		if err != nil {
			return err
		}

		account2, err := q.GetAccountForUpdate(ctx, arg.ToAccountID)
		if err != nil {
			return err
		}

		result.ToAccount, err = q.UpdateAccount(ctx, UpdateAccountParams{
			ID:      arg.ToAccountID,
			Balance: account2.Balance + arg.Amount,
		})
		if err != nil {
			return err
		}

再次，运行单元测试run test，不幸的是，它又出错了。
deadlock detected
这次报的错是：检测到死锁了 deadlock detected，所以，怎么解决呢？接下来，学习如何调试这种死锁的情况。

调试死锁

为了弄清楚为什么会发生死锁(deadlock)，我们需要打印一些日志，查看一下哪个事务正在调用哪个查询sql，以及调用顺序是怎么样的。

所以，我们必须给每个事务分配个名称，并通过上下文参数传递给 TransferTx() 函数，在store_test.go里面的for i := 0; i < n; i++ {内，增加

txName := fmt.Sprintf("tx %d", i+1)

为了把这个txName通过context传递，需要在store.go里面定义一个空的结构体

var txKey = struct{}{}

这里的第二个{}表示空的对象，回到store_test.go改造一下，把txKey和txName作为参数传给context.WithValue()：

	for i := 0; i < n; i++ {
		txName := fmt.Sprintf("tx %d", i+1)
		go func() {
			ctx := context.WithValue(context.Background(), txKey, txName)
			result, err := store.TransferTx(ctx, TransferTxParams{
				FromAccountID: account1.ID,
				ToAccountID:   account2.ID,
				Amount:        amount,
			})

			errs <- err
			results <- result
		}()
	}

这样，上下文就可以保存事务名称了。

来到store.go里面的TransferTx函数，增加日志输出：

var txKey = struct{}{}

func (store *Store) TransferTx(ctx context.Context, arg TransferTxParams) (TransferTxResult, error) {
	var result TransferTxResult

	err := store.execTx(ctx, func(q *Queries) error {
		var err error

		txName := ctx.Value(txKey)

		// 1. 创建一个金额等于`10`的转账记录
		fmt.Println(txName, "create transfer")
		result.Transfer, err = q.CreateTransfer(ctx, CreateTransferParams{
			FromAccountID: arg.FromAccountID,
			ToAccountID:   arg.ToAccountID,
			Amount:        arg.Amount,
		})
		if err != nil {
			return err
		}

		// 2. 为`FromAccount`创建一个账目记录，金额为`-10`
		fmt.Println(txName, "create entry 1")
		result.FromEntry, err = q.CreateEntry(ctx, CreateEntryParams{
			AccountID: arg.FromAccountID,
			Amount:    -arg.Amount,
		})
		if err != nil {
			return err
		}

		// 3. 为`ToAccount`创建一个账目记录，金额为`+10`
		fmt.Println(txName, "create entry 2")
		result.ToEntry, err = q.CreateEntry(ctx, CreateEntryParams{
			AccountID: arg.ToAccountID,
			Amount:    arg.Amount,
		})
		if err != nil {
			return err
		}

		// 从数据库中获取 account -> 更新账户余额
		fmt.Println(txName, "get account 1")
		account1, err := q.GetAccountForUpdate(ctx, arg.FromAccountID)
		if err != nil {
			return err
		}

		fmt.Println(txName, "update account 1")
		result.FromAccount, err = q.UpdateAccount(ctx, UpdateAccountParams{
			ID:      arg.FromAccountID,
			Balance: account1.Balance - arg.Amount,
		})
		if err != nil {
			return err
		}

		fmt.Println(txName, "get account 2")
		account2, err := q.GetAccountForUpdate(ctx, arg.ToAccountID)
		if err != nil {
			return err
		}

		fmt.Println(txName, "update account 2")
		result.ToAccount, err = q.UpdateAccount(ctx, UpdateAccountParams{
			ID:      arg.ToAccountID,
			Balance: account2.Balance + arg.Amount,
		})
		if err != nil {
			return err
		}

		return err
	})

	return result, err
}

为了便于调试，把store_test.go里面的并发数量n改成3，便于跟踪调试，运行它run test，可以看到保存了，并输出了我们打印的日志：

=== RUN   TestTransferTx
>> before: 103 980
tx 3 create transfer
tx 3 create entry 1
tx 3 create entry 2
tx 2 create transfer
tx 1 create transfer
tx 3 get account 1
tx 3 update account 1
tx 3 get account 2
tx 3 update account 2
tx 2 create entry 1
tx 1 create entry 1
tx 1 create entry 2
tx 2 create entry 2
tx 1 get account 1
tx 2 get account 1
>> tx: 93 990
tx 2 update account 1

到这里出错了，现在就要跟踪一下，是怎么出这个错误的，我们来用go执行的过程模拟一下，先把go执行转账事务所需要的sql整理出来，就是下面这个流程：

BEGIN;
-- create transfer
INSERT INTO transfers (from_account_id, to_account_id, amount) VALUES  (1, 2, 10) RETURNING *;
-- create entry 1
INSERT INTO entries (account_id, amount) VALUES (1, -10) RETURNING *;
-- create entry 2
INSERT INTO entries (account_id, amount) VALUES (2, 10) RETURNING *;
-- get account 1
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;
-- update account 1
UPDATE accounts SET balance = 90 WHERE id = 1 RETURNING *;
-- get account 2
SELECT * FROM accounts WHERE id = 2 FOR UPDATE;
-- update account 2
UPDATE accounts SET balance = 110 WHERE id = 2 RETURNING *;

因为我们设置了3个并发，因此，想上面操作的那样，我们打开3个postgres控制台：
3个postgres控制台
接下来，按照日志的执行顺序，分别依次在不同的postgres控制台里输入这些sql

  • 首先这3个控制台都输入BEGIN;开启事务
  • 日志tx 3 create transfer，就在第3个控制台输入，INSERT INTO transfers (from_account_id, to_account_id, amount) VALUES (1, 2, 10) RETURNING *;
  • 日志tx 3 create entry 1，就在第3个控制台输入， INSERT INTO entries (account_id, amount) VALUES (1, -10) RETURNING *;
  • 依次类推…
  • 直到这一条，tx 3 get account 1,在第3个控制台执行 SELECT * FROM accounts WHERE id = 1 FOR UPDATE;，发现卡住了，为什么INSERT transfers的时候，会引发SELECT accounts操作死锁，是不同的表啊；带着问题，我们Google搜postgres lock，在postgres的WIKI里(https://wiki.postgresql.org/wiki/Lock_Monitoring)，看到了这段:
SELECT blocked_locks.pid     AS blocked_pid,
         blocked_activity.usename  AS blocked_user,
         blocking_locks.pid     AS blocking_pid,
         blocking_activity.usename AS blocking_user,
         blocked_activity.query    AS blocked_statement,
         blocking_activity.query   AS current_statement_in_blocking_process
   FROM  pg_catalog.pg_locks         blocked_locks
    JOIN pg_catalog.pg_stat_activity blocked_activity  ON blocked_activity.pid = blocked_locks.pid
    JOIN pg_catalog.pg_locks         blocking_locks 
        ON blocking_locks.locktype = blocked_locks.locktype
        AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
        AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
        AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
        AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
        AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
        AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
        AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
        AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
        AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
        AND blocking_locks.pid != blocked_locks.pid

    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
   WHERE NOT blocked_locks.granted;

  • 把这段sql放到navicat里执行一下，可以看到：
    lock的sql
    发现，blocked的sql就是SELECT * FROM accounts WHERE id = 1 FOR UPDATE;,而引发blocking的sql是INSERT INTO transfers (from_account_id, to_account_id, amount) VALUES (1, 2, 10) RETURNING *;，因此，对这两个不同的表操作，确实会引发相互阻塞。

  • 让我们更深入的了解一下为什么SELECT查询必须等待INSERT操作，回到postgres WIKI页面，往下继续看，找到1条，找出数据库中所有的锁

SELECT a.datname,
         l.relation::regclass,
         l.transactionid,
         l.mode,
         l.GRANTED,
         a.usename,
         a.query,
         a.query_start,
         age(now(), a.query_start) AS "age",
         a.pid
FROM pg_stat_activity a
JOIN pg_locks l ON l.pid = a.pid
ORDER BY a.query_start;

把它复制到navicat中，并稍作修改，因为要查看一些更多的信息，在a.datname,后面增加a.application_name,，用来查看锁来自哪个应用。

这个sql中，

  • l.relation::regclass其实就是表名，
  • l.transactionid是事务ID，
  • 在l.mode后面增加l.locktype用来查看锁的类型，
  • l.GRANTED是锁是否被授权，
  • a.usename是运行sql的用户名，
  • a.query是持有或试图获取锁的sql语句，
  • a.query_start和age(now(), a.query_start) AS "age"在这个场景中部重要，删除它，
  • a.pid是进程ID
  • ORDER BY a.query_start改为ORDER BY a.pid更好一下，因为我们在psql控制台有3个不同的处理进程，更容易看出来哪个锁是属于哪个事务，
  • 增加WHERE a.application_name = 'psql'只关注和psql控制台相关的
  • 如下。
SELECT a.application_name,
         l.relation::regclass,
         l.transactionid,
         l.mode,
		 l.locktype,
         l.GRANTED,
         a.usename,
         a.query,
         a.pid
FROM pg_stat_activity a
JOIN pg_locks l ON l.pid = a.pid
WHERE a.application_name = 'psql'
ORDER BY a.pid;

在,navicat里运行一下，
未授权的sql
看到只有一条，GRANTED为f的记录，可以看到它的transactionid是1075，可以看到transactionid为1075的还有一条，它正在进行INSERT操作，pid为6991，但是，为什么SELECT FROM accounts表需要从INSERT INTO transfers的事务中获取锁呢？

来看一下，我们的sql建表语句，有这样的外键约束：

ALTER TABLE "transfers" ADD FOREIGN KEY ("from_account_id") REFERENCES "accounts" ("id");

所以，对transfers表的from_account_id做任何更新操作时，都会影响到accounts表做SELECT FOR UPDATE的操作，因为，这里需要获取一个锁来防止冲突，保证数据的一致性。这样，就解释了deadlock是如何发生的。如何解决这个问题呢？
让我们先把这3个控制台执行ROLLBACK;并\q退出。

修复死锁方案1

我们知道，死锁是由外键约束引起的，那我们尝试把这几个外键约束的sql都删除掉，在000001_init_schema.up.sql文件里，先注释掉下面这几行：

-- ALTER TABLE "entries" ADD FOREIGN KEY ("account_id") REFERENCES "accounts" ("id");

-- ALTER TABLE "transfers" ADD FOREIGN KEY ("from_account_id") REFERENCES "accounts" ("id");

-- ALTER TABLE "transfers" ADD FOREIGN KEY ("to_account_id") REFERENCES "accounts" ("id");

让我们把数据库降级一下make migratedown,再make migrateup，之后，再来运行这个单元测试run test，可以看到成功了。

但是，这不是最好的解决方案，因为，这样失去了保持数据一致性的良好约束。所以，恢复刚才注释掉的那几行sql代码。并运行make migratedown和make migrateup。

修复死锁方案2

打开account.sql文件，看这里

-- name: UpdateAccount :one
UPDATE accounts SET balance = $2 WHERE id = $1
RETURNING *;

更新账户余额的时候，id是永远不会更改的，因为它是账户表的主键。所以，如果我们能告诉postgres,SELECT * FROM accounts FOR UPDATE时不更新主键，那么postgres将不需要获取事务锁，因此，就不会出现deadlock。

恩，有个知识点，FOR UPDATE的时候，我们只需要明确一下，NO KEY UPDATE，说明我们不更新主键ID，像这样。

-- name: GetAccountForUpdate :one
SELECT * FROM accounts
WHERE id = $1 LIMIT 1
FOR NO KEY UPDATE;

在项目终端里，在运行make sqlc重新生成代码，再运行这个单元测试，可以看到成功了。

之后，清理一下代码，把我们之前加的打印日志都去掉吧，再运行一下单元测试，没问题，通过。
测试通过

可以，看到这个日志，每次交易后的2个账户余额是怎么变化的。

修复死锁方案3

有一种更好的方法来实现更新余额操作。目前，我们必须执行两个sql来获取并更新账户余额：

		account1, err := q.GetAccountForUpdate(ctx, arg.FromAccountID)
		if err != nil {
			return err
		}

		result.FromAccount, err = q.UpdateAccount(ctx, UpdateAccountParams{
			ID:      arg.FromAccountID,
			Balance: account1.Balance - arg.Amount,
		})
		if err != nil {
			return err
		}

其实，可以通过1个sql语句来搞定。所以，我们在account.sql里再增加一个AddAccountBalance语句，它和UpdateAccount类似，不同的是设置 balance 等于 balance + 第二个参数，如下：

-- name: AddAccountBalance :one
UPDATE accounts SET balance = balance + $2 WHERE id = $1
RETURNING *;

之后，运行make sqlc来生成代码，看到account.sql.go里面增加了如下代码：

type AddAccountBalanceParams struct {
	ID      int64 `json:"id"`
	Balance int64 `json:"balance"`
}

但是，这个参数Balance有点混淆，我们是让余额增加或减少金额，而不是更新Balance本身，在sqlc可以这样做：

-- name: AddAccountBalance :one
UPDATE accounts SET balance = balance + sqlc.arg(amount) 
WHERE id = sqlc.arg(id)
RETURNING *;

把$2改成sqlc.arg(amount),$1改成sqlc.arg(id)，之后，在运行make sqlc，可以看到生成的代码变成了这样：

type AddAccountBalanceParams struct {
	Amount int64 `json:"amount"`
	ID     int64 `json:"id"`
}

Balance变成了Amount，这样语义就清晰了。

回到store.go文件，删除GetAccountForUpdate,把UpdateAccount改为AddAccountBalance，完整代码如下：

package db

import (
	"context"
	"database/sql"
	"fmt"
)

type Store struct {
	*Queries
	db *sql.DB
}

func NewStore(db *sql.DB) *Store {
	return &Store{
		db:      db,
		Queries: New(db),
	}
}

func (store *Store) execTx(ctx context.Context, fn func(*Queries) error) error {
	tx, err := store.db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}

	q := New(tx)
	err = fn(q)
	if err != nil {
		if rbErr := tx.Rollback(); rbErr != nil {
			return fmt.Errorf("tx err: %v, rb err: %v", err, rbErr)
		}
		return err
	}

	return tx.Commit()
}

type TransferTxParams struct {
	FromAccountID int64 `json:"from_account_id"`
	ToAccountID   int64 `json:"to_account_id"`
	Amount        int64 `json:"amount"`
}

type TransferTxResult struct {
	Transfer    Transfer `json:"transfer"`
	FromAccount Account  `json:"from_account"`
	ToAccount   Account  `json:"to_account"`
	FromEntry   Entry    `json:"from_entry"`
	ToEntry     Entry    `json:"to_entry"`
}

func (store *Store) TransferTx(ctx context.Context, arg TransferTxParams) (TransferTxResult, error) {
	var result TransferTxResult

	err := store.execTx(ctx, func(q *Queries) error {
		var err error

		// 1. 创建一个金额等于`10`的转账记录
		result.Transfer, err = q.CreateTransfer(ctx, CreateTransferParams{
			FromAccountID: arg.FromAccountID,
			ToAccountID:   arg.ToAccountID,
			Amount:        arg.Amount,
		})
		if err != nil {
			return err
		}

		// 2. 为`FromAccount`创建一个账目记录，金额为`-10`
		result.FromEntry, err = q.CreateEntry(ctx, CreateEntryParams{
			AccountID: arg.FromAccountID,
			Amount:    -arg.Amount,
		})
		if err != nil {
			return err
		}

		// 3. 为`ToAccount`创建一个账目记录，金额为`+10`
		result.ToEntry, err = q.CreateEntry(ctx, CreateEntryParams{
			AccountID: arg.ToAccountID,
			Amount:    arg.Amount,
		})
		if err != nil {
			return err
		}

		// 更新账户余额
		result.FromAccount, err = q.AddAccountBalance(ctx, AddAccountBalanceParams{
			ID:     arg.FromAccountID,
			Amount: -arg.Amount,
		})
		if err != nil {
			return err
		}

		result.ToAccount, err = q.AddAccountBalance(ctx, AddAccountBalanceParams{
			ID:     arg.ToAccountID,
			Amount: arg.Amount,
		})
		if err != nil {
			return err
		}

		return err
	})

	return result, err
}

再次运行单元测试，没问题，测试通过。

好了，本次课程学习结束。下节，将继续学习如何避免数据库事务查询中的死锁顺序问题

宝码
关注
专栏目录
golang学习笔记（进阶篇）
lcynone的博客
01-13 701
Golang学习笔记_进阶篇
Golang 使用goroutine并发处理订单的示例
canduecho的专栏
06-20 1156
为了保证每个goroutine都能够独立地处理一部分订单数据，我们根据循环变量i计算了每个goroutine需要处理的订单数据的起始位置和结束位置，并将它们作为参数传递给processOrders函数。与传统的线程相比，goroutine的创建和销毁都非常快速，而且它们的调度是由Go语言的运行时系统自动管理的，因此使用goroutine可以很方便地实现并发编程。然后，在 `processOrders` 函数中，我们遍历每个订单，并使用 `db.Exec` 方法执行 SQL 插入语句将订单保存到数据库中。
Go语言 用数据库实现分布式锁
jojozym的博客
06-29 586
业务场景：该服务需要每隔固定时间同步一次数据库，服务部署在多台机器，我们只希望同时有一台机器在做同步操作。 实现：用一个scheduler.go跑线程 //scheduler.go type Scheduler struct { } var scheduler *Scheduler var scheduler_once sync.Once func GetSchedulerInstance() *Scheduler { scheduler_once.Do(func() { scheduler =
Golang中的锁
qq_45838790的博客
03-25 2052
锁是一种在并发编程中常用的同步机制，用于管理对共享资源的访问。Golang提供了多种锁类型，可以满足不同的并发编程需求。
Golang数据库事务实践
残星说梦话
04-02 527
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。工作原理：事务管理器启动事务并将事务放入回调，存储库工厂方法使用事务创建自己。
Golang后端学习笔记 — 6. Golang操作数据库事务的方法
拎小壶冲
04-12 2059
之前，学习了对数据库的每个表执行CRUD操作。真实的场景中，我们经常需要执行一个事务，它组合了多个表的相关操作。本节学习如何在Golang中实现它。 在开始之前，先聊一下事务。 什么是数据库事务？ 它是一个单一的工作单元，通常由多个表操作组成。 比如：在我们的小银行项目中，我们要从张三的账户中向李四的账户中转账10元。该交易就包括5个操作，涉及到accounts表、entries表和transfers表： 创建一个金额等于10的转账记录(transfers表) 为张三创建一个账目记录，金额为-10(ent
Golang学习笔记-Golang中的锁
最新发布
qq_24428851的博客
08-25 2269
Go标准库的中的sync.Cond是一个条件变量，它可以让一系列的goroutine都在满足特定条件下时候被唤醒，每一个 sync.Cond 结构体在初始化时都需要传入一个互斥锁，我们可以通过下面的例子了解它的使用方法。因为请求的哈希在业务上一般表示相同的请求，所以上述代码使用它作为请求的键。这个是Go语言的扩展包中提供的另外一个信号量，它能够在一个服务中抑制对下游的多次重复请求，比如在redis的缓存雪崩中，能够限制对同一个 Key 的多次重复请求，减少对下游的瞬时流量。上述两个加起来，只占用8个字节。
Golang笔记
怨行客
10-18 470
协程是用户态轻量级线程协程是线程调度的基本单位通常在函数前加上go关键字就能实现并发。一个Goroutine会以一个很小的栈启动2KB或4KB，当遇到栈空间不足时，栈会自动伸缩， 因此可以轻易实现成千上万个goroutine同时启动。
用Golang/Go搭建大型电商系统,要用到前后台的技术和框架
canduecho的专栏
05-22 1022
微服务是一种软件架构风格，它将一个大型的应用程序拆分为一组小型的、相互独立的服务，每个服务都运行在自己的进程中，通过轻量级的通信机制相互协作。每个服务都有自己的功能和数据存储，可以独立部署、升级和扩展，从而提高了应用程序的可维护性、可伸缩性和可靠性。事务的最终一致性是指，当一个分布式系统中的多个服务对同一数据进行操作时，这些操作可能会发生冲突，导致数据的不一致。为了保证数据的一致性，需要采取一系列手段，确保最终数据达到一致状态。这种手段称为最终一致性。
Go语学习笔记 - gorm使用 - gorm处理错误 Web框架Gin（十）
m0_67394360的博客
08-01 891
学习笔记，写到哪是哪。目前gorm对数据库的一些操作基本了解。本篇主要测试一下gorm的异常处理方式。编写一个接口来测试一下异常。在student_service下新增TestError方法。如果sql无法获取到record，会报出ErrRecordNotFound异常。验证一下接口执行后的打印输出。可以看到是全局捕获的异常响应报文。...
Golang锁
qq_39920531的博客
03-01 787
转载自：https://www.jianshu.com/p/a1d62b6a13ac Go 语言提供两类锁: 互斥锁(Mutex)和读写锁(RWMutex)。其中读写锁(RWMutex)是基于互斥锁(Mutex)实现的，互斥锁的定义如下： type Mutex struct { state int32 sema uint32 } 互斥锁提供两个API，Lock和Unlock，按字面意...
Golang实现一个事务型内存数据库
Qinng的博客
03-03 1107
MossDB的实现细节已经分析完成，支持了事务、持久化、Watch与过期删除等特性，后续可能会支持HTTP API、存储快照等功能。
go后端学习路线
mindcarver
10-09 2309
https://blog.csdn.net/wudawei071193/article/details/100187015
Mysql事务实现原理以及在Go语言中使用数据库事务
haming123的专栏
04-24 705
数据库并发访问问题 数据库使用中通常存在多个客户端同时访问数据库，因此数据库系统要能够处理这种并发访问的情况。在实际工作中，并发访问时数据库使用中的常态，然而并发访问时数据库时，可能出现以下问题： 脏读： 当前事务读到其他事务未提交的数据（脏数据），这种现象是脏读。在这里我们使用一个简单的订单表说明什么情况下会出现脏读，订单表（order）的表结构如下： 字段名 数据类型 描述 id bigint(20) 自增id no varchar(64) 订单编号 status tinyi
事务中的锁，行锁与表锁
03-01 1058
当执行事务时，相当于执行了锁，来保持数据的一致性，但是锁分多种，有行锁，表锁。行锁就是只锁定那一行，那一条记录，别的连接下的操作还可以操作这张表。表锁就是锁定整张表，只有当前连接执行完事务，才可以解锁。   就效率而然，当然是行锁好，适用与多线程和高并发的情况，不过行锁对数据库会带来额外的开销。表锁高并发就差一点了，但单个的话快一点。   以mysql为例，有索引并且使用了
golang mysql加锁_使用golang实现类InnoDB数据行锁效果
weixin_39626237的博客
01-28 1082
在关系型数据库领域，为人津津乐道的一个特性，便是数据库的锁设计及事务隔离级别。本文通过golang系统库sync，来实现简单的数据库数据读写操作。场景说明小明经营一家水果店，创业初始资金为100000元，所有的收入以及支出通过2个银行账户进行往来。因交易频繁，可能存在并发更新账户数据及查账的需求，需要保障账户数据针对所有操作的一致性。此处需要引入读写锁，保障读写的安全性及高效性。需求分析在MySQ...
事务死锁
从现在go，一切都不迟
07-01 4693
并发的几个事务同时发生，不加锁控制的话数据就会乱套了，而加了锁后，又是并发访问会出现死锁，所以就会出现避免死锁的一些措施。 首先谈并发：理论指的是在一段时间同时对某件事进行操作。 注意精度问题，修改数据库是在一段时间内操作，不是在某个时刻，而日志则会从 时刻 开始记录你的操作。 造成死锁的原因是为了防止 不同的用户同时间（不是时刻）都对某个数据修改，造成访问不一致的问题。 比如你读了数据库的一个数
Go 语言中的死锁问题解决
兔子学前端
09-22 720
目录 死锁 如何避免死锁死锁代码 死锁 死锁的4个条件 不可剥夺 线程已经获得的资源，在未使用完之前，不能被其他线程剥夺，只能在使用完后自己释放。 请求保持 线程 T1 保持了一个资源 R1 占用，但是又提出另外一个资源 R2 请求，此时，资源 R2 被线程 T2 占用，于是 T1 线程必须等待，但又对自己保持的 R1 资源不释放。 循环等待 死锁发生时，必然存在一个 “进程-资源环形链”，例如 进程p0 等待 p1 占用资源，p1 等待 p2 占用的资源， p2 等待 p0 占用的资源
记一次gorm事务及调试解决mysql死锁
m0_46351795的博客
07-27 2557
gorm以及mysql死锁处理
"Golang2-new.docx：个人学习golang笔记及入门参考
Golang2-new.docx是一份个人学习golang笔记，是从多种教程中总结而来，作为入门参考。该笔记包括以下目录： 1. 入门 1.1 Hello World 1.2 命令行参数 2. 程序结构 2.1 类型 2.1.1 命名类型（named type）与未...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值