一、併發控制

為啥要進行併發控制？

併發的任務對同一個臨界資源進行操作，如果不採取措施，可能導致不一致，故必須進行併發控制（Concurrency Control）。

 

技術上，通常如何進行併發控制？

通過併發控制保證資料一致性的常見手段有：

• 鎖（Locking）

• 資料多版本（Multi Versioning）

 

二、鎖

如何使用普通鎖保證一致性？

普通鎖，被使用最多：

(1)操作資料前，鎖住，實施互斥，不允許其他的併發任務操作；

(2)操作完成後，釋放鎖，讓其他任務執行；

如此這般，來保證一致性。

 

普通鎖存在什麼問題？

簡單的鎖住太過粗暴，連“讀任務”也無法並行，任務執行過程本質上是序列的。

 

於是出現了共享鎖與排他鎖：

• 共享鎖（Share Locks，記為S鎖），讀取資料時加S鎖

• 排他鎖（eXclusive Locks，記為X鎖），修改資料時加X鎖

 

共享鎖與排他鎖的玩法是：

• 共享鎖之間不互斥，簡記為：讀讀可以並行

• 排他鎖與任何鎖互斥，簡記為：寫讀，寫寫不可以並行

 

可以看到，一旦寫資料的任務沒有完成，資料是不能被其他任務讀取的，這對併發度有較大的影響。

畫外音：對應到資料庫，可以理解為，寫事務沒有提交，讀相關資料的select也會被阻塞。

 

有沒有可能，進一步提高併發呢？

即使寫任務沒有完成，其他讀任務也可能併發，這就引出了資料多版本。

 

三、資料多版本

資料多版本是一種能夠進一步提高併發的方法，它的核心原理是：

（1）寫任務發生時，將資料克隆一份，以版本號區分；

（2）寫任務操作新克隆的資料，直至提交；

（3）併發讀任務可以繼續讀取舊版本的資料，不至於阻塞；

如上圖：

1. 最開始資料的版本是V0；

2. T1時刻發起了一個寫任務，這是把資料clone了一份，進行修改，版本變為V1，但任務還未完成；

3. T2時刻併發了一個讀任務，依然可以讀V0版本的資料；

4. T3時刻又併發了一個讀任務，依然不會阻塞；

 

可以看到，資料多版本，通過“讀取舊版本資料”能夠極大提高任務的併發度。

 

提高併發的演進思路，就在如此：

• 普通鎖，本質是序列執行

• 讀寫鎖，可以實現讀讀併發

• 資料多版本，可以實現讀寫併發

畫外音：這個思路，比整篇文章的其他技術細節更重要，希望大家牢記。

 

好，對應到InnoDB上，具體是怎麼玩的呢？

 

四、redo, undo,回滾段

在進一步介紹InnoDB如何使用“讀取舊版本資料”極大提高任務的併發度之前，有必要先介紹下redo日誌，undo日誌，回滾段（rollback segment）。

 

為什麼要有redo日誌？

資料庫事務提交後，必須將更新後的資料刷到磁碟上，以保證ACID特性。磁碟隨機寫效能較低，如果每次都刷盤，會極大影響資料庫的吞吐量。

 

優化方式是，將修改行為先寫到redo日誌裡（此時變成了順序寫），再定期將資料刷到磁碟上，這樣能極大提高效能。

畫外音：這裡的架構設計方法是，隨機寫優化為順序寫，思路更重要。

 

假如某一時刻，資料庫崩潰，還沒來得及刷盤的資料，在資料庫重啟後，會重做redo日誌裡的內容，以保證已提交事務對資料產生的影響都刷到磁碟上。

 

一句話，redo日誌用於保障，已提交事務的ACID特性。

 

為什麼要有undo日誌？

資料庫事務未提交時，會將事務修改資料的映象（即修改前的舊版本）存放到undo日誌裡，當事務回滾時，或者資料庫奔潰時，可以利用undo日誌，即舊版本資料，撤銷未提交事務對資料庫產生的影響。

畫外音：更細節的，

對於insert操作，undo日誌記錄新資料的PK(ROW_ID)，回滾時直接刪除；

對於delete/update操作，undo日誌記錄舊資料row，回滾時直接恢復；

他們分別存放在不同的buffer裡。

 

一句話，undo日誌用於保障，未提交事務不會對資料庫的ACID特性產生影響。

 

什麼是回滾段？

儲存undo日誌的地方，是回滾段。

 

undo日誌和回滾段和InnoDB的MVCC密切相關，這裡舉個例子展開說明一下。

 

栗子：

t(id PK, name);

 

資料為：

1, shenjian

2, zhangsan

3, lisi

此時沒有事務未提交，故回滾段是空的。

 

接著啟動了一個事務：

start trx;

delete (1, shenjian);

update set(3, lisi) to (3, xxx);

insert (4, wangwu);

並且事務處於未提交的狀態。

可以看到：

(1)被刪除前的(1, shenjian)作為舊版本資料，進入了回滾段；

(2)被修改前的(3, lisi)作為舊版本資料，進入了回滾段；

(3)被插入的資料，PK(4)進入了回滾段；

 

接下來，假如事務rollback，此時可以通過回滾段裡的undo日誌回滾。

畫外音：假設事務提交，回滾段裡的undo日誌可以刪除。

 

可以看到：

(1)被刪除的舊資料恢復了；

(2)被修改的舊資料也恢復了；

(3)被插入的資料，刪除了；

事務回滾成功，一切如故。

 

四、InnoDB是基於多版本併發控制的儲存引擎

《大資料量，高併發量的網際網路業務，一定要使用InnoDB》提到，InnoDB是高併發網際網路場景最為推薦的儲存引擎，根本原因，就是其多版本併發控制（Multi Version Concurrency Control, MVCC）。行鎖，併發，事務回滾等多種特性都和MVCC相關。

 

MVCC就是通過“讀取舊版本資料”來降低併發事務的鎖衝突，提高任務的併發度。

 

核心問題：

舊版本資料儲存在哪裡？

儲存舊版本資料，對MySQL和InnoDB原有架構是否有巨大沖擊？

通過上文undo日誌和回滾段的鋪墊，這兩個問題就非常好回答了：

(1)舊版本資料儲存在回滾段裡；

(2)對MySQL和InnoDB原有架構體系衝擊不大；

 

InnoDB的核心，會對所有row資料增加三個內部屬性：

(1)DB_TRX_ID，6位元組，記錄每一行最近一次修改它的事務ID；

(2)DB_ROLL_PTR，7位元組，記錄指向回滾段undo日誌的指標；

(3)DB_ROW_ID，6位元組，單調遞增的行ID；

 

InnoDB為何能夠做到這麼高的併發？

回滾段裡的資料，其實是歷史資料的快照（snapshot），這些資料是不會被修改，select可以肆無忌憚的併發讀取他們。

 

快照讀（Snapshot Read），這種一致性不加鎖的讀（Consistent Nonlocking Read），就是InnoDB併發如此之高的核心原因之一。

 

這裡的一致性是指，事務讀取到的資料，要麼是事務開始前就已經存在的資料（當然，是其他已提交事務產生的），要麼是事務自身插入或者修改的資料。

 

什麼樣的select是快照讀？

除非顯示加鎖，普通的select語句都是快照讀，例如：

select * from t where id>2;

 

這裡的顯示加鎖，非快照讀是指：

select * from t where id>2 lock in share mode;

select * from t where id>2 for update;

 

問題來了，這些顯示加鎖的讀，是什麼讀？會加什麼鎖？和事務的隔離級別又有什麼關係？

 

本節的內容已經夠多了，且聽下回分解。

 

總結

(1)常見併發控制保證資料一致性的方法有鎖，資料多版本；

(2)普通鎖序列，讀寫鎖讀讀並行，資料多版本讀寫並行；

(3)redo日誌保證已提交事務的ACID特性，設計思路是，通過順序寫替代隨機寫，提高併發；

(4)undo日誌用來回滾未提交的事務，它儲存在回滾段裡；

(5)InnoDB是基於MVCC的儲存引擎，它利用了儲存在回滾段裡的undo日誌，即資料的舊版本，提高併發；

(6)InnoDB之所以併發高，快照讀不加鎖；

(7)InnoDB所有普通select都是快照讀；

畫外音：本文的知識點均基於MySQL5.6。