我有一个简单的模型，Payments，它有两个字段amount 和running_balance。当一个新的payment记录被创建时，我们寻找它之前支付的running_balance，比如last_running_balance并保存last_running_balance+amount 作为当前支付的running_balance。

以下是我们实现Payments 模型的三个失败尝试。为简单起见，假设之前的付款始终存在，并且 id 随着付款的创建而增加。

尝试 1:

class Payments < ActiveRecord::Base
    before_validation :calculate_running_balance
    private
    def calculate_running_balance
        p = Payment.last
        self.running_balance = p.running_balance + amount
    end
end

尝试 2:

class Payments < ActiveRecord::Base
    after_create :calculate_running_balance
    private
    def calculate_running_balance
        p = Payment.where("id < ?", id).last
        update!(running_balance: p.running_balance + amount)
    end
end

尝试 3:

class Payments < ActiveRecord::Base
    after_commit :calculate_running_balance
    private
    def calculate_running_balance
        p = Payment.where("id < ?", id).last
        update!(running_balance: p.running_balance + amount)
    end
end

这些实现可能会导致系统出现竞争条件，因为我们正在使用 sidekiq 在后台创建支付。假设最后一笔付款是 payment 1。当同时创建两个新付款时，比如 payment 2 和 payment 3，它们的 running_balance 可能会根据运行余额计算payment 1 因为当 payment 3 正在计算其运行余额时可能会出现这种情况 payment 2 尚未保存到数据库中。

特别是，我对避免运行条件的修复感兴趣。我也热衷于寻找实现类似支付系统的其他 Rails 应用程序。

最佳答案

更新:这是第一个版本，对于实际工作的方法，请参见下文:

如果您在使用 pessimistic locking 计算最后一笔余额时锁定最后一笔付款，您可以摆脱竞争条件.为此，您始终需要使用交易 block 包装创建付款。

class Payments < ActiveRecord::Base
  before_create :calculate_running_balance

  private
  def calculate_running_balance
    last_payment = Payment.lock.last
    self.running_balance = last_payment.running_balance + amount
  end
end

# then, creating a payment must always be done in transaction
Payment.transaction do
  Payment.create!(amount: 100)
end

获取最后一笔 Payment 的第一个查询也会在包装它的事务期间锁定记录(并延迟进一步查询)，即直到事务完全提交并且创建的新记录。 如果另一个查询同时也试图读取锁定的最后一笔付款，它将不得不等到第一笔交易完成。因此，如果您在创建付款时在 sidekiq 中使用交易，您应该是安全的。

有关更多信息，请参阅上面链接的指南。

更新:没那么容易，这种方法会导致死锁

经过一些广泛的测试，问题似乎更复杂了。如果我们只锁定“最后”支付记录(Rails 将其转换为 SELECT * FROM payments ORDER BY id DESC LIMIT 1)，那么我们可能会遇到死锁。

这里我给出了导致死锁的测试，实际工作的方法在下面。

在下面的所有测试中，我都在 MySQL 中使用一个简单的 InnoDB 表。我创建了最简单的 payments 表，只在第一行添加了 amount 列，并在 Rails 中添加了相应的模型，如下所示:

# sql console
create table payments(id integer primary key auto_increment, amount integer) engine=InnoDB;
insert into payments(amount) values (100);

# app/models/payments.rb
class Payment < ActiveRecord::Base
end

现在，让我们打开两个 Rails 控制台，开始一个长时间运行的事务，在第一个控制台 session 中使用最后记录锁定和新行插入，在第二个控制台 session 中使用另一个最后行锁定:

# rails console 1
>> Payment.transaction { p = Payment.lock.last; sleep(10); Payment.create!(amount: (p.amount + 1));  }
D, [2016-03-11T21:26:36.049822 #5313] DEBUG -- :    (0.2ms)  BEGIN
D, [2016-03-11T21:26:36.051103 #5313] DEBUG -- :   Payment Load (0.4ms)  SELECT  `payments`.* FROM `payments`  ORDER BY `payments`.`id` DESC LIMIT 1 FOR UPDATE
D, [2016-03-11T21:26:46.053693 #5313] DEBUG -- :   SQL (1.0ms)  INSERT INTO `payments` (`amount`) VALUES (101)
D, [2016-03-11T21:26:46.054275 #5313] DEBUG -- :    (0.1ms)  ROLLBACK
ActiveRecord::StatementInvalid: Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction: INSERT INTO `payments` (`amount`) VALUES (101)

# meanwhile in rails console 2
>> Payment.transaction { p = Payment.lock.last; }
D, [2016-03-11T21:26:37.483526 #8083] DEBUG -- :    (0.1ms)  BEGIN
D, [2016-03-11T21:26:46.053303 #8083] DEBUG -- :   Payment Load (8569.0ms)  SELECT  `payments`.* FROM `payments`  ORDER BY `payments`.`id` DESC LIMIT 1 FOR UPDATE
D, [2016-03-11T21:26:46.053887 #8083] DEBUG -- :    (0.1ms)  COMMIT
=> #<Payment id: 1, amount: 100>

第一个事务以死锁结束。一种解决方案是使用此答案开头的代码，但在发生死锁时重试整个事务。

重试死锁事务的可能解决方案:(未测试)

利用@M.G.Palmer 在this SO answer 中重试锁定错误的方法:

retry_lock_error do
  Payment.transaction 
    Payment.create!(amount: 100)
  end
end

当发生死锁时，事务会重试，即找到并使用最新的最后一条记录。

带测试的工作解决方案

我的另一种方法 came across就是锁定表的所有记录。这可以通过锁定 COUNT(*) 子句来完成，并且它似乎始终如一地工作:

# rails console 1
>> Payment.transaction { Payment.lock.count; p = Payment.last; sleep(10); Payment.create!(amount: (p.amount + 1));}
D, [2016-03-11T23:36:14.989114 #5313] DEBUG -- :    (0.3ms)  BEGIN
D, [2016-03-11T23:36:14.990391 #5313] DEBUG -- :    (0.4ms)  SELECT COUNT(*) FROM `payments` FOR UPDATE
D, [2016-03-11T23:36:14.991500 #5313] DEBUG -- :   Payment Load (0.3ms)  SELECT  `payments`.* FROM `payments`  ORDER BY `payments`.`id` DESC LIMIT 1
D, [2016-03-11T23:36:24.993285 #5313] DEBUG -- :   SQL (0.6ms)  INSERT INTO `payments` (`amount`) VALUES (101)
D, [2016-03-11T23:36:24.996483 #5313] DEBUG -- :    (2.8ms)  COMMIT
=> #<Payment id: 2, amount: 101>

# meanwhile in rails console 2
>> Payment.transaction { Payment.lock.count; p = Payment.last; Payment.create!(amount: (p.amount + 1));}
D, [2016-03-11T23:36:16.271053 #8083] DEBUG -- :    (0.1ms)  BEGIN
D, [2016-03-11T23:36:24.993933 #8083] DEBUG -- :    (8722.4ms)  SELECT COUNT(*) FROM `payments` FOR UPDATE
D, [2016-03-11T23:36:24.994802 #8083] DEBUG -- :   Payment Load (0.2ms)  SELECT  `payments`.* FROM `payments`  ORDER BY `payments`.`id` DESC LIMIT 1
D, [2016-03-11T23:36:24.995712 #8083] DEBUG -- :   SQL (0.2ms)  INSERT INTO `payments` (`amount`) VALUES (102)
D, [2016-03-11T23:36:25.000668 #8083] DEBUG -- :    (4.3ms)  COMMIT
=> #<Payment id: 3, amount: 102>

通过查看时间戳，您可以看到第二个事务等待第一个事务完成并且第二个插入已经“知道”第一个事务。

所以我提出的最终解决方案如下:

class Payments < ActiveRecord::Base
  before_create :calculate_running_balance

  private
  def calculate_running_balance
    Payment.lock.count # lock all rows by pessimistic locking
    last_payment = Payment.last # now we can freely select the last record
    self.running_balance = last_payment.running_balance + amount
  end
end

# then, creating a payment must always be done in transaction
Payment.transaction do
  Payment.create!(amount: 100)
end

关于mysql - 如何避免记录付款和运行余额的 Rails 模型中的竞争条件？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35934068/