全面解讀：騰訊 CDB 內核特性與優化實踐

簡懷兵，騰訊雲數據庫高級工程師，負責騰訊雲 CDB 內核及基礎設施建設，從事 MySQL 內核開發工做 8 年，具備豐富的優化經驗；在分佈式存儲等領域有豐富經驗。

TxSQL，是騰訊 CDB（Cloud Database 雲數據庫）的內核，由開源的數據庫 MySQL 分支發展而來。

本文會從四個方面來對 TxSQL（騰訊CDB內核）進行解讀，分別是：

• TxSQL 的發展歷程
• TxSQL 的特性功能
• TxSQL 的深度優化
• TxSQL 的演進計劃

1、TxSQL 的發展歷程

TxSQL 最先是用於騰訊的內部業務，像騰訊遊戲當中使用的數據庫。

而後受業務驅動，被用於互聯網金融支付業務。支付業務對數據庫提出了更高的要求，尤爲是在性能和穩定性方面。

再後來，運營推進其發展，針對外部需求加上更多功能。你們比較熟悉的可能就是 RDS（騰訊雲）。

因此基本上 TxSQL 的發展歷程就是首先從內部業務到互聯網金融，再到如今 RDS 上蓬勃發展的趨勢。這三個業務的維護慢慢驅動造成了一個騰訊內部本身維護的數據庫分支 —— TxSQL。

2、TxSQL 的特性功能

TxSQL 的特性功能有不少，在此僅列出一些你們可能比較感興趣或者是對開發者及其餘公司來講會有一些借鑑性的功能。

① 分佈式鎖服務

TxSQL 這個內核分支當中有提供一個分佈式的鎖服務。這個鎖服務是用來作什麼的呢？

首先它提供了一個和鏈接無關的鎖服務，能夠經過完整的和 MySQL 兼容的協議來使用這個鎖服務。它和如今的一些分佈式鎖服務不同，好比說 zp（ZooKeeper）。不同的地方在於：

第一是它能夠實現讓你的鎖和你的數據在一塊兒；第二是能夠用原生的徹底兼容 MySQL 的協議來使用這個鎖服務。因此它提供的實際上是兩個不同的東西。            

好比說有時要部署一個 MySQL，須要一個比較高可用的集羣，同時還要去作一些後期的維護，有了分佈式的鎖服務之後，不須要作額外的應用，只須要在 RDS 裏面操做，後面所用的高可用、運維等一些東西都已經包含在 MySQL 這個運維的體系當中了。

② 超級 root 帳號

這個功能比較有意思。拿 MySQL 來講，在公有云上申請了 MySQL 實例時，後端會負責作主從複製、備份，可是作這些工做都須要有一個 MySQL 帳號。假如如今已經申請了一個數據庫實例，但有時候因爲誤操做或其它緣由，會把一個不屬於本身的業務賬號刪掉，由此會影響網站後端作備份這些功能。

TxSQL 提供的這個 root 帳號，實際上是 MySQL 的虛擬帳號。即使把 MySQL 的系統表 delete 之後，也不會有任何影響，後端的業務仍是能夠鏈接上來，繼續運營、運維。

③ OSC(Online Schema Change)

所謂 OSC，就是 Online Schema Change。用過數據庫的人都知道，尤爲是互聯網業務，變化很泛，業務需求在變，產品形態也在變。此時就有對數據庫的表結構、規範結構進行增長、刪除和字段類型修改的操做的需求。若是在原生 MySQL 中實行這樣的操做，會比較麻煩並且有風險。這個功能能夠經過改變內部的表結構來與原生的進行支持，而且能夠在線修改。

④ 帶租約的工做模式

在一些對移植性要求比較高的數據庫的應用場景下，爲了防止在同一個拓撲結構下會有多個 master 或者是有多個讀寫的狀況，能夠經過帶租約的工做模式，把每個 MySQL 的實例定位到一個具體的 multi mode 當中，就是說如今是隻讀、可讀寫仍是說查詢相似這樣的一些區分。

帶租約的工做模式，便是能夠經過外圍的一些空 paper 讓租約在整個拓撲範圍內，讓每個節點達到一個惟一肯定的狀態。

⑤ Binlog 限速插件

在 MySQL 的主從之間，通常原生的是經過獲取 node 來訪問主從複製，但這樣就會有一個問題，就是在主從之間（也就是 master 和 slave 之間）新建了一個實例，若是中斷時間比較長，而你的網絡剛開始恢復的時候，它會瞬間把你主從之間的帶寬給打滿，這可能會影響到其餘一些正常的業務邏輯。

爲了不相似這樣的問題，TxSQL提供了一個限速插件。這個插件在主從同步的時候，能夠設置閾值。所以即使在這種狀況下，也能夠保證爲業務應用預留必定的帶寬。

⑥ Super Read Only

第六個就是 Super Read Only。在 MySQL 發佈 5.5 以前，也有 Read Only 這樣的一個功能，但爲了保證訪問數據嚴格的一致性，又開發了 Super Read Only 的功能，無論是 root 帳號仍是其餘的普通用戶帳號，經過開啓這個功能均可以保證數據在預期的時候去寫，不會出現不預期的寫。

⑦ 預留 super 鏈接

這裏指的是預留 super 鏈接的權限。比方說，當你開發了一個 app，可這個 app 有 bug，它會一直去鏈接 MySQL，可是每個 MySQL 實例都是有鏈接次數限制的，因此有可能會由於這個程序的 bug，致使設置的 GET 鏈接數被佔滿了。這種狀況下，不管是 DBA 仍是運維，都沒辦法鏈接上來作一些其餘的應急措施。

所以，TxSQL 提供了這樣的一個功能，會爲預留的 super 帳號提供一些額外的鏈接，這些鏈接不能夠配置，所以即使是你的 app 有 bug 或是其餘緊急狀況下，也能夠保證這個運維的鏈接是始終均可以連上的。

⑧ 安全 Reset Master

在一般狀況下，好比主從複製正在進行時，外面 master 也正在進行一個 Reset Master 的操做，這可能會致使有些 Binlog 會被刪除，下次再來建主從的時候就會致使有一些 node 還沒同步過去就已經被刪除，所以會出現建不上主從複製的狀況。

TxSQL 會在 Reset Master 前，確保如今是沒有主從鏈接。若是必定要作這個動做，而如今又有主從鏈接，會先把主從複製上的拓撲停掉。

⑨ 數據強同步

數據強同步的封裝最先是在 MySQL 5.5 上，5.5 以前都是經過異步的方式。所謂的異步就是指 master 和 slave 之間不主從複製，比方說如今有一個 app 已經在 master 上，你提交了一個事務或一條數據，這時候把 master 的大小切到 slave 上，你會發現剛纔提交的事務有可能已經查詢不到。

爲了防止這種狀況，在 5.6 和 5.7 已經提供了半同步的功能，半同步和強同步的差異就是半同步第一次在某些比較特殊的場景仍是保護不了數據同步的一致性，第二就是它會設置一個 time out 的值，第三個就是性能方面的問題，原生的話可能性能不足。

針對一些應用對數據的一致性要求很是高，TxSQL 在 MySQL 原生半同步的基礎上進行了深度優化，確保一個事務在主庫上提交以前必定已經複製到至少一個備庫上，確保主庫宕機時數據的一致性。

⑩ 在線 GTID 升級

MySQL 5.6 已經提供了 GTID 這樣的一些特性，可是這個版本中從 非 GTID 的版本到 GTID 版本是沒有辦法比較簡單在線升級的。因此爲了確保能夠在線平滑升級，有作一些工做。

最後還有兩個特性功能，第一個是須要在某些場景下過濾其中一些功能，這就須要把一些 MyISAM 的錶轉換成 InnoDB 的表，第二個是把系統庫裏面的一些需求隱藏掉。

功能這部分就講完了，這裏列的 12 個特性功能，都是在最多見的使用場景當中對你們比較有意義的一些功能。

3、TxSQL 的深度優化

① 主從複製全鏈路優化

這個會在後面做爲一個點單獨來說，好比說在主從複製中、優化過程當中，還有不少其餘環節中作了哪些優化，有什麼效果。

② ReadView 優化

第二個是 ReadView 的優化，在最新的 MySQL 5.7.14 版本中，MySQL 官方已經有這個優化。

③ Redo Log Buffer 鎖拆分

簡單講就是之前會有一把大鎖去共享這個 Redo Log Buffer、去讀寫字段，而後都會頻繁競爭這把鎖，這就會致使在大併發的量下產生較大的性能開銷。

④ Logical Clock(MTS)

 Logical Clock，就是 MTS（multi-threaded slave）。傳統的官方 MySQL 版本是 slave 去回放，master 同步 Binlog 過來的時候，都是單線程的模式，到 5.6 之後就變成了並行。

TxSQL上作了一些正式的優化，按臨界事務提交的這個區間，只有不一樣的事務沒有的狀況下去競爭或者在同一個資源上的時候競爭，至關於把它的粒度拆分到最細。

⑤ Thread Pool

有關 Thread Pool 的功能，在 MySQL 中，通常狀況下是產生一個鏈接就會去建一個線程，該線程用 node 鏈接，這個可能跟早期的 Apache 同樣。

⑥ Redo Group Commit

Redo Group Commit，簡單的理解就是由於 TxSQL 是 IO 密集型的服務器，對於服務器，最致命的東西就是 IO、磁盤，使用傳統的機械硬盤又須要轉磁頭以定位到扇區，而這些東西的開銷都很大，所以這個功能就是爲了減小磁盤尋道和尋址的開銷。

接下來從三個維度去介紹 TxSQL 所作的改進，分別是高性能、強一致和工程化。

1. 主要改進 - 高性能

在 MySQL 內核複製的 4 個主要環節優化：

• Binlog 讀寫鎖拆分
• 網絡傳輸 Binlog 串行變並行
• 寫 RelayLog IO 合併和解鎖
• 事務回放串行變並行(MTS)

1） 高性能 - Binlog 讀寫鎖拆分

MySQL 5.6 存在的問題：

• 對 Binlog 的讀寫都要互斥，高併發(尤爲是有多個 Slave)時，是影響性能的關鍵之一；

TxSQL 的優化：

• 將讀寫分離開來，多個寫入的線程仍是在鎖保護下串行執行，每個寫入線程寫入完成後更新當前 Binlog 的長度信息，多個 Dump 線程以 Binlog 文件的長度信息爲讀取邊界，多個 Dump 線程之間並行執行。以這種方式來讓複製拓撲中的 Dump 線程發送得更快！

2） 高性能 - 傳輸 Binlog 串行變並行

MySQL 5.6 存在的問題：

• 未收到上一個 Binlog Event 的 ACK 以前，不能發送下一個 Binlog Event；
• 每一個事務須要一個 RTT，不能有效利用主從 DB 之間的帶寬，尤爲是跨園區條件下；

TxSQL 的優化：

• 將發送和 ACK 迴應的接收獨立到不一樣的線程中，因爲發送和接收都是基於 TCP 流的傳輸，因此時序性是有保障的；這樣發送線程能夠在未收 ACK 以前繼續發送，接受線程收到 ACK 後喚醒等待的線程執行相應的任務。

3） 高性能 - 寫 RelayLog 時 IO 合併和解鎖

MySQL 5.6/5.7 存在的問題：

• IO 線程和 SQL 線程競爭 RelayLog 的鎖
• 以 Binlog Event 爲單位寫文件，產生大量小 IO
• 寫 Masterinfo 文件產生額外文件 IO
• 頻繁動態內存分配和釋放

TxSQL 的優化：

• 使用讀寫邊界解除 IO 線程和 SQL 線程之間的鎖競爭
• 合併小 IO 到事務級別
• 使用 GTID 規避 Masterinfo 文件寫 IO
• 內存複用

4） 高性能 - 事務回放串行變並行(MTS)

MySQL 5.6 存在的問題：

• 事務按 Database 級別並行，併發粒度大，效率低

TxSQL 的優化：

• 在 Master 上提交無衝突的事務，均可以並行回放

2. 主要改進 - 強一致

優化 MySQL 內核半同步複製爲強同步：

• Master 提交事務前保證至少有一個 Slave 已經收到日誌
• HA 單獨處理臨界事務

存在問題：

• Master 在本地完成事務提交後再同步 Binlog，致使幻讀

1 ）強一致 - 事務不丟失和消除幻讀

MySQL 5.6 存在的問題：

• 主 DB 先提交事務再發送給 Slave, 在發送過程當中 Crash 時，主 DB 可見的事務在從 DB 不可見

TxSQL 的優化：

2） 強一致 - 臨界事務處理

HA 存在的問題：

• Master 寫 Binlog 成功，但 Binlog 同步時進程 Crash；
• Master 進程恢復時，會產生多餘的事務

TxSQL 的優化：

• Truncate 臨界事務的 Binlog 信息

 

3. 主要改進 - 工程化

1） 工程化 - 低侵入

• 業務痛點：老應用遷移成本高、風險大、沒法享受新技術紅利
• TxSQL 的方案：徹底兼容 MySQL 5.1-5.7 的複製中間件

2 ）工程化 - 健康診斷和審計

業務痛點：

• 訪問安全：IP、賬號、對象、越權操做記錄、不活躍賬號
• SQL安全：注入、寬鬆條件的修改\刪除、低效SQL

TxSQL的方案：

• 對訪問和SQL相關安全事件進行記錄
• 對異常事件進行攔截或者預警
• 提供SQL級別耗時統計

3 ）工程化 - 兼容

業務痛點：    

• 不一樣業務使用不一樣分支的 MySQL，遷移難
• 不一樣業務使用不一樣版本的 MySQL，升級難

TxSQL 的方案：

• 支持主流 MySQL 分支
• 支持在線升級
• 支持業務的持續集成

4、TxSQL 的演進計劃

首先是實現用戶使用的基本功能，而後在此基礎上進行深度優化，也就是上面提到的那些。未來，會針對架構進行優化。