如何正确使用事务和锁来确保数据库完整性？

Question

我开发了一个在线预订系统。为了简化，假设用户可以预订多个项目，每个项目只能预订一次。物品首先被添加到购物车。

应用程序使用MySql / InnoDB数据库。根据MySql文档，默认隔离级别为Repeatable reads。

这是我到目前为止提出的结账程序：

1. 开始交易
2. 选择购物车中的商品（使用for update锁） 来自cart-item和items表的记录在此步骤中获取。
3. 检查项目是否未被其他人预订 基本上检查quantity > 0。它在实际应用中更复杂，因此我把它作为一个单独的步骤。
4. 更新项目，设置quantity = 0 还执行其他重要的数据库操作。
5. 付款（通过外部API，如PayPal或Stripe） 无需用户交互，因为可以在结账前收集付款细节。
6. 如果一切顺利，则提交事务或回滚
7. 继续使用非必要的逻辑 如果成功发送电子邮件等，重定向错误。

我不确定这是否足够。我担心是否：

1. 尝试同时预订同一项目的其他用户将被正确处理。他的交易T2会等到T1完成吗？
2. 使用PayPal或Stripe付款可能需要一些时间。这不会成为性能方面的问题吗？
3. 项目可用性将始终正确显示（项目应该可用，直到结帐成功）。这些只读选择应该使用shared lock吗？
4. MySql可能会自行回滚事务吗？通常更好的方法是自动重试或显示错误消息并让用户再试一次？
5. 我想如果我在SELECT ... FOR UPDATE桌上做items就够了。这样，双击和其他用户引起的请求都必须等到事务完成。他们会等，因为他们也使用FOR UPDATE。与此同时，香草SELECT将在交易前看到db的快照，但没有延迟，对吗？
6. 如果我在JOIN中使用SELECT ... FOR UPDATE，两个表中的记录都会被锁定吗？
7. 我对Willem Renzema回答的不存在的行部分的SELECT ... FOR UPDATE感到有点困惑。什么时候变得重要？你能举个例子吗？

以下是我读过的一些资源：How to deal with concurrent updates in databases?，MySQL: Transactions vs Locking Tables，Do database transactions prevent race conditions?，Isolation (database systems)，InnoDB Locking and Transaction Model，A beginner’s guide to database locking and the lost update phenomena。

重写了我原来的问题，使其更加通用。 添加了后续问题。

Answer 1

1. 开始交易
2. 选择购物车中的商品（用于更新锁定）

到目前为止，这至少可以防止用户在多个会话中进行结账（多次尝试签出同一张卡 - 很好地处理双击。）

3. 检查其他用户是否未预订项目

你怎么检查？使用标准的SELECT或SELECT ... FOR UPDATE？基于第5步，我猜你正在检查项目上的保留列，或类似的东西。

这里的问题是步骤2中的SELECT ... FOR UPDATE不会将FOR UPDATE锁应用于其他所有内容。它只适用于什么是SELECTed：cart-item表。根据名称，这将是每个购物车/用户的不同记录。这意味着其他交易不会被阻止继续进行。

4. 付款
5. 更新将其标记为已保留的项目
6. 如果一切顺利提交事务，否则回滚

根据上述情况，根据您提供的信息，如果您未在第3步使用SELECT ... FOR UPDATE，最终可能会有多人购买相同的商品。

Suggested Solution

1. 开始交易
2. SELECT ... FOR UPDATE cart-item表。

这将锁定双击运行。你在这里选择的应该是某种“购物车订购”栏目。如果这样做，第二个事务将在此处暂停并等待第一个事务完成，然后读取第一个保存到数据库的结果。

如果cart-item表已经订购，请务必在此处结束结帐流程。

3. SELECT ... FOR UPDATE您记录项目是否已被保留的表格。

这将锁定其他购物车/用户无法读取这些商品。

根据结果​​，如果未保留项目，请继续：

4. UPDATE ...在步骤3中的表格，将该项目标记为保留。你需要的任何其他INSERTs和UPDATEs。
5. 付款。如果付款服务显示付款不起作用，则发出回滚。
6. 记录付款，如果成功。
7. 提交交易

确保您不会在步骤5和7之间执行任何可能失败的操作（例如发送电子邮件），否则如果事务被回滚，您最终可能会在没有记录的情况下进行付款。

步骤3是确保两个（或更多）人不尝试订购相同物品的重要步骤。如果有两个人尝试，第二个人最终会在处理第一个网页时“挂起”。然后，当第一个完成时，第二个将读取“保留”列，并且您可以向用户返回某人已经购买该项目的消息。

Payment in transaction or not

这是主观的。通常，您希望尽快关闭事务，以避免多个人被锁定而无法立即与数据库交互。

但是，在这种情况下，您确实希望他们等待。这只是一个问题。

如果您选择在付款前提交交易，则需要在某个中间表中记录您的进度，运行付款，然后记录结果。请注意，如果付款失败，您必须手动撤消更新的商品预订记录。

SELECT ... FOR UPDATE on non-existent rows

如果你的表设计涉及在早期SELECT ... FOR UPDATE之前需要插入行，请注意警告：如果一行不存在，那么该事务不会导致其他事务等待，如果它们也SELECT ... FOR UPDATE相同的不存在的行。

因此，请确保始终通过在您知道存在的行上执行SELECT ... FOR UPDATE来序列化您的请求。然后你可以在可能存在或可能不存在的行上使用SELECT ... FOR UPDATE。 （不要试图在可能存在或可能不存在的行上执行SELECT，因为您将在事务开始时读取行的状态，而不是在您运行SELECT的那一刻。所以，SELECT ... FOR UPDATE在不存在的行上仍然需要做些什么才能获得最新的信息，只要知道它不会导致其他事务等待。）

Answer 2

1.试图同时预订同一项目的其他用户将被正确处理。他的交易T2会等到T1完成吗？

是。当活动事务使FOR UPDATE锁定记录时，其他使用任何锁定的事务中的语句（SELECT ... FOR UPDATE，SELECT ... LOCK IN SHARE MODE，UPDATE，DELETE）将被暂停，直到活动事务提交或超过“锁定等待超时”。

2.使用PayPal或Stripe付款可能需要一些时间。这不会成为性能方面的问题吗？

这不会是一个问题，因为这正是必要的。结帐交易应按顺序执行，即。后结账不应该在前完成之前开始。

3.项目可用性将始终正确显示（项目应该可用，直到结帐成功）。这些只读选择应该使用shared lock吗？

Repeatable reads隔离级别确保在提交事务之前，事务所做的更改不可见。因此，项目可用性将正确显示。在实际支付之前，什么都不会显示。不需要锁。

SELECT ... LOCK IN SHARE MODE会导致结账交易等到结束。这可能会减慢结账速度而不给予任何回报。

4. MySql可能自行回滚事务吗？通常更好的方法是自动重试或显示错误消息并让用户再试一次？

有可能的。当超过“锁定等待超时”或发生死锁时，可以回滚事务。在这种情况下，自动重试它是个好主意。 默认情况下，挂起的语句在50秒后失败。

如果我在SELECT ... FOR UPDATE桌上做items，我想它已经足够了。这样，双击和其他用户引起的请求都必须等到事务完成。他们会等，因为他们也使用FOR UPDATE。与此同时，香草SELECT将在交易前看到db的快照，但没有延迟，对吗？

是的，在SELECT ... FOR UPDATE桌上的items应该足够了。 是的，这些选择等待，因为FOR UPDATE是一个独占锁。 是的，简单的SELECT只会抓住交易开始前的价值，这将立即发生。

6.如果我在JOIN中使用SELECT ... FOR UPDATE，两个表中的记录是否会被锁定？

是的，SELECT ... FOR UPDATE，SELECT ... LOCK IN SHARE MODE，UPDATE，DELETE锁定所有读取记录，所以无论我们JOIN包括在内。见MySql Docs。

有趣的是（至少对我来说）在SQL语句处理过程中扫描的所有内容都会被锁定，无论它是否被选中。例如，WHERE id < 10将用id = 10锁定记录！

如果没有适合您的语句的索引，并且MySQL必须扫描整个表来处理该语句，则表的每一行都会被锁定，这反过来会阻止其他用户对表的所有插入。创建好的索引非常重要，这样您的查询就不会不必要地扫描很多行。