5月11日，國內數據庫技術盛會——2017第八屆中國數據庫技術大會(DTCC2017)拉開帷幕。本屆大會以“數據驅動 價值發現”為主題，吸引5000多名IT數據庫人群、大數據從業人員、廣大互聯網人士。騰訊高級工程師、騰訊云布道師張青林進行了題為《騰訊云CDB的核彈頭——TXSQL》主題演講。

嘉賓介紹：張青林，騰訊云布道師、MySQL架構師，隸屬騰訊TEG-基礎架構部-數據庫內核研發團隊，專注于MySQL內核研發&相關架構工作，有著服務多個10W級QPS客戶的數據庫優化及穩定性維護經驗。

在本次主題演講中，張青林主要從概覽、內核研發、云上實踐、未來發展方向四個方面介紹了Tencent MySQL(TXSQL)在騰訊云發展過程中遇到的各種問題，以及在解決這些問題的過程中TXSQL內核所做的一系列優化，包括read_view優化、Lock_log拆分、分布式token鎖、Redo log鎖拆分、Binlog限速等功能，從功能、性能和穩定性上對TXSQL進行深入的解析。

TXSQL內核版本擁有更高的性能、更強的穩定性，同時提供Oracle MySQL企業級版本才擁有的特性，對內支持集團內部業務的發展，對外提供強有力的竟爭力，大大提升了騰訊云在業界的影響力，贏得了客戶的信任與口碑，積極的推動了騰訊云的快速發展。

TXSQL概覽

什么是TXSQL?為什么有TXSQL?

TXSQL是Tencent MySQL的簡稱，是TEG基礎架構部CDB(Cloud DataBase)團隊在近十年發展過程中衍生出來的一個對MySQL內核源碼深度定制、對官方MySQL版本進行二次開發的項目。其主要目的是在保證線上穩定性的同時，滿足業務對數據庫的各種需求。

TXSQL的服務對象是公司內部用戶和騰訊云上小至數G大至數百T的外部客戶。TXSQL是支撐這些業務平穩運行的關鍵基石，促進開源數據庫技術發展。

 

圖1

TXSQL內核研發

TXSQL read view優化

read view又稱讀視圖，用于存儲事務創建時的活躍事務集合。當事務創建時，線程會對trx_sys上全局鎖，然后遍歷當前活躍事務列表，將當前活躍事務的ID存儲在數組中的同時，記錄***事務low_limit_id&最小事務 high_limit_id&最小序列化事務low_limit_no。

當事務執行時，凡是大于low_limit_id的數據對于事務是不可見的，凡是事務小于high_limit_id的數據都是可見的，事務ID是read_view數組中的某一個時也是不可見的;Purge thread在執行Purge操作時，凡是小于low_limit_no的數據，都是可以被Purge的，read view是MySQL MVCC實現的基礎。

Redo log優化背景

據介紹，MySQL有兩種很重要的Log，分別為redo log&binlog，前者是保證事務原子性操作所產生的日志，后者是主備數據同步所產生的同步日志。其中binlog在ordered_commit時進行group commit,而redo log則是在事務提交的時候分別調用trx_prepare使redo log落地，導致log_sys->mutex竟爭較為嚴重。

從crash recovery的邏輯來看，只要redo log早于binlog落地，就不會有數據問題，因此在ordered_commit的***階段時，TXSQL會收集各種引擎的***redo log LSN，然后將小于該LSN的redo log落盤，從而提升寫性能。更詳細的分析與測試，可以參考bug#73202。

圖2

TXSQL redo log雙緩沖區

MySQL redo log是一個順序寫的單緩沖區，log_sys->mutex鎖資源竟爭激烈，在事務落盤的過程中對LSN相關的讀、寫都被阻塞，為了解決 log_sys->mutex的鎖竟爭問題，引入雙緩沖區機制&w_mutex鎖，在flush redo log 的過程中釋放log_sys->mutex，繼續持有log_sys->w_mutex，從而阻塞寫，不阻塞LSN相關的讀操作，flush完成后釋放w_mutex;從而提升并發性，提升性能。

圖3

TXSQL性能數據對比

讀性能數據對比

寫性能數據對比

讀寫混合數據對比

TXSQL功能開發

在TXSQL并行復制方面，MySQL并行復制存在的問題：在實際的應用環境中，實例中往往只有一個 Database，導致 relay log 中的事務大部分會分到同一個 worker 線程中，造成備庫的性能低下，當主庫的性能超過備庫的單線程執行的性能時，就會出現延遲，對只讀實例產生影響。

TXSQL并行復制存在的優化

為了解決上述問題，TXSQL 添加了另外一種分發方式，即基于表粒度的分發，為了實現基于表粒度的分發，TXSQL 對于不同的實現，進行了不同的處理:

當binlog_row_format= ROW 時, 調用 get_slave_worker 直接進行分發;

當 binlog_row_format= statement 時，則需要對語句先進行調用 mysql_parse 對語句進行解析，然后再做分發。

TXSQL強同步支持

原生 semi-sync 存在著以下問題：

semi-sync 在時間超過 rpl_semi_sync_master_timeout 會退化為異步;

采用 select 進行監聽，當句柄值大于 1024 時則會出現異常，詳情可參考 bug#79865;

在 after commit 后等待 ACK 容易出現幻讀的問題;

TXSQL 強同步支持：

優化半同步，增加ack線程，收發并行化;

修正select時fd超過1024導致異常的bug，改為poll;

在半同步基礎上實現強同步，一直hold住直到收到ack;

修改同步方式時，喚醒正在等待的用戶線程，繼續等待或者退出;

增加一些狀態，用于展示當前等待的情況(正在等待的binlog位點，已等待時間);

對于主多 binlog 備少 binlog 的情況進行特殊的處理，以保證雙寫的情況不會發生;

TXSQL云上實踐

XX游戲數據庫優化案例

問題現象：性能不能滿足業務要求，游戲業務邏輯 TPS 不達標;在壓力達到一定程度時，CPU 不能充分利用，idle 較高;性能抖動較為明顯; thread running 過高，系統負載較高;系統 IO 壓力較小，IO 沒有問題;

問題排查：

pt-pmp & pstack & mysql 命令進行問題排查，發現以下問題：

1.應用在執行SQL語句的過程中，table_cache_manager 中的鎖沖突比較嚴重; 2.MySQL Server 層中的 MDL_lock 沖突比較重; 3.實例開啟了 Performance_schema 功能; 4.事務鎖 trx_sys->mutx 沖突較高;

調優過程：

根據已經查找出來的問題，調整相應參數與版本并重啟，效果如下圖所示：

1.table_open_cache_instances= 32 2.metadata_locks_hash_instances= 32 3.performance_schema= OFF 4.其它

TXSQL未來發展方向

***，張青林針對今天的演講做了精簡的總結，列出的數據庫問題如下：在壓力達到一定程度時，CPU 不能充分利用，idle 較高; 性能抖動明顯; 并發過大引起的 thread running 過高，系統負載較高; IO 問題引起的性能抖動; 鎖問題導致的性能抖動; 壓力不夠大或者壓力不均勻; 優化器問題引起的執行計劃出錯; SQL 語句引起的異常; 參數配置的不合理; 內核 Bug; 網絡問題。

在未來的發展過程中TXSQL仍然會以用戶為導向從以下方面不斷的進行改進：批量計算;執行計劃緩存;XA 三階段支持;基于binlog的深度優化;Innodb的持續優化;引入oracle企業級特性。