在單實例JVM中，常見的處理并發問題的方法有很多，比如synchronized關鍵字進行訪問控制、volatile關鍵字、ReentrantLock等常用方法。但是在分布式環境中，上述方法卻不能在跨jvm場景中用于處理并發問題，當業務場景需要對分布式環境中的并發問題進行處理時，需要使用其他方式來實現，如數據庫鎖機制、緩存數據庫如redis以及zookeeper分布式鎖等。
本文主要介紹數據庫中常用的樂觀鎖和悲觀鎖的實現以及優缺點。
數據庫樂觀鎖：
定義：顧名思義，系統認為數據的更新在大多數情況下是不會產生沖突的，只在數據庫更新操作提交的時候才對數據作沖突檢測。如果檢測的結果出現了與預期數據不一致的情況，則返回失敗信息。
實現方式：
1. 借助數據庫表增加一個版本號的字段version，每次更新一行記錄，都使得該行版本號加一，開始更新之前先獲取version的值，更新提交的時候帶上之前獲取的version值與當前version值作比較，如果不相等則說明version值發生了變化則檢測到了并發沖突，本次操作執行失敗，如果相等則操作執行成功。
例如：update table set columnA = 1,version=version+1 where id=#{id} and version = #{oldVersion}
2. 借助行更新時間時間戳，檢測方法則與方式1相似，即更新操作執行前先獲取記錄當前的更新時間，在提交更新時，檢測當前更新時間是否與更新開始時獲取的更新時間時間戳相等。
3. 前面2種方式都是提交的時候檢測版本有沒有改變，只要有變化都會失敗，而有一類場景當字段只需要滿足一個區間范圍并不關心是否有數據更新沖突，且本身進行更新并且作為判斷條件時，可不借助其他字段，對字段本身作判斷即可。例如一個較常見的場景：庫存的扣減，只要扣減后的值大于等于零即可。例如：update product set rest = rest– #{deduct} where name = ‘abc’ and rest >= #{deduct
優點與缺點分析，優點比較明顯，由于在檢測數據沖突時并不依賴數據庫本身的鎖機制，不會影響請求的性能，當產生并發且并發量較小的時候只有少部分請求會失敗。缺點則是，一需要對表的設計增加額外的字段，增加了數據庫的冗余，另外，當應用并發量高的時候，version值在頻繁變化，則會導致大量請求失敗，影響系統的可用性。我們通過上述sql語句還可以看到，數據庫鎖都是作用于同一行數據記錄上，這就導致一個明顯的缺點，在一些特殊場景，如大促、秒殺等活動開展的時候，大量的請求同時請求同一條記錄的行鎖，會對數據庫產生很大的寫壓力。所以綜合數據庫樂觀鎖的優缺點，樂觀鎖比較適合并發量不高，并且寫操作不頻繁的場景。
數據庫悲觀鎖：
定義：根據命名即對數據進行操作更新時，對操作持悲觀保守的態度，認為產生數據沖突的可能性很大，需要先對請求的數據加鎖再進行相關的操作。
實現方式：通過數據庫鎖機制實現，即對查詢語句添加for update關鍵字。
如下sql語句 select * from table where id = 1 for update 當一個請求A開啟事務并執行此sql同時未提交事務時，另一個線程B發起請求，此時B將阻塞在加了鎖的查詢語句上，直到A請求的事務提交或者回滾，B才會繼續執行，保證了訪問的隔離性。
悲觀鎖優缺點分析，優點是每一次行數據的訪問都是獨占的，只有當正在訪問該行數據的請求事務提交以后，其他請求才能依次訪問該數據，否則將阻塞等待鎖的獲取。悲觀鎖可以嚴格保證數據訪問的安全，但是缺點也明顯，即每次請求都會額外產生加鎖的開銷且未獲取到鎖的請求將會阻塞等待鎖的獲取，在高并發環境下，容易造成大量請求阻塞，影響系統可用性。另外，悲觀鎖使用不當還可能產生死鎖的情況。
我們來看如下情況，以商品表、用戶商品列表為例：
系統出現了2個業務操作，操作A先查詢商品表并加鎖，根據查詢的結果作更新用戶商品列表狀態字段的操作，sql為 select * from product where id = 10 for update;update user_product set status = 2? where user_id = 10001;。業務操作B先查詢用戶商品表并加鎖，根據查詢結果更新商品表剩余數量的操作,sql為select * from user_product where user_id = 10001 for update；update product set rest = rest - 1 where id = 10。
我們看一下產生死鎖的過程：A業務操作開啟事務，獲取product表id=10的行鎖，B業務操作接著開啟事務并獲取user_product表user_id為10001記錄的行鎖，A繼續執行更新操作，需要等待獲取user_product表user_id為10001的行鎖進入阻塞狀態如下圖1所示，B繼續執行更新操作需要等待獲取product表id=10的行鎖。此時我們可以發現數據庫的狀態為A等待的鎖被B占住，而B等待的鎖被A所占住，雙方事務都未提交都在等待對方釋放鎖，進入一個死循環狀態。
如圖2所示，數據庫（mysql5.7）檢測到產生了死鎖，自動回滾了B操作的事務，釋放了鎖。雖然常見數據庫如oracle或者mysql都有死鎖檢測機制，出現死鎖數據庫會自動回滾一個事務，但是也會造成系統的可用性和穩定性受到影響，我們應該避免在實際應用場景中出現死鎖的情況，如上例所示，可以考慮把一個操作改為樂觀鎖實現或者改變鎖的獲取順序使得2個操作都是先獲取同一個鎖再獲取另外一個鎖，以此避免死鎖的發生。綜合數據庫悲觀鎖的特點，在
圖1? A操作執行其update操作時等待鎖的獲取
圖2? B操作執行update時，數據庫檢測到死鎖則回滾
并發量較小、又需要獨占讀取結果并依賴讀取的結果進行判斷的業務場景比較適合使用悲觀鎖。
本文作者：彭逆（點融黑幫），任職于點融工程部promotion團隊高級軟件工程師，對足球、電影、旅游、桌游非常有興趣。
