InnoDB併發如此高，緣由居然在這？

InnoDB併發如此高，緣由居然在這？

原創： 58沈劍 架構師之路 昨天

《InnoDB行鎖，如何鎖住一條不存在的記錄？》埋了一個坑，沒想到評論反響劇烈，你們都但願深挖下去。原計劃寫寫InnoDB的鎖結束這個case，既然呼聲這麼高，乾脆全盤系統性的寫寫InnoDB的併發控制，鎖，事務模型好了。

 

體系相對宏大，一篇確定寫不完，容我娓娓道來，通俗地說清楚前因後果。

 

1、併發控制

爲啥要進行併發控制？

併發的任務對同一個臨界資源進行操做，若是不採起措施，可能致使不一致，故必須進行併發控制（Concurrency Control）。

 

技術上，一般如何進行併發控制？

經過併發控制保證數據一致性的常見手段有：

• 鎖（Locking）

• 數據多版本（Multi Versioning）

 

2、鎖

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

普通鎖，被使用最多：

(1)操做數據前，鎖住，實施互斥，不容許其餘的併發任務操做；

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

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

 

普通鎖存在什麼問題？

簡單的鎖住太過粗暴，連「讀任務」也沒法並行，任務執行過程本質上是串行的。

 

因而出現了共享鎖與排他鎖：

• 共享鎖（Share Locks，記爲S鎖），讀取數據時加S鎖

• 排他鎖（eXclusive Locks，記爲X鎖），修改數據時加X鎖

 

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

• 共享鎖之間不互斥，簡記爲：讀讀能夠並行

• 排他鎖與任何鎖互斥，簡記爲：寫讀，寫寫不能夠並行

 

能夠看到，一旦寫數據的任務沒有完成，數據是不能被其餘任務讀取的，這對併發度有較大的影響。

畫外音：對應到數據庫，能夠理解爲，寫事務沒有提交，讀相關數據的select也會被阻塞。

 

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

即便寫任務沒有完成，其餘讀任務也可能併發，這就引出了數據多版本。

 

3、數據多版本

數據多版本是一種可以進一步提升併發的方法，它的核心原理是：

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

（2）寫任務操做新克隆的數據，直至提交；

（3）併發讀任務能夠繼續讀取舊版本的數據，不至於阻塞；

如上圖：

1. 最開始數據的版本是V0；

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

3. T2時刻併發了一個讀任務，依然能夠讀V0版本的數據；

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

 

能夠看到，數據多版本，經過「讀取舊版本數據」可以極大提升任務的併發度。

 

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

• 普通鎖，本質是串行執行

• 讀寫鎖，能夠實現讀讀併發

• 數據多版本，能夠實現讀寫併發

畫外音：這個思路，比整篇文章的其餘技術細節更重要，但願你們牢記。

 

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

 

4、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)被插入的數據，刪除了；

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

 

5、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。

 

但願你們有收穫，下一篇繼續深刻InnoDB的鎖。

 

但願通俗的技術文被更多人看到，求幫轉。

 

相關文章：

《InnoDB，5項最佳實踐，知其因此然？》