悲觀鎖

在MySQL中，悲觀鎖依賴數(shù)據(jù)庫提供的鎖機制來實現(xiàn)。在InnoDB引擎中，使用悲觀鎖需要先關(guān)閉MySQL數(shù)據(jù)庫的自動提交屬性，然后通過select ... for update來進(jìn)行加鎖。

在數(shù)據(jù)庫中，悲觀鎖的流程如下：

? 在對記錄進(jìn)行修改前，先嘗試為該記錄加上排他鎖（exclusive lock）。

? 如果加鎖失敗，說明該記錄正在被修改，此時當(dāng)前查詢可能需要等待或拋出異常，具體響應(yīng)方式由開發(fā)者根據(jù)實際需求決定。

? 如果成功加鎖，則可以對記錄進(jìn)行修改，事務(wù)完成后鎖將被釋放。

? 其間若有其他操作試圖對該記錄進(jìn)行修改或加排他鎖，則會等待當(dāng)前鎖的釋放或直接拋出異常。

我們以電商平臺下單過程中扣減庫存的需求為例，說明如何使用悲觀鎖：

-- 0.開始事務(wù)
begin; 
-- 1.查詢出商品信息
SELECT stock FROM products WHERE product_id = 12345 FOR UPDATE;
-- 2.修改商品stock為2
update products set stock=2 where product_id = 12345;
-- 3.提交事務(wù)
commit;

在對id=1的記錄進(jìn)行修改前，先通過FOR UPDATE的方式加鎖，然后再進(jìn)行修改。這就是典型的悲觀鎖策略。

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

上面提到，使用SELECT ... FOR UPDATE會將數(shù)據(jù)鎖住，不過我們需要注意一些鎖的級別。MySQL InnoDB默認(rèn)使用行級鎖。行級鎖都是基于索引的，如果一條SQL語句未使用索引，優(yōu)化器在選擇時，若發(fā)現(xiàn)鎖表可能性能更好，有可能會直接鎖表。

上面這個點之前也有在文章提到過： 

日活3kw的實際庫存業(yè)務(wù)場景中的超賣到底怎么解決的

感興趣的可以參考閱讀一下，希望對你有所幫助

樂觀鎖

MySQL中的樂觀鎖主要通過CAS（Compare and Swap）的機制來實現(xiàn)，通常使用版本號（version）來實現(xiàn)。

CAS是一種樂觀鎖技術(shù)，當(dāng)多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能成功更新變量的值，而其他線程都失敗。失敗的線程并不會被掛起，而是被告知在此次競爭中失敗，并可以再次嘗試。

以扣減庫存為例，通過樂觀鎖可以實現(xiàn)如下：

-- 查詢出商品信息，stock = 3
select stock from products product_id id= 1
-- 根據(jù)商品信息生成訂單
-- 修改商品stock為2
update products set stock=2 where id=1 and stock = 3;

以上，在更新之前，先查詢庫存表中當(dāng)前的庫存數(shù)（stock），然后在執(zhí)行更新時，將庫存數(shù)作為修改條件。提交更新時，對比數(shù)據(jù)庫表記錄的當(dāng)前庫存數(shù)與第一次查詢得到的庫存數(shù)，若兩者相等，則執(zhí)行更新；否則，視為數(shù)據(jù)已過期。

題外話

悲觀鎖

在對數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行修改時，為了避免同時被其他人修改，最好的方法是直接對該數(shù)據(jù)進(jìn)行加鎖以防止并發(fā)。這種在修改數(shù)據(jù)之前先鎖定再修改的方式被稱為悲觀并發(fā)控制（又稱“悲觀鎖”，Pessimistic Concurrency Control，縮寫為“PCC”）。

悲觀鎖之所以被稱為悲觀，是因為這是一種對數(shù)據(jù)的修改抱有悲觀態(tài)度的并發(fā)控制方式。一般來說，我們認(rèn)為數(shù)據(jù)被并發(fā)修改的概率較大，因此在修改之前先加鎖。

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

圖片

在效率方面，處理加鎖機制會導(dǎo)致數(shù)據(jù)庫產(chǎn)生額外的開銷，增加了產(chǎn)生死鎖的風(fēng)險。此外，悲觀鎖還可能降低并行性，因為如果一個事務(wù)鎖定了某行數(shù)據(jù)，其他事務(wù)就必須等待該事務(wù)完成才能處理該行數(shù)據(jù)。

樂觀鎖

樂觀鎖（Optimistic Locking）是相對悲觀鎖而言的。樂觀鎖假設(shè)數(shù)據(jù)在一般情況下不會發(fā)生沖突，因此在數(shù)據(jù)提交更新時才會實際檢查數(shù)據(jù)是否沖突。如果發(fā)現(xiàn)沖突，則會向用戶返回錯誤信息，讓用戶決定如何處理。

與悲觀鎖相比，樂觀鎖在處理數(shù)據(jù)庫時并不會使用數(shù)據(jù)庫提供的鎖機制。一般來說，樂觀鎖的實現(xiàn)方式是通過記錄數(shù)據(jù)的版本信息。

圖片

樂觀并發(fā)控制相信事務(wù)之間的數(shù)據(jù)競爭（data race）的概率較小，因此盡可能直接進(jìn)行操作，直到提交時才對數(shù)據(jù)進(jìn)行檢查和鎖定。這樣做不會產(chǎn)生任何鎖或死鎖。

如何選擇

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

1. 樂觀鎖并未真正加鎖，效率高。適用于讀操作頻繁，寫操作相對較少的場景。一旦鎖的粒度掌握不好，更新失敗的概率就會比較高，容易發(fā)生業(yè)務(wù)失敗。

2. 悲觀鎖依賴數(shù)據(jù)庫鎖，效率低。更新失敗的概率比較低。適用于寫操作較為頻繁，且并發(fā)寫入的概率較高的場景。

根據(jù)以上區(qū)別和場景特點，可以針對具體業(yè)務(wù)需求選擇合適的并發(fā)控制策略。當(dāng)然最多的場景其實當(dāng)屬于高并發(fā)場景如何選擇。