淺談資料庫樂觀鎖和悲觀鎖
在單例項JVM中，常見的處理併發問題的方法有很多，比如synchronized關鍵字進行訪問控制、volatile關鍵字、ReentrantLock等常用方法。但是在分散式環境中，上述方法卻不能在跨jvm場景中用於處理併發問題，當業務場景需要對分散式環境中的併發問題進行處理時，需要使用其他方式來實現，如資料庫鎖機制、快取資料庫如redis以及zookeeper分散式鎖等。
本文主要介紹資料庫中常用的樂觀鎖和悲觀鎖的實現以及優缺點。
資料庫樂觀鎖：
定義：顧名思義，系統認為資料的更新在大多數情況下是不會產生衝突的，只在資料庫更新操作提交的時候才對資料作衝突檢測。如果檢測的結果出現了與預期資料不一致的情況，則返回失敗資訊。
實現方式：
- 藉助資料庫表增加一個版本號的欄位version，每次更新一行記錄，都使得該行版本號加一，開始更新之前先獲取version的值，更新提交的時候帶上之前獲取的version值與當前version值作比較，如果不相等則說明version值發生了變化則檢測到了併發衝突，本次操作執行失敗，如果相等則操作執行成功。
例如：update table set columnA = 1,version=version+1 where id=#{id} and version = #{oldVersion}
-
藉助行更新時間時間戳，檢測方法則與方式1相似，即更新操作執行前先獲取記錄當前的更新時間，在提交更新時，檢測當前更新時間是否與更新開始時獲取的更新時間時間戳相等。
-
前面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操作時等待鎖的獲取
併發量較小、又需要獨佔讀取結果並依賴讀取的結果進行判斷的業務場景比較適合使用悲觀鎖。