關於數據庫樂觀鎖和悲觀鎖

樂觀鎖

在關係數據庫管理系統裏,樂觀併發控制(又名”樂觀鎖”,Optimistic Concurrency Control,縮寫”OCC”)是一種併發控制的方法。它假設多用戶併發的事務在處理時不會彼此互相影響,各事務能夠在不產生鎖的情況下處理各自影響的 那部分數據。在提交數據更新之前,每個事務會先檢查在該事務讀取數據後,有沒有其他事務又修改了該數據。如果其他事務有更新的話,正在提交的事務會進行回 滾。樂觀事務控制最早是由孔祥重(H.T.Kung)教授提出。

樂觀併發控制的階段

樂觀併發控制的事務包括以下階段:
1. 讀取:事務將數據讀入緩存,這時系統會給事務分派一個時間戳。
2. 校驗:事務執行完畢後,進行提交。這時同步校驗所有事務,如果事務所讀取的數據在讀取之後又被其他事務修改,則產生衝突,事務被中斷回滾。
3. 寫入:通過校驗階段後,將更新的數據寫入數據庫。

樂觀併發控制多數用於數據爭用不大、衝突較少的環境中,這種環境中,偶爾回滾事務的成本會低於讀取數據時鎖定數據的成本,因此可以獲得比其他併發控制方法更高的吞吐量。

相對於悲觀鎖,在對數據庫進行處理的時候,樂觀鎖並不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。

數據版本,爲數據增加的一個版本標識。當讀取數據時,將版本標識的值一同讀出,數據每更新一次,同時對版本標識進行更新。當我們提交更新的時候,判 斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對,如果數據庫表當前版本號與第一次取出來的版本標識值相等,則予以更新,否則認爲是過 期數據。

實現數據版本有兩種方式,第一種是使用版本號,第二種是使用時間戳。 使用版本號實現樂觀鎖

使用版本號時,可以在數據初始化時指定一個版本號,每次對數據的更新操作都對版本號執行+1操作。並判斷當前版本號是不是該數據的最新的版本號。

使用版本號實現樂觀鎖

使用版本號時,可以在數據初始化時指定一個版本號,每次對數據的更新操作都對版本號執行+1操作。並判斷當前版本號是不是該數據的最新的版本號。

?

1

2

3

4

5

6

7

1.查詢出商品信息

select (status,status,version) from t_goods where id=#{id}

2.根據商品信息生成訂單

3.修改商品status爲2

update t_goods

set status=2,version=version+1

where id=#{id} and version=#{version};

 

優點與不足

  樂觀併發控制相信事務之間的數據競爭(data race)的概率是比較小的,因此儘可能直接做下去,直到提交的時候纔去鎖定,所以不會產生任何鎖和死鎖。但如果直接簡單這麼做,還是有可能會遇到不可預 期的結果,例如兩個事務都讀取了數據庫的某一行,經過修改以後寫回數據庫,這時就遇到了問題。

 

悲觀鎖

在關係數據庫管理系統裏,悲觀併發控制(又名”悲觀鎖”,Pessimistic Concurrency Control,縮寫”PCC”)是一種併發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作讀某行數據應用了 鎖,那只有當這個事務把鎖釋放,其他事務才能夠執行與該鎖衝突的操作。

悲觀併發控制主要用於數據爭用激烈的環境,以及發生併發衝突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。

使用

MySQL InnoDB中使用悲觀鎖

要使用悲觀鎖,我們必須關閉mysql數據庫的自動提交屬性,因爲MySQL默認使用autocommit模式,也就是說,當你執行一個更新操作後,MySQL會立刻將結果進行提交。set autocommit=0;

?

1

2

3

4

5

6

7

8

9

10

#0.開始事務

begin;/begin work;/start transaction; (三者選一就可以)

#1.查詢出商品信息

select status from t_goods where id=1 for update;

#2.根據商品信息生成訂單

insert into t_orders (id,goods_id) values (null,1);

#3.修改商品status爲2

update t_goods set status=2;

#4.提交事務

commit;/commit work;

 

  上面的查詢語句中,我們使用了select…for update的方式,這樣就通過開啓排他鎖的方式實現了悲觀鎖。此時在t_goods表中,id爲1的 那條數據就被我們鎖定了,其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的數據不會被其它事務修改。

上面我們提到,使用select…for update會把數據給鎖住,不過我們需要注意一些鎖的級別,MySQL InnoDB默認行級鎖行級鎖都是基於索引的,如果一條SQL語句用不到索引是不會使用行級鎖的,會使用表級鎖把整張表鎖住,這點需要注意。

優點與不足

悲觀併發控制實際上是”先取鎖再訪問”的保守策略,爲數據處理的安全提供了保證。但是在效率方面,處理加鎖的機制會讓數據庫產生額外的開銷,還有增 加產生死鎖的機會;另外,在只讀型事務處理中由於不會產生衝突,也沒必要使用鎖,這樣做只能增加系統負載;還有會降低了並行性,一個事務如果鎖定了某行數 據,其他事務就必須等待該事務處理完纔可以處理那行數

總結

樂觀鎖適用於多讀的應用類型,這樣可以提高吞吐量,像數據庫如果提供類似於write_condition機智的其實都是提供的樂觀鎖。 相反,如果經常發生衝突,上層應用會不斷進行 retry,這樣反而降低了性能,所以這種情況下用悲觀鎖比較合適

 

 

 

---------------------------------------第二種理解-------------------

樂觀鎖

樂觀鎖不是數據庫自帶的,需要我們自己去實現。樂觀鎖是指操作數據庫時(更新操作),想法很樂觀,認爲這次的操作不會導致衝突,在操作數據時,並不進行任何其他的特殊處理(也就是不加鎖),而在進行更新後,再去判斷是否有衝突了。

通常實現是這樣的:在表中的數據進行操作時(更新),先給數據表加一個版本(version)字段,每操作一次,將那條記錄的版本號加1。也就是先查詢出那條記錄,獲取出version字段,如果要對那條記錄進行操作(更新),則先判斷此刻version的值是否與剛剛查詢出來時的version的值相等,如果相等,則說明這段期間,沒有其他程序對其進行操作,則可以執行更新,將version字段的值加1;如果更新時發現此刻的version值與剛剛獲取出來的version的值不相等,則說明這段期間已經有其他程序對其進行操作了,則不進行更新操作。

舉例:

 

下單操作包括3步驟:

1.查詢出商品信息

select (status,status,version) from t_goods where id=#{id}

2.根據商品信息生成訂單

3.修改商品status爲2

update t_goods 

set status=2,version=version+1

where id=#{id} and version=#{version};

 

除了自己手動實現樂觀鎖之外,現在網上許多框架已經封裝好了樂觀鎖的實現,如hibernate,需要時,可能自行搜索"hiberate 樂觀鎖"試試看。

 

悲觀鎖

與樂觀鎖相對應的就是悲觀鎖了。悲觀鎖就是在操作數據時,認爲此操作會出現數據衝突,所以在進行每次操作時都要通過獲取鎖才能進行對相同數據的操作,這點跟java中的synchronized很相似,所以悲觀鎖需要耗費較多的時間。另外與樂觀鎖相對應的,悲觀鎖是由數據庫自己實現了的,要用的時候,我們直接調用數據庫的相關語句就可以了。

說到這裏,由悲觀鎖涉及到的另外兩個鎖概念就出來了,它們就是共享鎖與排它鎖。共享鎖和排它鎖是悲觀鎖的不同的實現,它倆都屬於悲觀鎖的範疇。

 

共享鎖

  共享鎖指的就是對於多個不同的事務,對同一個資源共享同一個鎖。相當於對於同一把門,它擁有多個鑰匙一樣。就像這樣,你家有一個大門,大門的鑰匙有好幾把,你有一把,你女朋友有一把,你們都可能通過這把鑰匙進入你們家,進去啪啪啪啥的,一下理解了哈,沒錯,這個就是所謂的共享鎖。

  剛剛說了,對於悲觀鎖,一般數據庫已經實現了,共享鎖也屬於悲觀鎖的一種,那麼共享鎖在mysql中是通過什麼命令來調用呢。通過查詢資料,瞭解到通過在執行語句後面加上lock in share mode就代表對某些資源加上共享鎖了。

比如,我這裏通過mysql打開兩個查詢編輯器,在其中開啓一個事務,並不執行commit語句

city表DDL如下:

CREATE TABLE `city` (  
  `id` bigint(20) NOT NULL AUTO_INCREMENT,  
  `name` varchar(255) DEFAULT NULL,  
  `state` varchar(255) DEFAULT NULL,  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8;  

 

 

begin;
SELECT * from city where id = "1"  lock in share mode;

 

 

然後在另一個查詢窗口中,對id爲1的數據進行更新

 

 

update  city set name="666" where id ="1";

此時,操作界面進入了卡頓狀態,過幾秒後,也提示錯誤信息

[SQL]update  city set name="666" where id ="1";
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction

 

那麼證明,對於id=1的記錄加鎖成功了,在上一條記錄還沒有commit之前,這條id=1的記錄被鎖住了,只有在上一個事務釋放掉鎖後才能進行操作,或用共享鎖才能對此數據進行操作。

再實驗一下:

 

 

update city set name="666" where id ="1" lock in share mode;

[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'lock in share mode' at line 1

 

加上共享鎖後,也提示錯誤信息了,通過查詢資料才知道,對於update,insert,delete語句會自動加排它鎖的原因

 

於是,我又試了試SELECT * from city where id = "1" lock in share mode;


 

這下成功了。

 

 

 

 

排它鎖

排它鎖與共享鎖相對應,就是指對於多個不同的事務,對同一個資源只能有一把鎖。

與共享鎖類型,在需要執行的語句後面加上for update就可以了

 

行鎖

行鎖,由字面意思理解,就是給某一行加上鎖,也就是一條記錄加上鎖。

比如之前演示的共享鎖語句

SELECT * from city where id = "1"  lock in share mode; 

由於對於city表中,id字段爲主鍵,就也相當於索引。執行加鎖時,會將id這個索引爲1的記錄加上鎖,那麼這個鎖就是行鎖。

 

表鎖

表鎖,和行鎖相對應,給這個表加上鎖。

 

轉載原文地址爲:https://www.cnblogs.com/qlqwjy/p/7798266.html

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章