PostgreSQL行读取锁

猴王声辉

假设我有一张名为取款的表（id，金额，user_id，状态）。
每当我开始提款时，流程如下：
根据收到的金额之和，验证用户是否有足够的余额(-取款金额之和计算)
插入行，其金额为user_id，status =``结束’‘。
通过gRPC等待响应
如果我们收到肯定的答复，请立即更新状态为“已完成”的行；如果提款失败，则删除该条目。然而，我在这个过程中存在并发问题。假设用户在50 ms两次全额提款请求在差异内发出:
请求1
用户有足够的余额
创建提款(余额= 0）
更新提款状态请求2(约50毫秒后)
用户有足够的余额（这是不正确的，尚未存储其他插入内容）
创建提款(余额=负）
更新提款状态我们现在正在使用它redis将提款锁定在特定用户(如提款x
ms以内)，为了避免这种情况，但这不是最可靠的解决方案。目前，我们正在为企业开发当前的解决方案API在此过程中，我们将阻止可能同时提出的提款请求。是否有任何方法可以锁定并确保随后的插入查询Withdrawals表的user_id等待？

解决方案:
                                                            这是事务隔离的属性。关于它的文章很多，我强烈建议你在设计数据密集型应用程序中总结一下。我发现加深我个人理解的最有用的描述。
默认的postgres级别是READ COMMITTED，即使它们应该是相关的，它也允许这些并发事务中的每一个都具有相似的含义。
解决这个问题的一种方法是将每一件事标记为 SERIALIZABLE”一致性。
SERIALIZABLE当前事务的所有句子只能看到在执行第一个查询或数据修改句子之前提交的行。如果并发可序列化事务之间的读写模式不可能导致任何串行(一次)执行，其中一个将回滚并出现serialization_failure错误。
这应该以可用性为代价来提高应用程序的正确性，即在这种情况下，第二笔交易将不允许修改记录并被拒绝，这将需要重新测试。POC或者低流量应用程序，这通常是完全可以接受的第一步，因为你可以立即确保正确性。
同样，在上面引用的书中，我认为还有另一本书ATM句柄可用性示例。考虑到这种竞争，如果用户无法连接到集中银行，但用户限制最大提款金额，以最小化爆炸半径，用户将透支！
另一种解决这个问题的系统结构方法是使事务脱机并异步，以便将每个用户呼叫的事务发布到队列中，然后让队列的单个用户自然避免任何竞争。这里的相似的，只有一个员工可以提供固定的吞吐量，但这确实有助于解决当前的正确性：P
锁定跨机器(例如postgres /
grpc中使用redis）它被称为分布式锁，关于它有很多内容https://martin.kleppmann.com/2016/02/08/how-
to-do-distributed-locking.html

PostgreSQL行读取锁

猴王声辉 LV1