mysql - 乐观锁定用户信用管理

Question

我有一个中央数据库，用于处理多个服务器读取和写入的用户信用。该应用程序位于这些服务器之上，通过对每个请求执行以下操作来满足用户请求:

1. check if user has enough credit for the task by reading from db.2. perform the time consuming request3. deduct a credit from user account, save the new credit count back to db.

应用程序使用数据库的乐观锁定。所以可能会发生以下情况

1. request a comes in, see that user x has enough credit,2. request b comes in, see that user x has enough credit,3. a performs work4. a saves the new credit count back to db5. b performs work6. b tries to save the new credit count back to db, application gets an exception and fails to account for this credit deduction.

使用悲观锁定，应用程序需要显式锁定用户帐户以保证独占访问，但由于系统有许多并发请求，这会降低性能。
那么这个信用系统的新设计应该是怎样的呢？

Answer 1

这里有两个“锁定”机制可以避免使用 InnoDB 的锁定机制，原因有两个:

• 一个任务花费的时间比您在 InnoDB 的 BEGIN...COMMIT 中应该花费的时间长。
• 结束于与开始时不同的程序(或不同的网页)的任务。

计划 A。(假设竞争条件很少见，并且在这些罕见情况下，步骤 2 所浪费的时间是可以接受的。)

1. (相同)通过从数据库读取来检查用户是否有足够的信用来完成任务。
2. (same) 执行耗时的请求
3. (已添加)开始交易；
4. (added) 再次检查用户是否有足够的信用。 (ROLLABCK 如果没有则中止。)
5. (与旧的 #3 相同)从用户帐户中扣除信用，将新的信用计数保存回数据库。
6. (添加)提交；

START..COMMIT 是 InnoDB 事务的东西。如果争用条件导致“x”在第 4 步之前没有信用，您将ROLLBACK 并且不执行第 4 步和第 5 步。

B 计划。(这更复杂，但您可能更喜欢它。)

1. 有一个用于锁定的表Locks。它包含 user_id 和时间戳。
2. 开始交易；
3. 如果 user_id 在 Locks 中，则中止(ROLLBACK 并退出)。
4. INSERT INTO Locks Locks 中的 user_id 和 current_timestamp(从而“锁定”'x')。
5. 提交；
6. 执行处理(原始步骤 1、2、3)
7. DELETE FROM Locks WHERE user_id = 'x';(autocommit=1 在这里就足够了。)

一个潜在的问题:如果处理在第 6 步中终止，没有抽出时间释放锁，该用户将永远被锁在外面。 “解决方案”是定期检查 Locks 是否有任何“非常”旧的时间戳。如果找到任何内容，则假定处理已结束，并删除行。