騰訊私有雲MySQL解決方案—TDSQL

TDSQL是騰訊提供的一套完整的MySQL資料庫集群化管理解決方案，作為私有雲TStack平台重要的資料庫產品能力，旨在解決高可用、高性能、分散式、配套設施等方面問題。

TDSQL除了在騰訊內部有大量的使用場景，在外部市場中也有諸多應用場景；2014年被WeBank選中，作為其核心交易系統的資料庫解決方案，以私有雲方式交付；2015年，在騰訊雲上正式推出。目前已經為500+機構提供資料庫的公有雲及專有雲服務，客戶覆蓋計費、第三方支付、銀行、保險、互聯網金融、物聯網、互聯網+、政務等領域。

TDSQL私有雲版本的核心思路是：標準化、模塊化、豐儉由人！

例如TDSQL的模塊設計是充分解耦的，彼此之間通過介面銜接，客戶可以自行組裝或用自己現有模塊替換；又比如在設計部署架構時，客戶可在成本（自身數據中心建設情況），業務數據安全可靠性、業務可用性三者之間做不同的平衡選擇，可以做到N地N中心的部署，數據副本亦可做到一主N備（N>=0）；甚至在設計讀寫分離機制時，只讀賬戶可根據主備延遲狀態，選擇是從備機讀取，還是從主機讀取，還是直接返回錯誤；資料庫引擎，TDSQL也提供MariaDB、Percona、MySQL社區版三個版本支持。類似這樣的設計貫穿TDSQL私有雲版本的整個研發過程，以給予客戶足夠的靈活性和選擇權。

TDSQL關鍵特性

數據可靠性

在各種異常災難情況下，例如主機故障、網路故障、數據中心故障等，都能確保數據安全可靠。

系統可用性

基於數據多副本，系統保證在各種異常災難情況下，可根據客戶不同的數據可靠性級別，快速恢復可用，把不可用時長降至最低。強同步數據節點之間自動切換，RTO為40s，RPO為0。

高性能

對MySQL三大分支（MariaDB、Percona、MySQL community）深度優化，使得在主備網路延遲5ms的情況下，能做到跨IDC強同步性能相較於非同步同步零損耗；同時sysbench OLTP TPS數據是原生版本185%。

水平擴展性

提供Auto Sharding機制，可實現實時在線無縫擴容，確保集群性能和容量呈線性增長；同時提供健壯的分散式事務機制，在性能損耗極低(損耗30%)的情況下，大大降低了傳統業務遷移分散式架構的難度。

自動化運營

提供完善的運營體系，自動化運營發布平台，機器資源自動管理，智能監控平台及展示，資料庫智能診斷等。

配套設施

TDSQL還提供Binlog訂閱、安全審計、冷備系統、多源同步等配套系統，供客戶選擇。

核心架構

TDSQL的核心架構大體如下：

Set機制

TDSQL所有的高可用機制均是在Set之內實現，每個Set之內多個數據節點（1主N備），主備之間可以是基於Raft協議的強同步複製機制，也可以是非同步複製機制。在主機出現故障的情況下，在調度模塊的協助下，將挑選備機按照規定流程提升為主機，快速恢復業務，全程無需人工干預。在我們常規的使用過程中，通常是建議1主2備，主備之間強同步，這樣在主節點故障情況下，能確保自動切換，RTO為40s，RPO為0。

水平擴容

分散式版本對外呈現為一個完整的邏輯實例，後端數據實際上是分布在若干Set上（獨立的物理節點）組成。邏輯實例屏蔽了物理層實際存儲規則，業務無需關心數據層如何存儲，也無需在業務代碼中集成拆分方案或再購買中間件，只需要像使用集中式（單機）資料庫一樣使用即可。同時支持實時在線擴容，擴容過程對業務完全透明，無需業務停機，擴容時僅部分分片存在秒級的只讀（只讀是實際在做數據校驗），整個集群不會受影響。

分散式事務

TDSQL基於MySQL的XA實現了分散式事務機制，對各種異常處理做了充分的魯棒測試（發現了10多個XA相關的Bug並進行修復提交到社區，並做了大量性能方便的改進，擴展了事務狀態方面的統計信息以實現全局分散式死鎖檢測），且相對於單機事務，性能損失僅30%。

高級特性

二級分區

第一級即我們常說的水平拆分，原理是使用HASH演算法，使得數據能均勻的分散到後端的所有節點；第二級分區使用RANGE演算法，使得相關的數據能夠落在一個邏輯分區，例如可以按時間分區（類似每天每周每月一個分區等），亦可以按業務特性分區（類似每個省市一個分區等）等等。二級分片可以均衡數據分布和訪問，為快速一鍵擴容提供基礎支撐，也可以滿足快速刪除數據等場景。

讀寫分離

基於資料庫訪問賬號的讀寫分離方案，客戶能基於業務需求對賬號設定相關參數，以確保既不會讀取到過舊的數據，也不會影響寫業務，且業務無需改動代碼即可實現讀寫分離。這可以極大的降低業務運營成本。

此外，TDSQL還有全局唯一數字序列、統一參數管理、兼容MySQL函數，熱點更新等眾多高級特性，可滿足各類業務需求。

內核優化

TDSQL在資料庫內核這塊的優化，主要集中在數據複製、性能、安全性等方面。

強同步機制

TDSQL針對金融場景的強同步機制，有效解決了MySQL原生半同步機制的問題：性能降低以及超時退化為非同步。目前TDSQL在強同步模式下，系統的並發量（TPS/QPS）與非同步模式已無差別，基本能做到性能無損失。

性能優化

1、我們對MariaDB/Percona的線程池調度演算法進行了優化，改進當系統處於重負載時，查詢和更新請求在線程組間分布不均衡等極端情況。並且能夠更好地利用計算資源，減少無謂的線程切換，減少請求在隊列中的等待時間，及時處理請求。

2、組提交（Group Commit）的非同步化。工作線程在其會話狀態進入組提交隊列後，不再阻塞等待組提交的Leader線程完成提交，而是直接返回處理下一個請求。

3、InnoDBBuffer Pool使用優化。例如全表掃描時，避免佔滿InnoDB Buffer Pool，而是只取一塊來使用。

4、InnoDB在MySQL組提交期間避免與組提交有mutex衝突的活動，例如InnoDB Purge，降低衝突，以提升性能。

類似的性能優化的點，還有不少，可能在某些場景下，單個點效果不明顯，但是集合起來看，目前性能指標整體是不錯的。基於Sysbench OLTP測試結果，相同的硬體及測試環境下，TDSQL性能相比原生版本提升85%。

此外，我們長期關注MySQL的三個分支版本：MariaDB、Percona、MySQL community，對於社區的新特性，也會定期的合入。

部署方案

基於成本因素考慮，客戶可根據自身業務數據的容災要求，以及數據中心分布情況，選擇不同的部署方案。TDSQL可以針對客戶不同的數據中心架構，在數據可靠性與可用性上做出權衡，做到靈活部署。目前常見的兩種部署方案包括：

兩地三中心

該方案，ZK分布在兩地的三個中心內。

1、主IDC故障不會丟數據，自動切換到備IDC，此時蛻化成單個IDC的強同步。

2、僅僅主機故障，在對比兩個同城備節點及一個同城Watcher節點後，切換到數據最新的節點，優先選擇同IDC的Watcher節點，儘可能減少跨IDC切換。

3、備IDC故障，通過另外一個城市的ZK能自動做出選舉：

a)備IDC確實故障，自動提升主IDC的Watcher節點為Slave,由主提供服務。

b)主備網路不通，與a)一樣的處理方式。

兩地四中心

該方案適應性最強，但是對機房數量要求也高一些。

1、同城三中心集群化部署，簡化同步策略，運營簡單，數據可用性、一致性高

2、單中心故障不影響數據服務

3、深圳生產集群三中心多活

4、整個城市故障可以人工切換

周邊配套

對於私有雲客戶來說，資料庫產品其配套設施、可維護性、透明性等對於客戶來說至關重要，因為這決定了他們能否及時發現問題，針對問題能快速的做出變更及應對。所以TDSQL私有雲版本，提供完善的周邊配套體系，例如：

冷備系統

基於HDFS或其他分散式文件系統，可以做到自動備份，一鍵恢復，支持物理備份，邏輯備份，增量備份等各種策略。

消息隊列

基於Kafka定製的Binlog訂閱服務。基於該消息隊列，TDSQL還提供了SQL審計、多源同步（相同表結構的數據合併到一張表）等服務。

資源管理

基於cgroup的對TDSQL實例進行編排，提高機器資源利用率。

OSS

對TDSQL的所有操作，例如擴容、備份、恢復、手動切換、申請（修改／刪除）實例等操作，均提供統一的HTTPS介面，可以有效自動化，降低人肉運維的風險。

數據採集

TDSQL所有的內部運營狀態或數據，都能實時採集到，業務可以基於這些數據做定製分析或者構建運營監控平台。

監控平台

業務可以基於數據採集模塊採集到的所有數據，對接自建的監控系統，亦可直接使用TDSQL自帶的監控系統。

管理平台

基於以上模塊，TDSQL自帶運營管理平台（內部平台代號赤兔），DBA基本上可以通過該管理台進行所有常規的運營操作，不再需要登錄後台。

審計模塊

審計模塊通過對用戶訪問資料庫行為的日誌採集及分析，用來幫助客戶事後生成合規報告、事故追根溯源，同時加強內外部資料庫網路行為記錄，提高數據資產安全。

以上這些模塊可以自由組合，沒有強依賴關係，客戶也可以通過TDSQL的提供的介面自行對接自己現有的平台（如監控、告警、審計等）

寫在最後

TDSQL經過多年發展，上面提到的特性，均在騰訊內部的海量業務實踐運營過程中得到檢驗，這也是TDSQL對外版本發布的基本原則：只有經過現網運營驗證並覺得充分成熟的特性，才會發布給客戶，所以大家可以放心使用。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！