數據庫中的樂觀鎖與悲觀鎖

悲觀鎖

當咱們要對一個數據庫中的一條數據進行修改的時候，爲了不同時被其餘人修改，最好的辦法就是直接對該數據進行加鎖以防止併發。

這種藉助數據庫鎖機制在修改數據以前先鎖定，再修改的方式被稱之爲悲觀併發控制（又名「悲觀鎖」，Pessimistic Concurrency Control，縮寫「PCC」）。

之因此叫作悲觀鎖，是由於這是一種對數據的修改抱有悲觀態度的併發控制方式。咱們通常認爲數據被併發修改的機率比較大，因此須要在修改以前先加鎖。

悲觀併發控制其實是「先取鎖再訪問」的保守策略，爲數據處理的安全提供了保證。


可是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增長產生死鎖的機會；

另外，還會下降並行性，一個事務若是鎖定了某行數據，其餘事務就必須等待該事務處理完才能夠處理那行數據。

樂觀鎖

樂觀鎖（ Optimistic Locking ） 是相對悲觀鎖而言的，樂觀鎖假設數據通常狀況下不會形成衝突，因此在數據進行提交更新的時候，纔會正式對數據的衝突與否進行檢測，若是發現衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去作。

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

樂觀併發控制相信事務之間的數據競爭(data race)的機率是比較小的，所以儘量直接作下去，直到提交的時候纔去鎖定，因此不會產生任何鎖和死鎖。

悲觀鎖實現方式

悲觀鎖的實現，每每依靠數據庫提供的鎖機制。在數據庫中，悲觀鎖的流程以下：

• 在對記錄進行修改前，先嚐試爲該記錄加上排他鎖（exclusive locking）。
• 若是加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者拋出異常。具體響應方式由開發者根據實際須要決定。
• 若是成功加鎖，那麼就能夠對記錄作修改，事務完成後就會解鎖了。
• 其間若是有其餘事務對該記錄作加鎖的操做，都要等待當前事務解鎖或直接拋出異常。

咱們拿比較經常使用的MySql Innodb引擎舉例，來講明一下在SQL中如何使用悲觀鎖。

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

咱們舉一個簡單的例子，如淘寶下單過程當中扣減庫存的需求說明一下如何使用悲觀鎖：

//0.開始事務
begin; 
//1.查詢出商品庫存信息
select quantity from items where id=1 for update;
//2.修改商品庫存爲2
update items set quantity=2 where id = 1;
//3.提交事務
commit;

以上，在對id = 1的記錄修改前，先經過for update的方式進行加鎖，而後再進行修改。這就是比較典型的悲觀鎖策略。

若是以上修改庫存的代碼發生併發，同一時間只有一個線程能夠開啓事務並得到id=1的鎖，其它的事務必須等本次事務提交以後才能執行。這樣咱們能夠保證當前的數據不會被其它事務修改。

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

樂觀鎖實現方式

使用樂觀鎖就不須要藉助數據庫的鎖機制了。

樂觀鎖的概念中其實已經闡述了他的具體實現細節：主要就是兩個步驟：衝突檢測和數據更新。其實現方式有一種比較典型的就是Compare and Swap(CAS)技術。

CAS是項樂觀鎖技術，當多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程並不會被掛起，而是被告知此次競爭中失敗，並能夠再次嘗試。

好比前面的扣減庫存問題，經過樂觀鎖能夠實現以下：

//查詢出商品庫存信息，quantity = 3
select quantity from items where id=1
//修改商品庫存爲2
update items set quantity=2 where id=1 and quantity = 3;

以上，咱們在更新以前，先查詢一下庫存表中當前庫存數（quantity），而後在作update的時候，以庫存數做爲一個修改條件。當咱們提交更新的時候，判斷數據庫表對應記錄的當前庫存數與第一次取出來的庫存數進行比對，若是數據庫表當前庫存數與第一次取出來的庫存數相等，則予以更新，不然認爲是過時數據。

可是以上更新語句存在一個比較重要的問題，即ABA問題。

好比說一個線程1從數據庫中取出庫存數3，這時候另外一個線程2也從數據庫中庫存數3，而且線程2進行了一些操做將庫存數變成了2，緊接着又將庫存數變成3，這時候線程1進行CAS操做發現數據庫中仍然是3，而後線程1操做成功。儘管線程1的CAS操做成功，可是不表明這個過程就是沒有問題的。

有一個比較好的辦法能夠解決ABA問題，那就是經過一個單獨的能夠順序遞增的version字段。改成如下方式便可：

//查詢出商品信息，version = 1
select version from items where id=1
//修改商品庫存爲2
update items set quantity=2,version = 3 where id=1 and version = 2;

樂觀鎖每次在執行數據的修改操做時，都會帶上一個版本號，一旦版本號和數據的版本號一致就能夠執行修改操做並對版本號執行+1操做，不然就執行失敗。由於每次操做的版本號都會隨之增長，因此不會出現ABA問題，由於版本號只會增長不會減小。

除了version之外，還可使用時間戳，由於時間戳自然具備順序遞增性。

以上SQL其實仍是有必定的問題的，就是一旦高併發的時候，就只有一個線程能夠修改爲功，那麼就會存在大量的失敗。

對於像淘寶這樣的電商網站，高併發是常有的事，總讓用戶感知到失敗顯然是不合理的。因此，仍是要想辦法減少樂觀鎖的粒度的。

有一條比較好的建議，能夠減少樂觀鎖力度，最大程度的提高吞吐率，提升併發能力！以下：

//修改商品庫存
update item 
set quantity=quantity - 1 
where id = 1 and quantity - 1 > 0

以上SQL語句中，若是用戶下單數爲1，則經過quantity - 1 > 0的方式進行樂觀鎖控制。

以上update語句，在執行過程當中，會在一次原子操做中本身查詢一遍quantity的值，並將其扣減掉1。

高併發環境下鎖粒度把控是一門重要的學問，選擇一個好的鎖，在保證數據安全的狀況下，能夠大大提高吞吐率，進而提高性能。

如何選擇

在樂觀鎖與悲觀鎖的選擇上面，主要看下二者的區別以及適用場景就能夠了。

一、樂觀鎖並未真正加鎖，效率高。一旦鎖的粒度掌握很差，更新失敗的機率就會比較高，容易發生業務失敗。

二、悲觀鎖依賴數據庫鎖，效率低。更新失敗的機率比較低。

隨着互聯網三高架構（高併發、高性能、高可用）的提出，悲觀鎖已經愈來愈少的被使用到生產環境中了，尤爲是併發量比較大的業務場景。