鎖的相關使用心得

[Ban921]

一般在高併發或是金流或是多執行序相關鎖的使用方式或心得
可以介紹一下遇過什麼好的設計方式或是不好設計方式導致的心得
還有隔離階層
會問這問題的原因是公司的樣本數太少
想聽聽看有沒有更良好的設計方式可以省時省力

[Ban921]

補充一下 上述狀況可以用超賣商品或是門票之類的設計方式

[kevinkuo39781]

Hi, 我整理一下你的問題：
1.你想知道的應該是 "線上交易的正確性" 這個課題
2.隔離階層是指 MSSQL 的 isolation levels 嗎？ 有下列等級區分的Read uncommitted、Read committed、Repeatable read、Snapshot、Serializable

這個問題會有以下的延伸:

1. 你的金流服務的流量是否超過 RDBMS 所提供的 SQL Transaction，這個方法較為普遍被使用

示意 SQL

-- 開啟交易
BEGIN TRANSACTION;  

-- 資料處理
do something...

-- 資料確認
do something...

-- 判斷資料是否正確
do something...

-- 成功 
COMMIT;

-- 失敗
ROLLBACK TRANSACTION

這種做法透過反正規化的設計，省去 JOIN 與合理的 Index 設計可以處理大部分的場景

2. 如果你的量超過 RDBMS 叢集可以處理的量，你就需要考慮實作分散鎖(distributed lock)
   這部分的問題點會比較多，安排時間彙整出來再供參考

有任何問題歡迎提出討論 @jim515jim