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

嘉賓介紹：張青林，騰訊云布道師、MySQL架構(gòu)師，隸屬騰訊TEG-基礎(chǔ)架構(gòu)部-數(shù)據(jù)庫內(nèi)核研發(fā)團(tuán)隊(duì)，專注于MySQL內(nèi)核研發(fā)&相關(guān)架構(gòu)工作，有著服務(wù)多個(gè)10W級QPS客戶的數(shù)據(jù)庫優(yōu)化及穩(wěn)定性維護(hù)經(jīng)驗(yàn)。

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

TXSQL內(nèi)核版本擁有更高的性能、更強(qiáng)的穩(wěn)定性，同時(shí)提供Oracle MySQL企業(yè)級版本才擁有的特性，對內(nèi)支持集團(tuán)內(nèi)部業(yè)務(wù)的發(fā)展，對外提供強(qiáng)有力的竟?fàn)幜Γ蟠筇嵘蓑v訊云在業(yè)界的影響力，贏得了客戶的信任與口碑，積極的推動了騰訊云的快速發(fā)展。

TXSQL概覽

什么是TXSQL?為什么有TXSQL?

TXSQL是Tencent MySQL的簡稱，是TEG基礎(chǔ)架構(gòu)部CDB(Cloud DataBase)團(tuán)隊(duì)在近十年發(fā)展過程中衍生出來的一個(gè)對MySQL內(nèi)核源碼深度定制、對官方MySQL版本進(jìn)行二次開發(fā)的項(xiàng)目。其主要目的是在保證線上穩(wěn)定性的同時(shí)，滿足業(yè)務(wù)對數(shù)據(jù)庫的各種需求。

TXSQL的服務(wù)對象是公司內(nèi)部用戶和騰訊云上小至數(shù)G大至數(shù)百T的外部客戶。TXSQL是支撐這些業(yè)務(wù)平穩(wěn)運(yùn)行的關(guān)鍵基石，促進(jìn)開源數(shù)據(jù)庫技術(shù)發(fā)展。

圖1

TXSQL內(nèi)核研發(fā)

TXSQL read view優(yōu)化

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

當(dāng)事務(wù)執(zhí)行時(shí)，凡是大于low_limit_id的數(shù)據(jù)對于事務(wù)是不可見的，凡是事務(wù)小于high_limit_id的數(shù)據(jù)都是可見的，事務(wù)ID是read_view數(shù)組中的某一個(gè)時(shí)也是不可見的;Purge thread在執(zhí)行Purge操作時(shí)，凡是小于low_limit_no的數(shù)據(jù)，都是可以被Purge的，read view是MySQL MVCC實(shí)現(xiàn)的基礎(chǔ)。

Redo log優(yōu)化背景

據(jù)介紹，MySQL有兩種很重要的Log，分別為redo log&binlog，前者是保證事務(wù)原子性操作所產(chǎn)生的日志，后者是主備數(shù)據(jù)同步所產(chǎn)生的同步日志。其中binlog在ordered_commit時(shí)進(jìn)行g(shù)roup commit,而redo log則是在事務(wù)提交的時(shí)候分別調(diào)用trx_prepare使redo log落地，導(dǎo)致log_sys->mutex竟?fàn)庉^為嚴(yán)重。

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

圖2

TXSQL redo log雙緩沖區(qū)

MySQL redo log是一個(gè)順序?qū)懙膯尉彌_區(qū)，log_sys->mutex鎖資源竟?fàn)幖ち遥谑聞?wù)落盤的過程中對LSN相關(guān)的讀、寫都被阻塞，為了解決 log_sys->mutex的鎖竟?fàn)巻栴}，引入雙緩沖區(qū)機(jī)制&w_mutex鎖，在flush redo log 的過程中釋放log_sys->mutex，繼續(xù)持有l(wèi)og_sys->w_mutex，從而阻塞寫，不阻塞LSN相關(guān)的讀操作，flush完成后釋放w_mutex;從而提升并發(fā)性，提升性能。

圖3

TXSQL性能數(shù)據(jù)對比

讀性能數(shù)據(jù)對比

寫性能數(shù)據(jù)對比

讀寫混合數(shù)據(jù)對比

TXSQL功能開發(fā)

在TXSQL并行復(fù)制方面，MySQL并行復(fù)制存在的問題：在實(shí)際的應(yīng)用環(huán)境中，實(shí)例中往往只有一個(gè) Database，導(dǎo)致 relay log 中的事務(wù)大部分會分到同一個(gè) worker 線程中，造成備庫的性能低下，當(dāng)主庫的性能超過備庫的單線程執(zhí)行的性能時(shí)，就會出現(xiàn)延遲，對只讀實(shí)例產(chǎn)生影響。

TXSQL并行復(fù)制存在的優(yōu)化

為了解決上述問題，TXSQL 添加了另外一種分發(fā)方式，即基于表粒度的分發(fā)，為了實(shí)現(xiàn)基于表粒度的分發(fā)，TXSQL 對于不同的實(shí)現(xiàn)，進(jìn)行了不同的處理:

當(dāng)binlog_row_format= ROW 時(shí), 調(diào)用 get_slave_worker 直接進(jìn)行分發(fā);

當(dāng) binlog_row_format= statement 時(shí)，則需要對語句先進(jìn)行調(diào)用 mysql_parse 對語句進(jìn)行解析，然后再做分發(fā)。

TXSQL強(qiáng)同步支持

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

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

采用 select 進(jìn)行監(jiān)聽，當(dāng)句柄值大于 1024 時(shí)則會出現(xiàn)異常，詳情可參考 bug#79865;

在 after commit 后等待 ACK 容易出現(xiàn)幻讀的問題;

TXSQL 強(qiáng)同步支持：

優(yōu)化半同步，增加ack線程，收發(fā)并行化;

修正select時(shí)fd超過1024導(dǎo)致異常的bug，改為poll;

在半同步基礎(chǔ)上實(shí)現(xiàn)強(qiáng)同步，一直hold住直到收到ack;

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

增加一些狀態(tài)，用于展示當(dāng)前等待的情況(正在等待的binlog位點(diǎn)，已等待時(shí)間);

對于主多 binlog 備少 binlog 的情況進(jìn)行特殊的處理，以保證雙寫的情況不會發(fā)生;

TXSQL云上實(shí)踐

XX游戲數(shù)據(jù)庫優(yōu)化案例

問題現(xiàn)象：性能不能滿足業(yè)務(wù)要求，游戲業(yè)務(wù)邏輯 TPS 不達(dá)標(biāo);在壓力達(dá)到一定程度時(shí)，CPU 不能充分利用，idle 較高;性能抖動較為明顯; thread running 過高，系統(tǒng)負(fù)載較高;系統(tǒng) IO 壓力較小，IO 沒有問題;

問題排查：

pt-pmp & pstack & mysql 命令進(jìn)行問題排查，發(fā)現(xiàn)以下問題：

1.應(yīng)用在執(zhí)行SQL語句的過程中，table_cache_manager 中的鎖沖突比較嚴(yán)重; 2.MySQL Server 層中的 MDL_lock 沖突比較重; 3.實(shí)例開啟了 Performance_schema 功能; 4.事務(wù)鎖 trx_sys->mutx 沖突較高;

調(diào)優(yōu)過程：

根據(jù)已經(jīng)查找出來的問題，調(diào)整相應(yīng)參數(shù)與版本并重啟，效果如下圖所示：

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

TXSQL未來發(fā)展方向

***，張青林針對今天的演講做了精簡的總結(jié)，列出的數(shù)據(jù)庫問題如下：在壓力達(dá)到一定程度時(shí)，CPU 不能充分利用，idle 較高; 性能抖動明顯; 并發(fā)過大引起的 thread running 過高，系統(tǒng)負(fù)載較高; IO 問題引起的性能抖動; 鎖問題導(dǎo)致的性能抖動; 壓力不夠大或者壓力不均勻; 優(yōu)化器問題引起的執(zhí)行計(jì)劃出錯(cuò); SQL 語句引起的異常; 參數(shù)配置的不合理; 內(nèi)核 Bug; 網(wǎng)絡(luò)問題。

在未來的發(fā)展過程中TXSQL仍然會以用戶為導(dǎo)向從以下方面不斷的進(jìn)行改進(jìn)：批量計(jì)算;執(zhí)行計(jì)劃緩存;XA 三階段支持;基于binlog的深度優(yōu)化;Innodb的持續(xù)優(yōu)化;引入oracle企業(yè)級特性。