快捷導航

MySQL中的悲觀鎖與樂觀鎖

更新時間：2020年09月11日 10:17:14 作者：debug客棧

這篇文章主要介紹了MySQL中悲觀鎖與樂觀鎖的相關(guān)資料，幫助大家更好的理解和學習MySQL數(shù)據(jù)庫，感興趣的朋友可以了解下

在關(guān)系型數(shù)據(jù)庫中，悲觀鎖與樂觀鎖是解決資源并發(fā)場景的解決方案，接下來將詳細講解🔎一下這兩個并發(fā)解決方案的實際使用及優(yōu)缺點。

首先定義一下數(shù)據(jù)庫，做一個最簡單的庫存表，如下設(shè)計：

CREATE TABLE `order_stock` (
 `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'ID',
 `oid` int(50) NOT NULL COMMENT '商品ID',
 `quantity` int(20) NOT NULL COMMENT '庫存',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

quantity代表著不同商品oid的庫存，接下來OCC及PCC使用此數(shù)據(jù)庫進行演示。

樂觀鎖 OCC

它假設(shè)多用戶并發(fā)的事務(wù)在處理時不會彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分數(shù)據(jù)。在提交數(shù)據(jù)更新之前，每個事務(wù)會先檢查在該事務(wù)讀取數(shù)據(jù)后，有沒有其他事務(wù)又修改了該數(shù)據(jù)。如果其他事務(wù)有更新的話，正在提交的事務(wù)會進行回滾。

即“樂觀鎖🔒”認為拿鎖的用戶多半是會成功的，因此在進行完業(yè)務(wù)操作需要實際更新數(shù)據(jù)的最后一步再去拿一下鎖就好。這樣就可以避免使用數(shù)據(jù)庫自身定義的行鎖，可以避免死鎖現(xiàn)象的產(chǎn)生。

UPDATE order_stock SET quantity = quantity - 1 WHERE oid = 1 AND quantity - 1 > 0;

樂觀并發(fā)控制多數(shù)用于數(shù)據(jù)爭用不大、沖突較少的環(huán)境中，這種環(huán)境中，偶爾回滾事務(wù)的成本會低于讀取數(shù)據(jù)時鎖定數(shù)據(jù)的成本，因此可以獲得比其他并發(fā)控制方法更高的吞吐量。

悲觀鎖 PCC

它可以阻止一個事務(wù)以影響其他用戶的方式來修改數(shù)據(jù)。如果一個事務(wù)執(zhí)行的操作讀某行數(shù)據(jù)應(yīng)用了鎖，那只有當這個事務(wù)把鎖釋放，其他事務(wù)才能夠執(zhí)行與該鎖沖突的操作。

這種設(shè)計采用了“一鎖🔒二查🔍三更新”模式，就是采用數(shù)據(jù)庫中自帶 select ... for update 關(guān)鍵字進行對當前事務(wù)添加行級鎖🔒，先將要操作的數(shù)據(jù)進行鎖上，之后執(zhí)行對應(yīng)查詢數(shù)據(jù)并執(zhí)行更新操作。

BEGIN
SELECT quantity FROM order_stock WHERE oid = 1 FOR UPDATE;
UPDATE order_stock SET quantity = 2 WHERE oid = 1; 
COMMIT;

MySQL還有個問題是select ... for update語句執(zhí)行中所有掃描過的行都會被鎖上，這一點很容易造成問題。因此如果在MySQL中用悲觀鎖務(wù)必要確定走了索引，而不是全表掃描。

悲觀并發(fā)控制主要用于數(shù)據(jù)爭用激烈的環(huán)境，以及發(fā)生并發(fā)沖突時使用鎖保護數(shù)據(jù)的成本要低于回滾事務(wù)的成本的環(huán)境中。

OCC 和 PCC 優(yōu)缺點

OCC 優(yōu)點及缺點

【優(yōu)點】

樂觀鎖相信事務(wù)之間的數(shù)據(jù)競爭(data race)的概率是比較小的，因此盡可能直接做下去，直到提交的時候才去鎖定，所以不會產(chǎn)生任何鎖和死鎖；
可以快速響應(yīng)事務(wù)，隨著并發(fā)量增加，但會出現(xiàn)大量回滾出現(xiàn)；
效率高，但是要控制好鎖的力度。

【缺點】