前言
在上一個章節5分鐘帶你讀懂事務隔離性與隔離級別 的最後，其實我們已經提到了鎖的概念。本章節接下來將主要介紹以下資料庫悲觀鎖與樂觀鎖的相關知識。如有錯誤還請大家及時指出~
問題：
- 為什麼需要鎖？
- 什麼是悲觀鎖？
- 什麼是樂觀鎖？
- 悲觀鎖與樂觀鎖區別與聯絡？
- 悲觀鎖與樂觀鎖的使用場景？
為什麼需要鎖？
在併發環境下，如果多個客戶端訪問同一條資料，此時就會產生資料不一致的問題，如何解決，通過加鎖的機制，常見的有兩種鎖，樂觀鎖和悲觀鎖，可以在一定程度上解決併發訪問。
1. 悲觀鎖（Pessimistic Lock）
1.1 定義
百度百科：
悲觀鎖，正如其名，具有強烈的獨佔和排他特性。它指的是對資料被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制（也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改資料）。
其他知識點
悲觀鎖主要是共享鎖或排他鎖
共享鎖又稱為讀鎖，簡稱S鎖，顧名思義，共享鎖就是多個事務對於同一資料可以共享一把鎖，都能訪問到資料，但是隻能讀不能修改。
排他鎖又稱為寫鎖，簡稱X鎖，顧名思義，排他鎖就是不能與其他所並存，如一個事務獲取了一個資料行的排他鎖，其他事務就不能再獲取該行的其他鎖，包括共享鎖和排他鎖，但是獲取排他鎖的事務是可以對資料就行讀取和修改。
1.2 案例分析
使用場景舉例：以MySQL InnoDB為例
作為演示，我們繼續使用之前的資料庫表：product表
| productId | productName | productPrice | productCount |
|---|---|---|---|
| 1 | 小米 | 1999 | 100 |
| 2 | 魅族 | 1999 | 100 |
首先我們需要set autocommit=0，即不允許自動提交
有看過上一篇文章5分鐘帶你讀懂事務隔離性與隔離級別 的同學，可以看到最後我們使用事務隔離級別時，所引申出來的根本問題就是可以通過鎖機制解決。
問題
在併發情況下回導致資料一致性的問題： 如果有A、B兩個使用者需要搶productId =1的小米手機，A、B使用者都查詢小米手機數量是100，A購買後修改商品的數量為99，B購買後修改數量為99。
用法
每次獲取小米手機時，對該商品加排他鎖。也就是在使用者A獲取獲取 id=1 的小米手機資訊時對該行記錄加鎖，期間其他使用者阻塞等待訪問該記錄。程式碼如下：
start transaction；
select p.productCount from product p where p.productId = 1 for update;
update product p set p.productCount=p.productCount-1 where p.productId=1 ;
commit;
複製程式碼操作
下面同時開啟兩個視窗模擬2個使用者併發訪問資料庫
| 時間軸 | 事務A | 事務B |
|---|---|---|
| T1 | start transaction; | |
| T2 | select p.productCount from product p where p.productId = 1 for update; | |
| T3 | start transaction; | |
| T4 | select p.productCount from product p where p.productId = 1 for update;(等待中...) |
流程說明
- 使用者A start transaction開啟一個事物。前一步我們關閉了mysql的autocommit，所以需要手動控制事務的提交。
- 在獲得小米手機資訊（productId = 1 ）時，進行資料加鎖操作（for update）。與普通查詢方式不同，我們使用了
select…for update的方式，這樣就通過資料庫實現了悲觀鎖。在這個update事務提交之前其他外界是不能修改這條資料的，但是這種處理方式效率比較低，一般不推薦使用。 - 使用者B start transaction開啟一個事物。
- 使用者B 也進行查詢操作，此時處於等待中（阻塞狀態）。ps:需要等待使用者A事務提交後，才會執行。
注意：在事務中，只有select…for update(排他鎖) 或lock in share mode(共享鎖) 操作同一個資料時才會等待其它事務結束後才執行，一般select... 則不受此影響。例如在 T3中執行select p.productCount from product p where p.productId = 1;則能正常查詢出資料，不會受第一個事務的影響。
2. 樂觀鎖（Optimistic Lock）
2.1 定義
百度百科：
樂觀鎖機制採取了更加寬鬆的加鎖機制。樂觀鎖是相對悲觀鎖而言，也是為了避免資料庫幻讀、業務處理時間過長等原因引起資料處理錯誤的一種機制，但樂觀鎖不會刻意使用資料庫本身的鎖機制，而是依據資料本身來保證資料的正確性。
其他知識點
實現樂觀鎖一般來說有以下2種方式：
-
使用版本號 使用資料版本（Version）記錄機制實現，這是樂觀鎖最常用的一種實現方式。何謂資料版本？即為資料增加一個版本標識，一般是通過為資料庫表增加一個數字型別的 “version” 欄位來實現。當讀取資料時，將version欄位的值一同讀出，資料每更新一次，對此version值加一。當我們提交更新的時候，判斷資料庫表對應記錄的當前版本資訊與第一次取出來的version值進行比對，如果資料庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期資料。
-
使用時間戳 樂觀鎖定的第二種實現方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加一個欄位，名稱無所謂，欄位型別使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一致則OK，否則就是版本衝突。
2.2 案例分析
使用場景舉例：以MySQL InnoDB為例
作為演示，我們繼續使用之前的資料庫表：product表
| productId | productName | productPrice | productCount | version |
|---|---|---|---|---|
| 1 | 小米 | 1999 | 100 | 1 |
| 2 | 魅族 | 1999 | 100 | 2 |
我們以版本號實現的方式進行說明。
操作
查詢當前事務隔離級別：
SELECT @@tx_isolation;
結果：
REPEATABLE-READ
複製程式碼下面同時開啟兩個視窗模擬2個使用者併發訪問資料庫
第一種測試
| 時間軸 | 使用者A | 使用者B |
|---|---|---|
| T1 | start transaction; | |
| T2 | select * from product p where p.productId = 1;(productCount=100) | |
| T3 | update product p set p.productCount = 99,version=version+1 where p.productId = 1 and version = 1;(受影響的行: 1) | |
| T4 | start transaction; | |
| T5 | select * from product p where p.productId = 1;(productCount=100) | |
| T6 | update product p set p.productCount = 99,version=version+1 where p.productId = 1 and version = 1;(等待中...) | |
| T7 | commit; | |
| T8 | T6執行(受影響的行: 0) | |
| T9 | commit; |
流程說明
- 事務A開啟事務。
- 事務A查詢當前小米手機數量為100。
- 事務A購買小米手機，小米手機數量更新為99。(此時並未提交事務)。
- 事務B開啟事務。
- 事務B查詢當前小米手機數量為100。
- 事務B購買小米手機，小米手機數量更新為99。注意：此時處於阻塞狀態。
- 事務A提交事務。
- 此時第六步執行完畢，但並未成功(受影響的行: 0)。
- 事務B提交事務。
第二種測試
| 時間軸 | 使用者A | 使用者B |
|---|---|---|
| T1 | select * from product p where p.productId = 1;(productCount=100) | |
| T2 | update product p set p.productCount = 99,version=version+1 where p.productId = 1 and version = 1;(受影響的行: 1) | |
| T3 | select * from product p where p.productId = 1;(productCount=100) | |
| T4 | update product p set p.productCount = 99,version=version+1 where p.productId = 1 and version = 1;(受影響的行: 0) |
樂觀鎖小結
- 使用者B修改資料的時候，受影響行數為0，對業務來說，及更新失敗。這時候我們只需要告訴使用者購買失敗，重新查詢一遍即可。
- 對比第一種和第二種測試，我們會發現第一種測試，將update語句放入事務中會出現阻塞的情況，而第二種測試不會出現阻塞情況。這是為什麼呢？update其實在不在事務中都無所謂，在內部是這樣的：update是單執行緒的，及如果一個執行緒對一條資料進行update操作，會獲得鎖，其他執行緒如果要對同一條資料操作會阻塞，直到這個執行緒update成功後釋放鎖。
樂觀鎖不需要資料庫底層的支援！
3. 適用場景
悲觀鎖
比較適合寫入操作比較頻繁的場景，如果出現大量的讀取操作，每次讀取的時候都會進行加鎖，這樣會增加大量的鎖的開銷，降低了系統的吞吐量。
樂觀鎖
比較適合讀取操作比較頻繁的場景，如果出現大量的寫入操作，資料發生衝突的可能性就會增大，為了保證資料的一致性，應用層需要不斷的重新獲取資料，這樣會增加大量的查詢操作，降低了系統的吞吐量。
文末
本章節主要簡單介紹了資料庫中樂觀鎖與悲觀鎖的相關知識，後續我們將會繼續介紹資料庫中的其他鎖以及相關知識。例如行鎖、表鎖、死鎖、
歡迎關注公眾號：Coder程式設計 獲取最新原創技術文章和相關免費學習資料，隨時隨地學習技術知識！
參考文章：
chenzhou123520.iteye.com/blog/186095…
chenzhou123520.iteye.com/blog/186340…