ActiveRecords#update_countersを使用して競合状態を防止する

競合状態を防ぐためのいくつかのオプションがありますが、それらのほとんどすべては、常に1つのエンティティのみがデータを変更していることを確認するという単一のアイデアを中心に展開しています。

オプション1：ミューテックス

最も単純なオプションは、一般にミューテックスとして知られている「相互排他ロック」です。ミューテックスは、キーが1つしかないロックと考えることができます。 1つのスレッドがキーを保持している場合、ミューテックスにあるものは何でも実行できます。他のすべてのスレッドは、キーを保持できるようになるまで待機する必要があります。

サンプルコードにミューテックスを適用するには、次のようにします。

class MutexTransaction
  def self.run
    account = Account.find(1)
    account.update!(balance: 0)

    mutex = Mutex.new

    threads = []
    4.times do
      threads << Thread.new do
        mutex.lock
        balance = account.reload.balance
        account.update!(balance: balance + 100)
        mutex.unlock

        mutex.lock
        balance = account.reload.balance
        account.update!(balance: balance - 100)
        mutex.unlock
      end
    end

    threads.map(&:join)

    account.reload.balance
  end
end

ここでは、accountの読み取りと書き込みを行うたびに 、最初にmutex.lockを呼び出します 、完了したら、mutex.unlockを呼び出します。 他のスレッドが回転できるようにします。 mutex.lockを呼び出すだけです。 ブロックの開始時とmutex.unlock 最後に;ただし、これはスレッドが同時に実行されなくなったことを意味し、そもそもスレッドを使用する理由をいくらか否定します。パフォーマンスのために、コードをmutex内に保持することをお勧めします スレッドが可能な限り多くのコードを並行して実行できるようにするため、可能な限り小さくします。

.lockを使用しました および.unlock ここではわかりやすくするために、RubyのMutex クラスは素晴らしいsynchronizeを提供します ブロックを取得してこれを処理するメソッドなので、次のようにすることができます。

mutex.synchronize do
  balance = ...
  ...
end

RubyのMutexは必要なことを実行しますが、ご想像のとおり、Railsアプリケーションでは特定のデータベース行をロックする必要があるのはかなり一般的であり、ActiveRecordがこのシナリオをカバーしています。

オプション2：ActiveRecordロック

ActiveRecordはいくつかの異なるロックメカニズムを提供しますが、ここではそれらすべてについて深く掘り下げることはしません。私たちの目的では、lock!を使用するだけです。 更新する行をロックするには：

class LockedTransaction
  def self.run
    account = Account.find(1)
    account.update!(balance: 0)

    threads = []
    4.times do
      threads << Thread.new do
        Account.transaction do
          account = account.reload
          account.lock!
          account.update!(balance: account.balance + 100)
        end

        Account.transaction do
          account = account.reload
          account.lock!
          account.update!(balance: account.balance - 100)
        end
      end
    end

    threads.map(&:join)

    account.reload.balance
  end
end

Mutexは特定のスレッドのコードのセクションを「ロック」しますが、lock! 特定のデータベース行をロックします。これは、同じコードが複数のアカウントで並行して実行できることを意味します（たとえば、一連のバックグラウンドジョブで）。同じレコードにアクセスする必要があるスレッドのみが待機する必要があります。ActiveRecordは便利な#with_lockも提供します。 トランザクションを実行して一度にロックできるメソッド。したがって、上記の更新は次のようにもう少し簡潔に記述できます。

account = account.reload
account.with_lock do
  account.update!(account.balance + 100)
end
...

ソリューション3：アトミックメソッド

「アトミック」メソッド（または関数）は、実行の途中で停止することはできません。たとえば、一般的な+= Rubyでの操作はではありません 単一の操作のように見えますが、アトミック：

value += 10

# equivalent to:
value = value + 10

# Or even more verbose:
temp_value = value + 10
value = temp_value

スレッドがvalue + 10を計算する間に突然「スリープ」した場合 であり、結果をvalueに書き戻します 、それからそれは競合状態の可能性を開きます。ただし、Rubyがこの操作中にスレッドのスリープを許可しなかったと想像してみましょう。この操作中にスレッドがスリープしない（たとえば、コンピューターが実行を別のスレッドに切り替えることはない）と確実に言える場合は、「不可分」操作と見なすことができます。

一部の言語には、まさにこの種のスレッドセーフのためのアトミックバージョンのプリミティブ値があります（AtomicIntegerやAtomicFloatなど）。ただし、これは、Rails開発者として利用できる「アトミック」操作がいくつかないことを意味するものではありません。例として、ActiveRecordのupdate_counters メソッド。

これは、カウンターキャッシュを最新の状態に保つことを目的としていますが、アプリケーションでの使用を妨げるものは何もありません。カウンターキャッシュの詳細については、キャッシュに関する以前の記事をご覧ください。

この方法の使用は非常に簡単です：

class CounterTransaction
  def self.run
    account = Account.find(1)
    account.update!(balance: 0)

    threads = []
    4.times do
      threads << Thread.new do
        Account.update_counters(account.id, balance: 100)

        Account.update_counters(account.id, balance: -100)
      end
    end

    threads.map(&:join)

    account.reload.balance
  end
end

ミューテックスもロックもありません。2行のRubyだけです。 update_counters 最初の引数としてレコードIDを取り、次に変更する列を指定します（balance: ）とそれを変更する量（100 または-100 ）。これが機能する理由は、読み取り-更新-書き込みサイクルがデータベースで1回のSQL呼び出しで発生するためです。これは、Rubyスレッドが操作を中断できないことを意味します。スリープ状態であっても、データベースが実際の計算を行っているので問題ありません。

生成される実際のSQLは次のようになります（少なくとも私のマシンのpostgresでは）：

Account Update All (1.7ms)  UPDATE "accounts" SET "balance" = COALESCE("balance", 0) + $1 WHERE "accounts"."id" = $2  [["balance", "100.0"], ["id", 1]]

この方法でも、計算がデータベースで完全に行われるため、パフォーマンスが大幅に向上しますが、これは当然のことです。 reloadする必要はありません 最新の値を取得するためのレコード。ただし、この速度には代償が伴います。これは生のSQLで行っているため、Railsモデルをバイパスしています。つまり、検証やコールバックは実行されません（つまり、updated_atに変更はありません。 タイムスタンプ）。