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

 

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

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

1、併發控制

(1) 爲啥要進行併發控制?

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

(2) 技術上，一般如何進行併發控制?

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

• 鎖(Locking)
• 數據多版本(Multi Versioning)

2、鎖

(1) 如何使用普通鎖保證一致性?

普通鎖，被使用最多：

• 操做數據前，鎖住，實施互斥，不容許其餘的併發任務操做;
• 操做完成後，釋放鎖，讓其餘任務執行;

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

(2) 普通鎖存在什麼問題?

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

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

• 共享鎖(Share Locks，記爲S鎖)，讀取數據時加S鎖
• 排他鎖(eXclusive Locks，記爲X鎖)，修改數據時加X鎖

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

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

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

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

(3) 有沒有可能，進一步提升併發呢?

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

3、數據多版本

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

• 寫任務發生時，將數據克隆一份，以版本號區分;
• 寫任務操做新克隆的數據，直至提交;
• 併發讀任務能夠繼續讀取舊版本的數據，不至於阻塞;

 

如上圖：

• 最開始數據的版本是V0;
• T1時刻發起了一個寫任務，這是把數據clone了一份，進行修改，版本變爲V1，但任務還未完成;
• T2時刻併發了一個讀任務，依然能夠讀V0版本的數據;
• T3時刻又併發了一個讀任務，依然不會阻塞;

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

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

• 普通鎖，本質是串行執行
• 讀寫鎖，能夠實現讀讀併發
• 數據多版本，能夠實現讀寫併發

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

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

4、redo, undo,回滾段

在進一步介紹InnoDB如何使用「讀取舊版本數據」極大提升任務的併發度以前，有必要先介紹下redo日誌，undo日誌，回滾段(rollback segment)。

(1) 爲何要有redo日誌?

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

優化方式是，將修改行爲先寫到redo日誌裏(此時變成了順序寫)，再按期將數據刷到磁盤上，這樣能極大提升性能。

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

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

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

(2) 爲何要有undo日誌?

數據庫事務未提交時，會將事務修改數據的鏡像(即修改前的舊版本)存放到undo日誌裏，當事務回滾時，或者數據庫奔潰時，能夠利用undo日誌，即舊版本數據，撤銷未提交事務對數據庫產生的影響。

畫外音：更細節的，

• 對於insert操做，undo日誌記錄新數據的PK(ROW_ID)，回滾時直接刪除;
• 對於delete/update操做，undo日誌記錄舊數據row，回滾時直接恢復;

他們分別存放在不一樣的buffer裏。

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

(3) 什麼是回滾段?

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

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

栗子：

1. t(id PK, name)

數據爲：

• shenjian
• zhangsan
• lisi

 

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

接着啓動了一個事務：

1. start trx;
2. delete (1, shenjian);
3. update set(3, lisi) to (3, xxx);
4. insert (4, wangwu)

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

 

能夠看到：

• 被刪除前的(1, shenjian)做爲舊版本數據，進入了回滾段;
• 被修改前的(3, lisi)做爲舊版本數據，進入了回滾段;
• 被插入的數據，PK(4)進入了回滾段;

接下來，假如事務rollback，此時能夠經過回滾段裏的undo日誌回滾。

畫外音：假設事務提交，回滾段裏的undo日誌能夠刪除。

 

能夠看到：

• 被刪除的舊數據恢復了;
• 被修改的舊數據也恢復了;
• 被插入的數據，刪除了;

 

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

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

《大數據量，高併發量的互聯網業務，必定要使用InnoDB》提到，InnoDB是高併發互聯網場景最爲推薦的存儲引擎，根本緣由，就是其多版本併發控制(Multi Version Concurrency Control, MVCC)。行鎖，併發，事務回滾等多種特性都和MVCC相關。

MVCC就是經過「讀取舊版本數據」來下降併發事務的鎖衝突，提升任務的併發度。

(1) 核心問題：舊版本數據存儲在哪裏?

存儲舊版本數據，對MySQL和InnoDB原有架構是否有巨大沖擊?

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

• 舊版本數據存儲在回滾段裏;
• 對MySQL和InnoDB原有架構體系衝擊不大;

InnoDB的內核，會對全部row數據增長三個內部屬性：

• DB_TRX_ID，6字節，記錄每一行最近一次修改它的事務ID;
• DB_ROLL_PTR，7字節，記錄指向回滾段undo日誌的指針;
• DB_ROW_ID，6字節，單調遞增的行ID;

(2) InnoDB爲什麼可以作到這麼高的併發?

回滾段裏的數據，實際上是歷史數據的快照(snapshot)，這些數據是不會被修改，select能夠肆無忌憚的併發讀取他們。

快照讀(Snapshot Read)，這種一致性不加鎖的讀(Consistent Nonlocking Read)，就是InnoDB併發如此之高的核心緣由之一。

這裏的一致性是指，事務讀取到的數據，要麼是事務開始前就已經存在的數據(固然，是其餘已提交事務產生的)，要麼是事務自身插入或者修改的數據。

(3) 什麼樣的select是快照讀?

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

1. select * from t where id>2

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

1. select * from t where id>2 lock in share mode
2. select * from t where id>2 for update

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

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

5、總結

• 常見併發控制保證數據一致性的方法有鎖，數據多版本;
• 普通鎖串行，讀寫鎖讀讀並行，數據多版本讀寫並行;
• redo日誌保證已提交事務的ACID特性，設計思路是，經過順序寫替代隨機寫，提升併發;
• undo日誌用來回滾未提交的事務，它存儲在回滾段裏;
• InnoDB是基於MVCC的存儲引擎，它利用了存儲在回滾段裏的undo日誌，即數據的舊版本，提升併發;
• InnoDB之因此併發高，快照讀不加鎖;
• InnoDB全部普通select都是快照讀;

順便給你們推薦一個Java架構方面的交流學習羣：698581634，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系，主要針對Java開發人員提高本身，突破瓶頸，相信你來學習，會有提高和收穫。在這個羣裏會有你須要的內容  朋友們請抓緊時間加入進來吧。