postgresql - Postgres : Optimising concurrent same row updates

Question

问题

我正在使用 PostgreSQL v10 + golang，我认为这是一个非常常见的 SQL 问题:

• 我有一个“计数器”表，它有一个 current_value 和一个 max_value 整数列。
• 严格来说，一旦 current_value >= max_value，我想放弃请求。
• 我有几个 Kubernetes pod，每个 API 调用可能会将“计数器”表中同一行(在最坏情况下)的current_value 增加 1(可以被认为是分布式主机对同一数据库的并发更新)。

在我当前和天真的实现中，对同一行的多个更新自然会相互阻塞(如果重要的话，隔离级别是“已提交读”)。在最坏的情况下，我每秒有大约 10 多个请求会更新同一行。这会造成瓶颈并损害性能，这是我无法承受的。

---

可能的解决方案

我想了几个办法来解决这个问题，但它们都牺牲了完整性或性能。对于这个看似常见的问题，唯一保留两者的方法听起来不太干净:

只要计数器 current_value 与 max_value (delta > 100) 在相对安全的距离内，就将更新请求发送到每秒刷新一次的 channel ，或者所以由一个 worker 聚合更新并立即请求它们。否则(delta <= 100)，在事务的上下文中进行更新(并遇到瓶颈，但对于少数情况)。这将加快更新请求的速度，直到几乎达到限制，从而有效地解决瓶颈。

---

这可能会解决我的问题。但是，我忍不住认为有更好的方法来解决这个问题。

我没有在网上找到很好的解决方案，即使我的启发式方法可行，但感觉不干净且缺乏完整性。

非常欢迎创造性的解决方案!

---

编辑:

感谢@laurenz-albe 的建议，我尝试缩短行被锁定的 UPDATE 与事务的 COMMIT 之间的持续时间。将所有更新推送到事务的末尾似乎已经成功了。现在我每秒可以处理超过 100 个请求并保持完整性!

Answer 1

每秒 10 个并发更新少得离谱。只需确保交易尽可能短，这不会有问题。

您最大的问题将是 VACUUM，因为大量更新是 PostgreSQL 最糟糕的工作负载。确保您创建的表的 fillfactor 为 70 左右，并且 current_value 未索引，以便您获得热更新。