在開發上會遇到 code 對 database 處理 concurrency 所帶來的問題，而這些問題隨著商業邏輯逐漸壯大會更容易遇到。

當兩個用戶從資料中判斷同一個數值且同時進行更新，在沒有並行控制的情況下，其更新結果依照兩個操作的執行順序與時機決定，那麼數據的完整性將會受到損害，尤其在處理貨幣及存貨時更要注意。

其關鍵點就是

2 個 process 同時運行，同時進入關鍵部分引發的錯誤

而 Race condition 帶來的資料錯誤，影響層面視商業邏輯，其結果可大可小

• 小
  • 今天要賣 10 本書，結果不小心超賣變成 12 本，少 2 本可以出貨，就看用戶能不能等或是退錢
• 大
  • 今天要取消訂單，歸還鎖定的餘額，結果退了 2 次，用戶餘額直接無中生有多出一筆錢，並且提領走人，造成商業上的真金白銀損失

我們需要確保一段程式碼可以同步運行，並保證這些非原子性的操作，包在同一個原子內。

這篇文章將會說明以 Rails 框架實作時以不同的角度解決、避免和測試 race condition，並同時建立 convention 避免複雜的商業邏輯

序

Rails 中避免 race condition 的最佳實踐(一) => 本篇

• Lock 的種類
  • 悲觀鎖
  • 樂觀鎖
• 悲觀鎖定的最佳實踐
  • 超過兩層請用 AR transaction + Lock
  • Lock first
  • 規範鎖定順序
  • 使用 Bang 語法

Rails 中避免 race condition 的最佳實踐(二)

• Testing race condition
  • Unit test with RSpec
  • Benchmarking tool
• Snapshot read & Current read
• Single Query
• 總結
• 參考來源

Lock 的種類

對於資源的競爭，為了確保其數據正確性，通常會上鎖

日常開發最常使用的兩種鎖定，分別為

• 樂觀鎖(Optimistic Locking)
• 悲觀鎖(Pessimistic Locking)

悲觀鎖

悲觀鎖如其名，每一次去拿數據時，都悲觀的認為一定會有人修改數據，因此對數據上鎖，讓自己在讀寫的過程中，別人如果要操作同一筆數據，只能等待釋放才能繼續

• 優點: 嚴謹
• 缺點: 會對數據寫入造成堵塞，降低吞吐量
• 適合場景: 資源爭用嚴重、可能是駭客的打點、要完全確保資料正確的地方

Rails 提供兩種作法分別為 lock! & with_lock

# lock! 必須在 transaction 內操作

Account.transaction do
  # select * from accounts where ...
  account1 = accounts.find(1)
  account2 = accounts.find(2)
  # select * from accounts where id=? for update
  account1.lock!
  account2.lock!
  account1.balance -= 100
  account1.save!
  account2.balance += 100
  account2.save!
end

# with_lock 的實作其實就是幫你在外面包一層 transaction
account = Account.first
account.with_lock do
  # This block is called within a transaction,
  # account is already locked.
  account.balance -= 100
  account.save!
end

這裡要注意的是 lock! 必須在 transaction 內，否則不會將資料鎖定，會變成只是在 database 裡面下 SELECT FOR UPDATE 的語法

而這個語法只在 autocommit 被禁用的情況下生效，最常見就是自己管理 transaction 的時候

可參考 MySQL 的說明

Locking reads are only possible when autocommit is disabled (either by beginning transaction with START TRANSACTION or by setting autocommit to 0.

樂觀鎖

以上述的悲觀鎖來說，出錯機率小，因為一旦鎖上了，其他的要求就會被迫堵塞，也會影響吞吐量，系統開銷會比較大

而樂觀鎖適合用於資源競爭不是這麼多的地方，實作方式屬於一種版本控制，在數據上插上欄位，每次更新時都檢查該欄位是否已經被變動，來決定更新是否成功

• 優點: 效能更好，不會堵塞資料
• 缺點: 相較悲觀鎖較不嚴謹，需要自行處理 retry
• 適合場景: 資源爭用不嚴重的地方

在 Rails 已經有提供這樣的設計，使用樂觀鎖之前需要給數據庫增加一個欄位 :lock_version，Rails 會自動識別這一欄位，在數據庫提交數據的時候自動更新。

如果提交更新，發現 lock_version 已經被其他人更新了，那麼更新會導致失敗，Rails 會丟出 ActiveRecord::StaleObjectError 的異常

通常用 retry 來解決

retry_times = 3

begin
  person.first_name = "Nic"
  person.save
rescue ActiveRecord::StaleObjectError => e
  retry_times -= 1
  if retry_times > 0
    retry
  else
    raise e
  end
rescue => e
  raise e
end

悲觀鎖定的最佳實踐

這裡探討的場景以最嚴謹的方式下處理複雜且不可出錯的商業邏輯，在商業真金白銀可能造成損害的前提下，暫時忽略效能及吞吐量問題

那麼在鎖的挑選上，勢必會選擇悲觀鎖定

不過在 Rails 裡面實作，要如何制定一套處理金錢、存貨時團隊能夠易懂好維護的 Coding style 就是這個段落要說明的

以下 ActiveRecord 簡稱為 AR

超過兩層請用 AR transaction + Lock

AR 中的 with_lock 相當好用，但請勿濫用，會造成程式更難以閱讀及理解

@user.with_lock do
  # Logic
end

這樣寫很方便確實很方便，因為 with_lock 自帶 transaction，適合用在單一 AR object 更新

但如果超過兩層以上會出現 nested hell，如果裡面又多一堆判斷，會讓人難以理解，更何況外面還包一層 begin rescue

看起來會像這樣

begin
  order.with_lock do
    coupon.with_lock do
      account.with_lock do

        if order.paid?
          # some change
        else
          # some change
        end
      end
    end
  end
rescue => error
 # handle error
end

這時候請使用 transaction + lock 的寫法

begin
  ActiveRecord::Base.transaction do
    # Lock first
    order.lock!
    coupon.lock!
    account.lock!

    if order.paid?
      # some change
    else
      # some change
    end
  end
rescue => error
 # handle error
end

Lock first

鎖定語法一律放置整個程式區塊的最上方，方便其他協作者一眼看出這個 trnasaction 鎖了什麼

  ActiveRecord::Base.transaction do
    # Lock first
    order.lock!
    coupon.lock!
    account.lock!

    # Logic
  end

規範鎖定順序

避免 deadlock 的其中一個部分，就是在團隊中制訂鎖定順序，當其架構為 microservice 時更容易遇到有可能不同的後端語言實作，這時候就更需要注意資源鎖定的部分

假設大家都在爭奪 Account，甚至有的場景是要先鎖 2 名用戶的 Account

那麼，可以這樣子規範

同時兩筆 Account 進入 SQL statement 時， user_id 較小的先行上鎖

這樣在不同實作下，資源爭奪的部分有了順序，就可以有效降低 deadlock 發生的機率

使用 Bang 語法

Transaction 任何變更請使用 ActiveRecord 自帶的 ! 語法

該語法在更新後會將其與預期變更的 SQL 行數做比對，如果更新失敗會拋出 exception

讓 transaction 失敗觸發 Rollback

  ActiveRecord::Base.transaction do
    order.lock!
    coupon.lock!
    account.lock!

    coupon.update!(status: "redeemed")
  end

如果執行非 bang 的語法，這次的 Lock 將毫無意義

  ActiveRecord::Base.transaction do
    order.lock!
    coupon.lock!
    account.lock!

    # 假設 update 回傳 false，但依序往下執行
    coupon.update(status: "redeemed")
    # 假設 update 回傳 true，更新成功
    account.money.update(amount: 1000)

    # 這樣就變成 coupon 更新失敗，但 account 卻成功
    # Transaction COMMIT，沒有觸發 Rollback，是危險的執行
  end

本系列其他文章

• Rails 中避免 race condition 的最佳實踐(二)