【问题标题】:Maintain integrity on concurrent updates of the same row保持同一行的并发更新的完整性
【发布时间】:2020-06-05 11:42:12
【问题描述】:

在以下代码 sn-p 中,我尝试在 2 个不同线程中的 2 个不同事务中查找、删除和创建相同的项目。

在线程 1 中,我创建事务 1,找到该项目并将其删除。

完成后,我允许线程 2 创建事务 2,并尝试查找项目。 Find() 方法在这里阻塞,因为我使用选项 FOR UPDATE

回到线程 1,重新创建项目并提交事务 1,这允许线程 2 中的 Find() 完成。以下是那里出现的问题:

如果我使用隔离级别“ReadCommitted”,我会收到一个未找到的错误 - 这对我来说毫无意义,因为我认为 ReadCommitted 事务可以看到其他人应用的更新。

如果我使用隔离级别“Serializable”,我会收到错误:pq: could not serialize access due to concurrent update

为什么我会看到这种行为?我认为在第二次 find 解除阻塞后,它应该为我提供最新的行。

我怎样才能使当一行正在被修改时,任何其他读取都将锁定,并在其他线程中完成后解锁返回最新数据?

db, err := gorm.Open("postgres", "host=localHost port=5432 user=postgres dbname=test-rm password=postgres sslmode=disable")
if err != nil { panic("failed to connect database") }
db.SingularTable(true)
db.DropTableIfExists(&Product{})
db.AutoMigrate(&Product{})

db.Create(&Product{Code: "A", Price: 1000})
// SQL: INSERT  INTO "product" ("code","price") VALUES ('A',1000) RETURNING "products"."id"

txOpt := &sql.TxOptions{Isolation: sql.LevelSerializable}

doneTrans1 := make(chan struct{})

go func(){
    item1 := &Product{}

    tx1 := db.BeginTx(context.Background(), txOpt)

    err = tx1.Set("gorm:query_option", "FOR UPDATE").Find(item1, "code = ?", "A").Error
    // SQL: SELECT * FROM "product"  WHERE (code = 'A') FOR UPDATE

    item1.Price = 3000

    err = tx1.Delete(item1).Error
    // SQL: DELETE FROM "product"  WHERE "product"."id" = 1

    doneTrans1<-struct{}{}
    time.Sleep(time.Second * 3)

    err = tx1.Create(item1).Error
    // SQL: INSERT  INTO "product" ("id","code","price") VALUES (1,'A',3000) RETURNING "product"."id"

    tx1.Commit()
}()

// Ensure other trans work started
<-doneTrans1
time.Sleep(time.Second * 2)

item2 := &Product{}

tx2 := db.BeginTx(context.Background(), txOpt)

err = tx2.Set("gorm:query_option", "FOR UPDATE").Find(item2, "code = ?", "A").Error
// SQL: SELECT * FROM "product"  WHERE (code = 'A') FOR UPDATE
// ERROR occurs here

item2.Price = 5000
err = tx2.Delete(item2).Error
err = tx2.Create(item2).Error
tx2.Commit()
time.Sleep(time.Second * 5)

【问题讨论】:

  • 与您的问题无关,但您没有使用线程。你正在使用 goroutines。 Go 根本不允许你访问线程。

标签: postgresql go transactions go-gorm transaction-isolation


【解决方案1】:

要回答这个问题,我认为最好消除 goroutine 的复杂性(事实上,完全可以)并专注于 SQL。以下是 SQL 语句的运行顺序(我忽略了错误发生后的所有内容,因为这几乎无关紧要,并且执行顺序变得复杂/可变!)。

在主程序中

INSERT  INTO "product" ("code","price") VALUES ('A',1000) RETURNING "products"."id"

在 GoRoutine 中

BEGIN TX1
SELECT * FROM "product"  WHERE (code = 'A') FOR UPDATE
DELETE FROM "product"  WHERE "product"."id" = 1

在主程序中

BEGIN TX2
SELECT * FROM "product"  WHERE (code = 'A') FOR UPDATE -- ERROR occurs here

回答你的问题。

问题 1

如果我使用隔离级别“ReadCommitted”,我会收到一个未找到的错误 - 这对我来说毫无意义,因为我认为 ReadCommitted transaction 可以看到其他人应用的更新。

来自Read Committed Isolation Level 的文档:

UPDATE、DELETE、SELECT FOR UPDATE 和 SELECT FOR SHARE 命令 在搜索目标行方面的行为与 SELECT 相同:它们 只会找到在命令开始时提交的目标行 时间。但是,这样的目标行可能已经更新(或 被另一个并发事务删除或锁定) 成立。在这种情况下,可能的更新程序将等待第一个 更新事务以提交或回滚(如果它仍在 进步)。如果第一个更新程序回滚,那么它的效果是 否定,第二个更新程序可以继续更新 最初发现行。如果第一个更新者提交,第二个更新者 如果第一个更新程序删除了该行,将忽略该行,否则它将 尝试将其操作应用于行的更新版本。

所以 TX2 中的 SELECT * FROM "product" WHERE (code = 'A') FOR UPDATE 将等待 TX1 完成。此时 TX1 已删除产品 A,因此该行被忽略并且不返回任何结果。现在我知道 TX1 也重新创建了产品 A,但请记住“一个 SELECT 查询(没有 FOR UPDATE/SHARE 子句)只看到查询开始之前提交的数据;”并且由于选择在 TX1 重新创建记录之前开始,它将不会被看到。

问题 2

如果我使用隔离级别“Serializable”,我会收到错误:pq: could 由于并发更新,未序列化访问。

来自Repeatable Read Isolation Level 的文档(Serializable 是更高级别,因此这些规则以及一些更严格的规则适用):

UPDATE、DELETE、SELECT FOR UPDATE 和 SELECT FOR SHARE 命令 在搜索目标行方面的行为与 SELECT 相同:它们 只会找到在事务中提交的目标行 开始时间。但是,这样的目标行可能已经更新 (或删除或锁定)由另一个并发事务的时间 找到了。在这种情况下,可重复读事务将等待 第一个更新事务提交或回滚(如果是 仍在进行中)。如果第一个更新程序回滚,那么它的影响 被否定并且可重复读取事务可以继续 更新最初找到的行。但是如果第一个更新者提交 (实际上更新或删除了该行,而不仅仅是锁定它)然后 可重复读取事务将随消息一起回滚

在您的代码中,TX1 更新产品 A,这意味着 TX2 中的查询将延迟到 TX1 提交,届时它将因错误而中止(如果 TX1 回滚则它将继续)。

如何进行第二次更新?*

维护事务完整性是一个难题,PostgreSQL 中的功能是一些非常聪明的人大量工作的结果。如果您发现自己在与数据库作斗争,最好退后一步,考虑是否需要改变方法(或者您认为问题是否确实存在)。

在您的示例中,您有两个删除和重新创建同一记录的例程;我无法预见您希望两笔交易都进行的情况。在一个有可能的真实系统中,您不会仔细安排计时器来确保一个事务首先开始。这意味着事务完成后数据库的状态将取决于哪个先到达SELECT * FROM "product" WHERE (code = 'A') FOR UPDATE。所以实际上,如果失败并不重要(因为无论如何结果都是随机的);它实际上是一个更好的结果,因为您可以建议用户(谁可以检查记录并在需要时重新运行任务)。

因此,在阅读本文的其余部分之前,我建议您考虑一下这是否是一个问题(我没有关于您要完成的工作的背景,因此很难发表评论)。

如果您真的想确保更新继续进行,您有几个选择:

  • 如果使用“Serializable”,您需要检测失败并重试事务(如果这是业务逻辑要求的话)
  • 如果使用“已提交读”,则将 DELETE/INSERT 替换为 UPDATE(在这种情况下,PostgreSQL 将在释放第一个事务锁时重新评估 WHERE 子句)。

但是我觉得更好的方法是消除其中的大部分并尝试在一个步骤中执行这样的更新(这可能意味着绕过 ORM)。如果您想最大限度地减少此类问题的可能性,那么最大限度地减少锁的数量/持续时间很重要,并且在单个步骤中执行操作有很大帮助。对于复杂的操作,使用存储过程可以加快速度,但与其他同时运行的操作发生冲突的可能性仍然(减少)。

您可能还想查看Optimistic Locking,因为在某些情况下这更有意义(例如,您在哪里阅读信息,将其显示给用户并等待更改,但与此同时另一个用户可能已经进行了更改) .

【讨论】:

  • 感谢您如此详细的回复!
  • 您知道是否有任何方法可以使 TX2 中的 SELECT 阻塞直到 TX1 被提交,但让它 SELECT 新信息?
  • 请看我更新的答案。请注意,其中大部分是假设性的,因为我不知道您要解决的现实问题是什么(并且看不到您真的希望两个交易都进行的情况 - 这可能是因为问题缺乏上下文)。
【解决方案2】:

也许我理解错了 - 我以前没有使用过 gorm。 但是,从您的查询 cmets 中,您的两个 goroutine 中的两个事务都有一个“SELECT .. FOR UPDATE”并且它们并行运行。在尝试“SELECT.. FOR UPDATE”相同的行之前,您的主 goroutine 不会等待在您的第二个 goroutine 中启动的事务提交。

根据您的解释,您可能错误地将“FOR UPDATE”包含在第二个 goroutine 中。

或者您可以在第二个 goroutine 中使用 sync.Mutex 锁并在提交后释放它。而 main goroutine 等待获取锁,然后才执行它的查询。

【讨论】:

  • 这只是为了展示我遇到的问题,以及我尝试修复它的结果。实际上,两个事务中的代码是相同的。
  • 在主程序中,SELECT... FOR UPDATE 确实会阻塞,直到第一个事务完成,但它确实是未找到的 eer 或序列化错误
  • from pq documentationWithin a REPEATABLE READ or SERIALIZABLE transaction, however, an error will be thrown if a row to be locked has changed since the transaction started
  • 至于“ReadCommited”,我相信它使用您提供的代码可以正确执行。当您的主要 go-routine 尝试访问该行时,它已被您的显式 go-routine 删除,并且您确实看到了更新
  • 但它也被重新创建,与旧的 code 相同,当它被提交时。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2010-09-26
  • 1970-01-01
  • 2013-03-26
  • 1970-01-01
  • 1970-01-01
  • 2013-12-22
  • 2010-09-28
相关资源
最近更新 更多