关于多线程：Postgres中的Atomic UPDATE .. SELECT

concurrencymultithreadingpostgresqlrace-conditiontransaction-isolation

Atomic UPDATE .. SELECT in Postgres

我正在建立各种排队机制。有需要处理的数据行和状态标志。我正在使用update .. returning子句来管理它：

1
2
3
4

UPDATE stuff
SET computed = 'working'
WHERE id = (SELECT id FROM STUFF WHERE computed IS NULL LIMIT 1)
RETURNING *

嵌套的选择部分是否与更新锁相同，或者我是否有竞争条件？如果是这样，内部选择需要是select for update吗？

相关讨论

虽然Erwin的建议可能是获得正确行为的最简单方法(只要你在SQLSTATE 40001的情况下获得异常就重试你的事务)，按性质排队应用程序往往会更好地处理阻止有机会的请求他们在队列中转而不是使用PostgreSQL实现的SERIALIZABLE事务，这允许更高的并发性，并且对碰撞的可能性更加"乐观"。

在问题中的示例查询(在默认的READ COMMITTED事务隔离级别中)将允许两个(或更多)并发连接"声明"队列中的同一行。会发生什么是这样的：

T1启动并获得锁定UPDATE阶段中的行。
T2在执行时间内重叠T1并尝试更新该行。它阻止等待T1的COMMIT或ROLLBACK。
T1提交，已成功"声称"该行。
T2尝试更新行，发现T1已经拥有，查找该行的新版本，发现它仍然满足选择条件(只是id匹配)，并且还"声明"该行。

它可以被修改为正常工作(如果您使用的是PostgreSQL版本，它允许子查询中的FOR UPDATE子句)。只需将FOR UPDATE添加到选择id的子查询的末尾，这将发生：

T1启动，现在在选择id之前锁定行。
T2在执行时间内重叠T1并在尝试选择id时阻塞，等待T1的COMMIT或ROLLBACK。
T1提交，已成功"声称"该行。
当T2能够读取行以查看id时，它会看到它已被声明，因此它找到下一个可用的id。

在REPEATABLE READ或SERIALIZABLE事务隔离级别，写入冲突会引发错误，您可以捕获并确定基于SQLSTATE的序列化失败，然后重试。

如果您通常需要SERIALIZABLE事务但是想要避免在排队区域中重试，则可以通过使用建议锁来实现此目的。

相关讨论

将冗余WHERE子句AND computed IS NULL添加到外部UPDATE会使此特定查询正常运行吗？或者在T1将操作中途的所选行"无效"后，T2才会变空;
在READ COMMITTED中，它会阻止双重赋值，但在重叠事务的情况下，即使有其他行可用，也会返回空结果集。在更严格的隔离级别，它不会产生任何真正的差异，但无论如何可能是好的形式。
再次感谢。我设计了一个基于此的替代解决方案。
请注意，使用此策略的应用程序必须有一种方法可以发现某人声明某行，然后崩溃或无法完成工作。
@CraigRinger提出了一个很好的观点。在我需要做一些与此类似的事情的地方，我列出了一个列，用于标识谁已声明行和何时。这样可以清理废弃的索赔并对原因进行一些分析。
@kgrittn你能否让你的答案更清楚，并写出结果查询？你说，"只需将它添加到选择id的子查询"，我不知道"那个"是什么。代码比谈话更容易理解。谢谢！
@Nowaker，我重新编写而不是提供一个几乎与原版完全相同的例子 - 在我看来，人们会浪费太多时间来回看看差异是什么。主观，我知道，但这对我来说似乎更干净。
@kgrittn是否需要将语句包装在BEGIN ... COMMIT中以保存FOR UPDATE锁定？有一些报道说它不起作用：github.com/collectiveidea/delayed_job_active_record/pull/79
@jtomson，大多数锁在事务结束时发布并获取它们(例外情况是一些咨询锁)。如果没有BEGIN / COMMIT块(或使用其他语法或封闭函数的等效块)，每个语句都会创建自己的事务，该事务在语句完成时自动提交或回滚。
@kgrittn当你说，"在REPEATABLE READ或SERIALIZABLE事务隔离级别，写入冲突会引发错误"，你的意思是除非使用FOR UPDATE，否则会出现写冲突，对吧？
@Andy FOR UPDATE本身不会阻止序列化失败，但是如果你使用带有REPEATABLE READ隔离级别的FOR UPDATE SKIP LOCKED的Erwin示例(适用于9.5及更高版本)，那么在没有序列化失败的情况下，您可以获得所需的内容。如果更新没有ORDER BY子句并且包含LIMIT，那么有一些想法可以为SERIALIZABLE事务获得类似的性能，但这只是谈论。

如果您是唯一的用户，则查询应该没问题。特别是，查询本身(外部查询和子查询之间)没有竞争条件或死锁。我在这里引用手册：

However, a transaction never conflicts with itself.

对于同时使用，问题可能更复杂。使用SERIALIZABLE事务模式可以保证安全：

1
2
3
4
5
6

BEGIN ISOLATION LEVEL SERIALIZABLE;
UPDATE stuff
SET computed = 'working'
WHERE id = (SELECT id FROM stuff WHERE computed IS NULL LIMIT 1)
RETURNING *
COMMIT;

在这种情况下，您需要准备序列化失败并重试查询。

但我不完全确定这不是矫枉过正。我会要求@kgrittn停下来..他是并发和可序列化事务的专家。

他做到了。 :)

两全其美

以默认事务模式READ COMMITTED运行查询。

对于Postgres 9.5或更高版本，请使用FOR UPDATE SKIP LOCKED。看到：

Postgres UPDATE ... LIMIT 1

对于旧版本，在外部UPDATE中显式重新检查条件computed IS NULL：

1
2
3
4

UPDATE stuff
SET computed = 'working'
WHERE id = (SELECT id FROM stuff WHERE computed IS NULL LIMIT 1)
AND computed IS NULL;

正如@ kgrittn在他的回答评论中所建议的那样，这个查询可能在没有做任何事情的情况下变得空洞，在(不太可能的)情况下它与并发事务交织在一起。

因此，它将像事务模式SERIALIZABLE中的第一个变体一样工作，您必须重试 - 只是没有性能损失。

唯一的问题是：虽然冲突是不太可能的，因为机会之窗非常小，但它可能在重负荷下发生。你无法确定是否最后没有剩下的行。

如果这无关紧要(就像你的情况一样)，你就完成了。
如果确实如此，那么在获得空结果后，再使用显式锁定再启动一个查询。如果这个空了，你就完成了。如果没有，继续。
在plpgsql中它可能如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

LOOP
UPDATE stuff
SET computed = 'working'
WHERE id = (SELECT id FROM stuff WHERE computed IS NULL
LIMIT 1 FOR UPDATE SKIP LOCKED); -- pg 9.5+
-- WHERE id = (SELECT id FROM stuff WHERE computed IS NULL LIMIT 1)
-- AND computed IS NULL; -- pg 9.4-

CONTINUE WHEN FOUND; -- continue outside loop, may be a nested loop

UPDATE stuff
SET computed = 'working'
WHERE id = (SELECT id FROM stuff WHERE computed IS NULL
LIMIT 1 FOR UPDATE);

EXIT WHEN NOT FOUND; -- exit function (end)
END LOOP;

这应该会给你两全其美：性能和可靠性。

相关讨论