MySQL-悲觀鎖和樂觀鎖

引言                                                               

悲觀鎖和樂觀鎖指的並非一種鎖，而是一種思想，一種併發控制的方法。

在事務併發執行的情景中，可能存在多個用戶同時更新同一條數據的狀況，這可能會產生衝突致使丟失更新或者髒讀。

• 丟失更新是指一個事務的更新覆蓋了其餘事務的更新結果
• 髒讀是指當一個事務讀取了其餘事務沒有徹底執行的保存在數據庫日誌中的結果，也就是其餘事務未提交的結果。

1、悲觀鎖                                                                                     

在關係數據庫管理系統裏，悲觀併發控制（又名「悲觀鎖」，Pessimistic Concurrency Control，縮寫「PCC」）是一種併發控制的方法。它能夠阻止一個事務以影響其餘用戶的方式來修改數據。若是一個事務執行的操做讀某行數據應用了鎖，那只有當這個事務把鎖釋放，其餘事務纔可以執行與該鎖衝突的操做。悲觀併發控制主要用於數據爭用激烈的環境，以及發生併發衝突時使用鎖保護數據的成本要低於回滾事務的成本的環境中。

悲觀併發控制其實是「先取鎖再訪問」的保守策略，爲數據處理的安全提供了保證。可是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增長產生死鎖的機會；另外，在只讀型事務處理中因爲不會產生衝突，也不必使用鎖，這樣作只能增長系統負載；還有會下降了並行性，一個事務若是鎖定了某行數據，其餘事務就必須等待該事務處理完才能夠處理那行數據。(摘抄自維基百科)

2、樂觀鎖                                                         

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

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

3、兩種鎖的使用場景                                              

樂觀鎖適用於讀狀況比較多的場景，寫狀況很少的狀況下，不容易產生衝突，不加鎖會增大數據庫系統的吞吐量。

悲觀鎖適用於寫狀況比較多的場景，寫狀況多衝突也容易發生，保守一些比較好，儘管會減少吞吐量，但總比引發衝突。

4、樂觀鎖的兩種實現                                              

(1)校驗版本號

在事務執行前讀取當前數據的版本號(Version)到緩存，當前事務提交前將緩存中的版本號和當前的版本號進行對比，若兩個版本號相等則表明當前事務執行期間沒有其餘事務對數據進行修改，可提交。反之，好吧，我也沒搞清楚會怎麼樣(待更新)

(2)時間戳

 

參考：http://www.javashuo.com/article/p-dshfwowa-et.html和維基百科。