丢失更新会发生在 PostgreSQL 的读提交隔离级别吗？

Question

我在 PostgreSQL 中有如下查询：

UPDATE 
     queue 
SET 
  queue.status   = 'PROCESSING' 
WHERE 
    queue.status   = 'WAITING' AND
    queue.id       = (SELECT id FROM queue WHERE STATUS = 'WAITING' LIMIT 1 )
RETURNING 
        queue.id

许多工作人员试图一次处理一项工作（这就是为什么我有限制为 1 的子查询）。在此更新之后，每个工作人员都会获取有关 id 的信息并处理工作，但有时他们会获取相同的工作并处理两次或更多次。隔离级别为已提交读。

我的问题是我如何保证一件作品会被处理一次？我知道那里有很多帖子，但我可以说我已经尝试了其中的大部分但没有帮助（）；

• 我尝试了 SELECT FOR UPDATE，但它导致了死锁的情况。
• 我试过 pg_try_advisory_xact_lock，但它导致 out of shared memory
• 我尝试将AND pg_try_advisory_xact_lock(queue.id) 添加到外部查询的 WHERE 子句中，但是... [?]

任何帮助将不胜感激。

Answer 1

在您描述的情况下不会发生更新丢失，但也不会正常工作。

在您上面给出的示例中会发生什么，假设（例如）10 个工作人员同时启动，所有 10 个工作人员都将执行子查询并获得相同的 ID。他们都将尝试锁定该 ID。其中一个会成功；其他人将阻止第一个锁。一旦第一个后端提交或回滚，其他 9 个后端将争夺锁。将得到它，重新检查 WHERE 子句，发现 queue.status 测试不再匹配，不修改任何行就返回。其他 8 个查询也会发生同样的情况。因此，您使用 10 个查询来完成一个查询的工作。

如果您未能明确检查 UPDATE 结果并看到零行已更新，您可能会认为您丢失了更新，但事实并非如此。您的应用程序中只是由于对执行顺序和隔离规则的误解而导致了并发错误。真正发生的事情是，您正在有效地序列化您的后端，以便一次只有一个实际取得进展。

PostgreSQL 可以避免让它们都获得相同的队列项 ID 的唯一方法是对它们进行序列化，因此在查询 #1 完成之前它不会开始执行查询 #2。如果你愿意，你可以通过LOCKing 队列表来做到这一点......但同样，你也可以只拥有一个工人。

您无法通过咨询锁解决此问题，无论如何也不容易。使用非阻塞锁定尝试迭代队列直到获得第一个可锁定项之前的黑客攻击会起作用，但会很慢而且很笨拙。

您正在尝试使用 RDBMS 实现工作队列。这不会很好地工作。它会很慢，会很痛苦，而且既正确又快速将非常非常困难。不要自己滚。相反，使用完善的、经过良好测试的系统来进行可靠的任务排队。看看 RabbitMQ、ZeroMQ、Apache ActiveMQ、Celery 等。还有PGQ from Skytools，一个基于 PostgreSQL 的解决方案。

相关：

• In PostgreSQL, do multiple UPDATES to different rows in the same table having a locking conflict?
• Can multiple threads cause duplicate updates on constrained set?
• Why do we need message brokers like rabbitmq over a database like postgres?

Answer 2

SKIP LOCKED 可用于在 PostgreSql 中实现队列。 see