Как избежать состояния гонки в модели рельсов, которая записывает платежи и текущий баланс?

Обновление: это первая версия, о реально работающем подходе см. ниже:

Вы можете избавиться от условий гонки, если заблокируете последний платеж при расчете последнего баланса, используя пессимистическая блокировка. Чтобы это работало, вам всегда нужно обернуть создание платежей блоком транзакции.

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), мы можем попасть в тупик.

Здесь я представляю тест, который приводит к тупиковой ситуации, фактически рабочий подход ниже.

Во всех приведенных ниже тестах я работаю с простой таблицей InnoDB в MySQL. Я создал простейшую 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, запустим длительную транзакцию с блокировкой последней записи и вставкой новой строки в первую и еще одну блокировку последней строки во втором сеансе консоли:

# 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 в этом SO-ответе:

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

При возникновении тупика транзакция повторяется, т. Е. Обнаруживается и используется последняя последняя запись.

Рабочее решение с тестом

Другой подход, с которым я столкнулся - заблокировать все записи таблицы. Это можно сделать, заблокировав предложение 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