樂觀鎖和悲觀鎖的區別

時間 2019-11-19

標籤樂觀悲觀區別简体版

原文原文鏈接

樂觀鎖

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

樂觀併發控制的階段

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

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

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

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

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

使用版本號時，能夠在數據初始化時指定一個版本號，每次對數據的更新操做都對版本號執行+1操做。並判斷當前版本號是否是該數據的最新的版本號。併發

使用版本號實現樂觀鎖

使用版本號時，能夠在數據初始化時指定一個版本號，每次對數據的更新操做都對版本號執行+1操做。並判斷當前版本號是否是該數據的最新的版本號。框架

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」）是一種併發控制的方法。它能夠阻止一個事務以影響其餘用戶的方式來修改數據。若是一個事務執行的操做讀某行數據應用了鎖，那只有當這個事務把鎖釋放，其餘事務纔可以執行與該鎖衝突的操做。post

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

使用

MySQL InnoDB中使用悲觀鎖

要使用悲觀鎖，咱們必須關閉mysql數據庫的自動提交屬性，由於MySQL默認使用autocommit模式，也就是說，當你執行一個更新操做後，MySQL會馬上將結果進行提交。set autocommit=0;

#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;

這下成功了。