舉個栗子看如何作MySQL 內核深度優化

本文由雲+社區發表

做者介紹：簡懷兵，騰訊雲數據庫高級工程師，負責騰訊雲CDB內核及基礎設施建設；前後供職於Thomson Reuters和YY等公司，PTimeDB做者，曾獲一項發明專利；從事MySQL內核開發工做8年，具備豐富的優化經驗；在分佈式存儲等領域有較豐富經驗。

MYSQL數據庫適用場景普遍，相較於Oracle、DB2性價比更高，Web網站、日誌系統、數據倉庫等場景都有MYSQL用武之地，可是也存在對於事務性支持不太好（MySQL 5.5版本開始默認引擎纔是InnoDB事務型）、存在多個分支、讀寫效率瓶頸等問題。

因此如何用好MYSQL變得相當重要，一方面須要經過MYSQL優化找出系統讀寫瓶頸，提升數據庫性能；另外一方面須要合理涉及數據結構、調整參數，以提升用戶操做響應；同時還有儘量節省系統資源，以便系統能夠提供更大負荷的服務。本文將爲你們介紹騰訊雲團隊是如何對Mysql進行內核級優化的思路和經驗。

早期的CDB主要基於開源的Oracle MySQL分支，側重於優化運維和運營的OSS系統。在騰訊雲，由於用戶數的不斷增長，對CDB for MySQL提出愈來愈高的要求，騰訊雲CDB團隊針對用戶的需求和業界發展的技術趨勢，對CDB for MySQL分支進行深度的定製優化。優化重點圍繞內核性能、內核功能和外圍OSS系統三個維度展開，具體的作法以下：

一.內核性能的優化

因爲騰訊雲上的DB基本都須要跨園區災備的特性，所以CDB for MySQL的優化主要針對主從DB部署在跨園區網絡拓撲的前提下，重點去解決真實部署環境下的性能難題。通過分析和調研，咱們將優化的思路概括爲：「消除冗餘I/O、縮短I/O路徑和避免大鎖競爭」。如下是內核性能的部分案例：

1.主備DB間的複製優化

問題分析

如上圖所示，在原生MySQL的複製架構中，Master側經過Dump線程不斷髮送Binlog事件給Slave的I/O線程，Slave的I/O線程在接受到Binlog事件後，有兩個主要的動做：

• 寫入到Relay Log中，這個過程會和Slave SQL線程爭搶保護Relay Log的鎖。
• 更新複製元數據(包含Master的位置等信息)。

優化方法

通過分析，咱們的優化策略是：

• Slave I/O線程和Slave SQL線程是典型的單寫單讀生產者-消費者模型，是能夠作到無鎖設計的；所以實現思路就是Slave I/O線程在每次寫完數據後，原子更新Relay Log的長度信息，Slave SQL線程讀取Relay Log的時以長度信息爲邊界。這樣就將本來競爭激烈的Relay Log鎖化解爲無鎖；
• 因爲Binlog事件中的GTID(Global Transaction Identifier)和DB事務是一一對應的關係，因此Relay Log中的數據自己已經包含了所須要的複製元數據，因此咱們能夠不寫Master info文件，消除了冗餘的文件I/O；
• 於DB都是以事務爲更新粒度的，由於在Relay Log文件I/O上，咱們經過合併離散小I/O爲事務粒度的大I/O等手段，使磁盤I/O得以大幅提高。

優化效果

如上圖所示，通過優化：左圖35.79%的鎖競爭(futex)已經被徹底消除；同壓測壓力下，56.15%的文件I/O開銷被優化到19.16%，Slave I/O線程被優化爲預期的I/O密集型線程。

2.主庫事務線程和Dump線程間的優化

問題分析

如上圖所示，在原生MySQL中多個事務提交線程TrxN和多個Dump線程之間會同時競爭Binlog文件資源的保護鎖，多個事務提交線程對Binlog執行寫入，多個Dump線程從Binlog文件讀取數據併發送給Slave。全部的線程之間是串行執行的！

優化方法

通過分析，咱們的優化策略是：

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

效果

通過測試，優化後的內核，不只提高了事務提交線程的性能，在Dump線程較多的狀況下，對主從複製性能有較大提高。

二.主備庫交互流程優化

問題分析

如上圖所示，在原生MySQL中主備庫之間的數據發送和ACK迴應是簡單的串行執行，在上一個事件ACK迴應到達以前，不容許繼續發送下一個事件；這個行爲在跨園區(RTT 2-3ms)的狀況性能很是差，並且也不能很好地利用帶寬優點。

優化方法

通過分析，咱們的優化策略是：

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

效果

根據實際用例測試，優化後的TPS提高爲15%左右。

三.內核功能的優化

1. 預留運維賬號鏈接數配額

在騰訊雲上，不時遇到用戶APP異常或者BUG從而佔滿DB的最大鏈接限制，這是CDB OSS賬號沒法登陸以進行緊急的運維操做。針對這個現狀，咱們在MySQL內核單獨開闢了一個可配置的鏈接數配額，即使在上述場景下，運維賬號仍然能夠鏈接到DB進行緊急的運維操做。極大地下降了異常狀況下DB無政府狀態的風險。該賬號僅有數據庫運維管理權限，沒法獲取用戶數據，也保證了用戶數據的安全性。

2. 主備強同步

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

四.外圍系統的優化

除了以上提到的MySQL內核側的部分優化，咱們也在外圍OSS平臺進行了多處優化。例如使用異步MySQL ping協議實現大量實例的監控、經過分佈式技術來加固原有系統的HA/服務發現和自動擴容等功能、在數據安全/故障切換和快速恢復方面也進行了多處優化。

此文已由做者受權騰訊雲+社區發佈