五一小長(zhǎng)假即將到來(lái)，決定趁著假期出去玩一玩。我和女朋友商量好，我負(fù)責(zé)制定行程，她負(fù)責(zé)購(gòu)買(mǎi)出行用品。

相安無(wú)事，我正在各家比價(jià)中，不知道發(fā)生了什么，女朋友買(mǎi)買(mǎi)買(mǎi)竟然不高興了。

 

并發(fā)控制

當(dāng)程序中可能出現(xiàn)并發(fā)的情況時(shí)，我們就需要通過(guò)一定的手段來(lái)保證在并發(fā)情況下數(shù)據(jù)的準(zhǔn)確性，通過(guò)這種手段保證了當(dāng)用戶和其他用戶一起操作時(shí)，所得到的結(jié)果和他單獨(dú)操作時(shí)的禱告的結(jié)果是一樣的。

這種手段就叫做并發(fā)控制。并發(fā)控制的目的是保證一個(gè)用戶的工作不會(huì)對(duì)另一個(gè)用戶的工作產(chǎn)生不合理的影響。

沒(méi)有做好并發(fā)控制，就可能導(dǎo)致臟讀、幻讀和不可重復(fù)讀等問(wèn)題。

 

我們常說(shuō)的并發(fā)控制，一般都和數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS)有關(guān)，在 DBMS 中的并發(fā)控制的任務(wù)是確保在多個(gè)事務(wù)同時(shí)存取數(shù)據(jù)庫(kù)中同一數(shù)據(jù)時(shí)不破壞事務(wù)的隔離性和統(tǒng)一性以及數(shù)據(jù)庫(kù)的統(tǒng)一性。

實(shí)現(xiàn)并發(fā)控制的主要手段大致可以分為樂(lè)觀并發(fā)控制和悲觀并發(fā)控制兩種。

 

在開(kāi)始介紹之前要明確一下：無(wú)論是悲觀鎖還是樂(lè)觀鎖，都是人們定義出來(lái)的概念，可以認(rèn)為是一種思想。

其實(shí)不僅僅是關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)中有樂(lè)觀鎖和悲觀鎖的概念，像 Memcache、Hibernate、Tair 等都有類(lèi)似的概念。所以，不應(yīng)該拿樂(lè)觀鎖、悲觀鎖和其他的數(shù)據(jù)庫(kù)鎖等進(jìn)行對(duì)比。

悲觀鎖

當(dāng)我們要對(duì)一個(gè)數(shù)據(jù)庫(kù)中的一條數(shù)據(jù)進(jìn)行修改的時(shí)候，為了避免同時(shí)被其他人修改，***的辦法就是直接對(duì)該數(shù)據(jù)進(jìn)行加鎖以防止并發(fā)。

這種借助數(shù)據(jù)庫(kù)鎖機(jī)制在修改數(shù)據(jù)之前先鎖定，再修改的方式被稱之為悲觀并發(fā)控制(又名“悲觀鎖”，Pessimistic Concurrency Control，縮寫(xiě)“PCC”)。

之所以叫做悲觀鎖，是因?yàn)檫@是一種對(duì)數(shù)據(jù)的修改抱有悲觀態(tài)度的并發(fā)控制方式。我們一般認(rèn)為數(shù)據(jù)被并發(fā)修改的概率比較大，所以需要在修改之前先加鎖。

悲觀并發(fā)控制實(shí)際上是“先取鎖再訪問(wèn)”的保守策略，為數(shù)據(jù)處理的安全提供了保證。

 

但是在效率方面，處理加鎖的機(jī)制會(huì)讓數(shù)據(jù)庫(kù)產(chǎn)生額外的開(kāi)銷(xiāo)，還有增加產(chǎn)生死鎖的機(jī)會(huì)。

另外，還會(huì)降低并行性，一個(gè)事務(wù)如果鎖定了某行數(shù)據(jù)，其他事務(wù)就必須等待該事務(wù)處理完才可以處理那行數(shù)據(jù)。

 

樂(lè)觀鎖

樂(lè)觀鎖( Optimistic Locking ) 是相對(duì)悲觀鎖而言的，樂(lè)觀鎖假設(shè)數(shù)據(jù)一般情況下不會(huì)造成沖突。

所以在數(shù)據(jù)進(jìn)行提交更新的時(shí)候，才會(huì)正式對(duì)數(shù)據(jù)的沖突與否進(jìn)行檢測(cè)，如果發(fā)現(xiàn)沖突了，則讓返回用戶錯(cuò)誤的信息，讓用戶決定如何去做。

相對(duì)于悲觀鎖，在對(duì)數(shù)據(jù)庫(kù)進(jìn)行處理的時(shí)候，樂(lè)觀鎖并不會(huì)使用數(shù)據(jù)庫(kù)提供的鎖機(jī)制。一般的實(shí)現(xiàn)樂(lè)觀鎖的方式就是記錄數(shù)據(jù)版本。

 

樂(lè)觀并發(fā)控制相信事務(wù)之間的數(shù)據(jù)競(jìng)爭(zhēng)(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時(shí)候才去鎖定，所以不會(huì)產(chǎn)生任何鎖和死鎖。

 

悲觀鎖實(shí)現(xiàn)方式

悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫(kù)提供的鎖機(jī)制。在數(shù)據(jù)庫(kù)中，悲觀鎖的流程如下：

• 在對(duì)記錄進(jìn)行修改前，先嘗試為該記錄加上排他鎖(exclusive locking)。
• 如果加鎖失敗，說(shuō)明該記錄正在被修改，那么當(dāng)前查詢可能要等待或者拋出異常。具體響應(yīng)方式由開(kāi)發(fā)者根據(jù)實(shí)際需要決定。
• 如果成功加鎖，那么就可以對(duì)記錄做修改，事務(wù)完成后就會(huì)解鎖了。
• 其間如果有其他對(duì)該記錄做修改或加排他鎖的操作，都會(huì)等待我們解鎖或直接拋出異常。

我們拿比較常用的 MySQL Innodb 引擎舉例，來(lái)說(shuō)明一下在 SQL 中如何使用悲觀鎖。

要使用悲觀鎖，我們必須關(guān)閉 MySQL 數(shù)據(jù)庫(kù)的自動(dòng)提交屬性，因?yàn)?MySQL 默認(rèn)使用 Autocommit 模式。

也就是說(shuō)，當(dāng)你執(zhí)行一個(gè)更新操作后，MySQL 會(huì)立刻將結(jié)果進(jìn)行提交。set autocommit=0。

我們舉一個(gè)簡(jiǎn)單的例子，如用淘寶下單過(guò)程中扣減庫(kù)存的需求說(shuō)明一下如何使用悲觀鎖：

//0.開(kāi)始事務(wù) 
begin;  
//1.查詢出商品庫(kù)存信息 
select quantity from items where id=1 for update; 
//2.修改商品庫(kù)存為2 
update items set quantity=2 where id = 1; 
//3.提交事務(wù) 
commit; 

以上，在對(duì) id=1 的記錄修改前，先通過(guò) for update 的方式進(jìn)行加鎖，然后再進(jìn)行修改。這就是比較典型的悲觀鎖策略。

如果以上修改庫(kù)存的代碼發(fā)生并發(fā)，同一時(shí)間只有一個(gè)線程可以開(kāi)啟事務(wù)并獲得 id=1 的鎖，其他的事務(wù)必須等本次事務(wù)提交之后才能執(zhí)行。這樣我們可以保證當(dāng)前的數(shù)據(jù)不會(huì)被其他事務(wù)修改。

上面我們提到，使用 select…for update 會(huì)把數(shù)據(jù)給鎖住，不過(guò)我們需要注意一些鎖的級(jí)別，MySQL InnoDB 默認(rèn)行級(jí)鎖。

行級(jí)鎖都是基于索引的，如果一條 SQL 語(yǔ)句用不到索引是不會(huì)使用行級(jí)鎖的，會(huì)使用表級(jí)鎖把整張表鎖住，這點(diǎn)需要注意。

 

樂(lè)觀鎖實(shí)現(xiàn)方式

使用樂(lè)觀鎖就不需要借助數(shù)據(jù)庫(kù)的鎖機(jī)制了。樂(lè)觀鎖的概念中其實(shí)已經(jīng)闡述了它的具體實(shí)現(xiàn)細(xì)節(jié)，主要就是兩個(gè)步驟：沖突檢測(cè)和數(shù)據(jù)更新。其實(shí)現(xiàn)方式有一種比較典型的就是 Compare and Swap(CAS)。

CAS 是項(xiàng)樂(lè)觀鎖技術(shù)，當(dāng)多個(gè)線程嘗試使用 CAS 同時(shí)更新同一個(gè)變量時(shí)，只有其中一個(gè)線程能更新變量的值，而其他線程都失敗，失敗的線程并不會(huì)被掛起，而是被告知這次競(jìng)爭(zhēng)中失敗，并可以再次嘗試。

比如前面的扣減庫(kù)存問(wèn)題，通過(guò)樂(lè)觀鎖可以實(shí)現(xiàn)如下：

//查詢出商品庫(kù)存信息，quantity = 3 
select quantity from items where id=1 
//修改商品庫(kù)存為2 
update items set quantity=2 where id=1 and quantity = 3; 

以上，我們?cè)诟轮埃炔樵円幌聨?kù)存表中當(dāng)前庫(kù)存數(shù)(quantity)，然后在做 update 的時(shí)候，以庫(kù)存數(shù)作為一個(gè)修改條件。

當(dāng)我們提交更新的時(shí)候，判斷數(shù)據(jù)庫(kù)表對(duì)應(yīng)記錄的當(dāng)前庫(kù)存數(shù)與***次取出來(lái)的庫(kù)存數(shù)進(jìn)行比對(duì)，如果數(shù)據(jù)庫(kù)表當(dāng)前庫(kù)存數(shù)與***次取出來(lái)的庫(kù)存數(shù)相等，則予以更新，否則認(rèn)為是過(guò)期數(shù)據(jù)。

 

以上更新語(yǔ)句存在一個(gè)比較重要的問(wèn)題，即傳說(shuō)中的 ABA 問(wèn)題。

比如說(shuō)一個(gè)線程 one 從數(shù)據(jù)庫(kù)中取出庫(kù)存數(shù) 3，這時(shí)候另一個(gè)線程 two 也從數(shù)據(jù)庫(kù)中取出庫(kù)存數(shù) 3，并且 two 進(jìn)行了一些操作變成了 2。

然后 two 又將庫(kù)存數(shù)變成 3，這時(shí)候線程 one 進(jìn)行 CAS 操作發(fā)現(xiàn)數(shù)據(jù)庫(kù)中仍然是 3，然后 one 操作成功。盡管線程 one 的 CAS 操作成功，但是不代表這個(gè)過(guò)程就是沒(méi)有問(wèn)題的。

 

有一個(gè)比較好的辦法可以解決 ABA 問(wèn)題，那就是通過(guò)一個(gè)單獨(dú)的可以順序遞增的 version 字段。

改為以下方式即可：

//查詢出商品信息，version = 1 
select version from items where id=1 
//修改商品庫(kù)存為2 
update items set quantity=2,version = 3 where id=1 and version = 2; 

樂(lè)觀鎖每次在執(zhí)行數(shù)據(jù)的修改操作時(shí)，都會(huì)帶上一個(gè)版本號(hào)，一旦版本號(hào)和數(shù)據(jù)的版本號(hào)一致就可以執(zhí)行修改操作并對(duì)版本號(hào)執(zhí)行 +1 操作，否則就執(zhí)行失敗。

因?yàn)槊看尾僮鞯陌姹咎?hào)都會(huì)隨之增加，所以不會(huì)出現(xiàn) ABA 問(wèn)題，因?yàn)榘姹咎?hào)只會(huì)增加不會(huì)減少。

 

除了 version 以外，還可以使用時(shí)間戳，因?yàn)闀r(shí)間戳天然具有順序遞增性。

 

以上 SQL 其實(shí)還是有一定的問(wèn)題的，就是一旦發(fā)上高并發(fā)的時(shí)候，就只有一個(gè)線程可以修改成功，那么就會(huì)存在大量的失敗。

對(duì)于像淘寶這樣的電商網(wǎng)站，高并發(fā)是常有的事，總讓用戶感知到失敗顯然是不合理的。所以，還是要想辦法減少樂(lè)觀鎖的粒度的。

有一條比較好的建議，可以減小樂(lè)觀鎖力度，***程度的提升吞吐率，提高并發(fā)能力!如下：

//修改商品庫(kù)存 
update item  
set quantity=quantity - 1  
where id = 1 and quantity - 1 > 0 

以上 SQL 語(yǔ)句中，如果用戶下單數(shù)為 1，則通過(guò) quantity - 1 > 0 的方式進(jìn)行樂(lè)觀鎖控制。

以上 update 語(yǔ)句，在執(zhí)行過(guò)程中，會(huì)在一次原子操作中自己查詢一遍 quantity 的值，并將其扣減掉 1。

高并發(fā)環(huán)境下鎖粒度把控是一門(mén)重要的學(xué)問(wèn)，選擇一個(gè)好的鎖，在保證數(shù)據(jù)安全的情況下，可以大大提升吞吐率，進(jìn)而提升性能。

 

 

 

 

如何選擇

在樂(lè)觀鎖與悲觀鎖的選擇上面，主要看下兩者的區(qū)別以及適用場(chǎng)景就可以了：

• 樂(lè)觀鎖并未真正加鎖，效率高。一旦鎖的粒度掌握不好，更新失敗的概率就會(huì)比較高，容易發(fā)生業(yè)務(wù)失敗。
• 悲觀鎖依賴數(shù)據(jù)庫(kù)鎖，效率低。更新失敗的概率比較低。

隨著互聯(lián)網(wǎng)三高架構(gòu)(高并發(fā)、高性能、高可用)的提出，悲觀鎖已經(jīng)越來(lái)越少的被使用到生產(chǎn)環(huán)境中了，尤其是并發(fā)量比較大的業(yè)務(wù)場(chǎng)景。