在單實例JVM中，常見的處理并發(fā)問題的方法有很多，比如synchronized關(guān)鍵字進(jìn)行訪問控制、volatile關(guān)鍵字、ReentrantLock等常用方法。但是在分布式環(huán)境中，上述方法卻不能在跨jvm場景中用于處理并發(fā)問題，當(dāng)業(yè)務(wù)場景需要對分布式環(huán)境中的并發(fā)問題進(jìn)行處理時，需要使用其他方式來實現(xiàn)，如數(shù)據(jù)庫鎖機(jī)制、緩存數(shù)據(jù)庫如redis以及zookeeper分布式鎖等。

本文主要介紹數(shù)據(jù)庫中常用的樂觀鎖和悲觀鎖的實現(xiàn)以及優(yōu)缺點。

數(shù)據(jù)庫樂觀鎖：

定義：顧名思義，系統(tǒng)認(rèn)為數(shù)據(jù)的更新在大多數(shù)情況下是不會產(chǎn)生沖突的，只在數(shù)據(jù)庫更新操作提交的時候才對數(shù)據(jù)作沖突檢測。如果檢測的結(jié)果出現(xiàn)了與預(yù)期數(shù)據(jù)不一致的情況，則返回失敗信息。

實現(xiàn)方式：

1. 借助數(shù)據(jù)庫表增加一個版本號的字段version，每次更新一行記錄，都使得該行版本號加一，開始更新之前先獲取version的值，更新提交的時候帶上之前獲取的version值與當(dāng)前version值作比較，如果不相等則說明version值發(fā)生了變化則檢測到了并發(fā)沖突，本次操作執(zhí)行失敗，如果相等則操作執(zhí)行成功。

例如：update table set columnA = 1,version=version+1 where id=#{id} and version = #{oldVersion}

2. 借助行更新時間時間戳，檢測方法則與方式1相似，即更新操作執(zhí)行前先獲取記錄當(dāng)前的更新時間，在提交更新時，檢測當(dāng)前更新時間是否與更新開始時獲取的更新時間時間戳相等。

3. 前面2種方式都是提交的時候檢測版本有沒有改變，只要有變化都會失敗，而有一類場景當(dāng)字段只需要滿足一個區(qū)間范圍并不關(guān)心是否有數(shù)據(jù)更新沖突，且本身進(jìn)行更新并且作為判斷條件時，可不借助其他字段，對字段本身作判斷即可。例如一個較常見的場景：庫存的扣減，只要扣減后的值大于等于零即可。例如：update product set rest = rest– #{deduct} where name = ‘a(chǎn)bc’ and rest >= #{deduct

優(yōu)點與缺點分析，優(yōu)點比較明顯，由于在檢測數(shù)據(jù)沖突時并不依賴數(shù)據(jù)庫本身的鎖機(jī)制，不會影響請求的性能，當(dāng)產(chǎn)生并發(fā)且并發(fā)量較小的時候只有少部分請求會失敗。缺點則是，一需要對表的設(shè)計增加額外的字段，增加了數(shù)據(jù)庫的冗余，另外，當(dāng)應(yīng)用并發(fā)量高的時候，version值在頻繁變化，則會導(dǎo)致大量請求失敗，影響系統(tǒng)的可用性。我們通過上述sql語句還可以看到，數(shù)據(jù)庫鎖都是作用于同一行數(shù)據(jù)記錄上，這就導(dǎo)致一個明顯的缺點，在一些特殊場景，如大促、秒殺等活動開展的時候，大量的請求同時請求同一條記錄的行鎖，會對數(shù)據(jù)庫產(chǎn)生很大的寫壓力。所以綜合數(shù)據(jù)庫樂觀鎖的優(yōu)缺點，樂觀鎖比較適合并發(fā)量不高，并且寫操作不頻繁的場景。

數(shù)據(jù)庫悲觀鎖：

定義：根據(jù)命名即對數(shù)據(jù)進(jìn)行操作更新時，對操作持悲觀保守的態(tài)度，認(rèn)為產(chǎn)生數(shù)據(jù)沖突的可能性很大，需要先對請求的數(shù)據(jù)加鎖再進(jìn)行相關(guān)的操作。

實現(xiàn)方式：通過數(shù)據(jù)庫鎖機(jī)制實現(xiàn)，即對查詢語句添加for update關(guān)鍵字。

如下sql語句 select * from table where id = 1 for update 當(dāng)一個請求A開啟事務(wù)并執(zhí)行此sql同時未提交事務(wù)時，另一個線程B發(fā)起請求，此時B將阻塞在加了鎖的查詢語句上，直到A請求的事務(wù)提交或者回滾，B才會繼續(xù)執(zhí)行，保證了訪問的隔離性。

悲觀鎖優(yōu)缺點分析，優(yōu)點是每一次行數(shù)據(jù)的訪問都是獨占的，只有當(dāng)正在訪問該行數(shù)據(jù)的請求事務(wù)提交以后，其他請求才能依次訪問該數(shù)據(jù)，否則將阻塞等待鎖的獲取。悲觀鎖可以嚴(yán)格保證數(shù)據(jù)訪問的安全，但是缺點也明顯，即每次請求都會額外產(chǎn)生加鎖的開銷且未獲取到鎖的請求將會阻塞等待鎖的獲取，在高并發(fā)環(huán)境下，容易造成大量請求阻塞，影響系統(tǒng)可用性。另外，悲觀鎖使用不當(dāng)還可能產(chǎn)生死鎖的情況。

我們來看如下情況，以商品表、用戶商品列表為例：

系統(tǒng)出現(xiàn)了2個業(yè)務(wù)操作，操作A先查詢商品表并加鎖，根據(jù)查詢的結(jié)果作更新用戶商品列表狀態(tài)字段的操作，sql為 select * from product where id = 10 for update;update user_product set status = 2? where user_id = 10001;。業(yè)務(wù)操作B先查詢用戶商品表并加鎖，根據(jù)查詢結(jié)果更新商品表剩余數(shù)量的操作,sql為select * from user_product where user_id = 10001 for update；update product set rest = rest - 1 where id = 10。

我們看一下產(chǎn)生死鎖的過程：A業(yè)務(wù)操作開啟事務(wù)，獲取product表id=10的行鎖，B業(yè)務(wù)操作接著開啟事務(wù)并獲取user_product表user_id為10001記錄的行鎖，A繼續(xù)執(zhí)行更新操作，需要等待獲取user_product表user_id為10001的行鎖進(jìn)入阻塞狀態(tài)如下圖1所示，B繼續(xù)執(zhí)行更新操作需要等待獲取product表id=10的行鎖。此時我們可以發(fā)現(xiàn)數(shù)據(jù)庫的狀態(tài)為A等待的鎖被B占住，而B等待的鎖被A所占住，雙方事務(wù)都未提交都在等待對方釋放鎖，進(jìn)入一個死循環(huán)狀態(tài)。

如圖2所示，數(shù)據(jù)庫（mysql5.7）檢測到產(chǎn)生了死鎖，自動回滾了B操作的事務(wù)，釋放了鎖。雖然常見數(shù)據(jù)庫如oracle或者mysql都有死鎖檢測機(jī)制，出現(xiàn)死鎖數(shù)據(jù)庫會自動回滾一個事務(wù)，但是也會造成系統(tǒng)的可用性和穩(wěn)定性受到影響，我們應(yīng)該避免在實際應(yīng)用場景中出現(xiàn)死鎖的情況，如上例所示，可以考慮把一個操作改為樂觀鎖實現(xiàn)或者改變鎖的獲取順序使得2個操作都是先獲取同一個鎖再獲取另外一個鎖，以此避免死鎖的發(fā)生。綜合數(shù)據(jù)庫悲觀鎖的特點，在

圖1? A操作執(zhí)行其update操作時等待鎖的獲取

圖2? B操作執(zhí)行update時，數(shù)據(jù)庫檢測到死鎖則回滾

并發(fā)量較小、又需要獨占讀取結(jié)果并依賴讀取的結(jié)果進(jìn)行判斷的業(yè)務(wù)場景比較適合使用悲觀鎖。

本文作者：彭逆（點融黑幫），任職于點融工程部promotion團(tuán)隊高級軟件工程師，對足球、電影、旅游、桌游非常有興趣。