深度揭祕騰訊雲數據庫技術7年變遷史

早在上個世紀50、60年代，「數據」二字就已再也不是簡單的數字信息而已。隨着信息技術的不斷髮展，在計算機應用領域，計算機存儲和處理的對象逐漸普遍，表示這些對象的數據也隨之變得愈來愈複雜，數據庫這一門新興學科的應用也愈來愈普遍。

縱觀國內幾大雲服務商過去幾年在雲數據庫領域的發展，騰訊雲基於自身的業務場景以及技術研發能力，在雲數據庫市場上也經歷了從利用開源到定製適配，再到自主研發的歷程。

跟不少互聯網公司不一樣的是，騰訊初始的業務發展並未對數據庫有過強依賴。與最初需使用Oracle等商業數據庫的IOE廠商相比，騰訊雲數據庫的起步是從KV與存儲分析的類型開始，而後逐步過渡到關係型數據庫的使用上來的。

所以，騰訊內部是沒有去IOE的過程，那麼騰訊是以何種路線逐步進階數據庫的？這還得先從騰訊雲數據庫的發展歷程提及，其發展歷程整體來講能夠分爲兩條線：

1. 迎接開源——開源定製參與回饋開源——爲雲而生定製——適配客戶需求。

一開始，騰訊雲數據庫建設主要引入了當時業界較爲主流的開源數據庫，如MySQL，Redis，PostgreSQL等。隨後針對雲上客戶定製需求，騰訊雲在數據庫中衍生研發瞭如數據庫並行複製、審計日誌、在線加字段等核心功能，並計劃逐步將以上功能回饋給MariaDB和MySQL社區。

1. 內部自研——業務倒逼技術發展——雲化支撐——走進互聯網及傳統行業。

對於騰訊雲自研的數據庫，主要分爲兩類，一類是爲騰訊內部業務適配而生的自研數據庫，典型表明是TDSQL。另外一類是基於服務海量客戶，由開源數據庫適配業務自主研發的數據庫，好比企業級雲原生數據庫CynosDB。若是說節省運維以及人力成本是雲數據庫1.0時代的特徵，到了2.0時代，雲數據庫要在根本上具有自建數據庫沒法比擬的優點，才能成爲支持用戶業務運轉不可撼動的基石。

能夠說，在騰訊自研數據庫歷史上，騰訊分佈式數據庫TDSQL & 企業級雲原生數據庫CynosDB具備重要的歷史節點。接下來，咱們將從架構等細節着手，爲你們詳細介紹這兩款數據庫背後的技術進階和研發歷程。

歷經十年打磨的TDSQL技術全解析

TDSQL完美解決了金融等系統中高可用、數據一致性、水平伸縮問題。2002年，騰訊技術團隊選擇徹底開源MySQL構建數據庫體系，爲了解決計費等公司級敏感業務高可用、核心數據的零流失、核心交易的零錯帳等問題，騰訊從07年開始自研了一款數據庫產品，這也是TDSQL的前身，這款數據庫在當時很好的支撐了09年的開放平臺浪潮。

隨着騰訊開放合做的發展擴大，行業場景愈來愈多，這款數據庫沒法很好的爲合做夥伴提供服務，所以從2012年開始，由騰訊內部業務適配而衍生的自研數據庫TDSQL正式誕生。那麼，TDSQL 是如何實現自主可控和技術迭代的呢？

TDSQL 架構

從架構上講，TDSQL 是 Shared-Nothing 架構的分佈式數據庫；從部署方式來說，TDSQL 是一款支持多租戶的雲數據庫。總體來講，TDSQL 是由決策調度集羣 /GTM，SQLEngine、數據存儲層等核心組件組成，其每一個模塊都基於分佈式架構設計，能夠實現快速擴展，無縫切換，實時故障恢復等，經過這一架構，TDSQL 的 Noshard、Shard、TDSpark 實例能夠混合部署在同一集羣中。而且使用簡單的 x86 服務器，能夠搭建出相似於小型機、共享存儲等同樣穩定可靠的數據庫。

在架構上，TDSQL 的核心思想有兩個：數據的複製（replica）和分片（sharding），其它都是由此衍生出來的。其中：

 replica 配合故障的檢測和切換，解決可用性問題；
 sharding 配合集羣資源調度、訪問路由管理等，解決容量伸縮問題。
 同時，因 replica 引入了數據多副本間的一致性問題和總體吞吐量降低的問題，而 sharding 的引入也會帶來必定的功能約束。在最終實現上，TDSQL 由 Scheduler、Gateway、Agent 三個核心組件加上 MySQL 組成，其中：
 Scheduler 是管理調度器，內部又分爲 zookeeper 和 scheduler server；
 Gateway爲接入網關，多個網關組成一個接入層；
 Agent 是執行代理，與 MySQL 實例一塊兒，構成數據節點。多個數據節點構成服務單元 SET。

TDSQL 面向數據一致性考驗

在金融行業，銀行、風控、渠道等第三方一般經過讀寫分離方式來查詢數據，而在互聯網行業，因爲 x86 相對較高的故障率，致使數據可能常常性的出現錯亂、丟失場景。爲了解決這個問題，就必需要求主從數據保持強一致和良好的讀寫分離策略。而其中的關鍵在於如何實現強同步複製技術。

因爲 MySQL 的半同步和 Galera 模式不只對性能的損耗是很是大的，並且數據同步有大量毛刺，這給金融業務同城雙中心或兩地三中心架構容災架構帶來了極大的挑戰。爲何會這樣呢？

從 1996 年的 MySQL3.1.1.1 版本開始，業務數據庫一般跑在內網，網絡環境基本較好，所以 MySQL 採用的是每一個鏈接一個線程的模型，這套模型最大的好處就是開發特別簡單，線程內部都是同步調用，只要不訪問外部接口，支撐每秒幾百上千的請求量也基本夠用，由於大部分狀況下 IO 是瓶頸。

但隨着當前硬件的發展，尤爲是 ssd 等硬件出現，IO 基本上再也不是瓶頸，如再採用這套模型，並採用阻塞的方式調用延遲較大的外部接口，則 CPU 都會阻塞在網絡應答上了，性能天然上不去。

爲了解決這些問題，TDSQL 引入了線程池，將數據庫線程池模型 (執行 SQL 的邏輯) 針對不一樣網絡環境進行優化，並支持組提交方案。例如，在 binlog 複製方案上將複製線程分解：

1. 任務執行到寫 binlog 爲止，而後將會話保存到 session 中，接着執行下一輪循環去處理其它請求了，這樣就避免讓線程阻塞等待應答
2. MySQL 自身負責主備同步的 dump 線程會將 binlog 當即發送出去，備機的 io 線程收到 binlog 並寫入到 relaylog 以後，再經過 udp 給主機一個應答
3. 在主機上，開一組線程來處理應答，收到應答以後找到對應的會話，執行下半部分的 commit，send 應答，綁定到 epoll 等操做。綁定到 epoll 以後這個鏈接又能夠被其它線程檢測到並執行。

改造後， TDSQL 基本能夠應對複雜的網絡模型。但上述方案還有小缺陷：當主機故障，binlog 沒有來得及發送到遠端，雖然此時不會返回給業務成功，備機上不存在這筆數據，然而在主機故障自愈後，主機會多出來這筆事務的數據。解決方法是對新增的事務根據 row 格式的 binlog 作閃回，這樣就有效解決了數據強一致的問題。

基於規則和基於代價的查詢引擎

當前大多數分佈式數據庫都設計的是基於規則的查詢引擎 (RBO)，這意味着，它有着一套嚴格的使用規則，只要你按照它去寫 SQL 語句，不管數據表中的內容怎樣，也不會影響到你的「執行計劃」，但這意味着該規則複雜的數據計算需求不「敏感」。雖然金融業務都有本身的數據倉庫，然而也會常常須要在 OLTP 類業務中執行事務、Join 甚至批處理。

TDSQL 在 SQLENGINE 實現了基於代價的查詢引擎 (CBO)，SQL 通過 SQLENGINE 的詞法、語法解析、語義分析和 SQL 優化以後，會生成分佈式的查詢計劃，並根據數據路由策略（基於代價的查詢引擎）進行下推計算，最後對彙總的數據返回給前端。

而做爲分佈式的計算引擎，在存儲與計算引擎相分離的狀況下，很是重要的一環就是如何將計算儘可能下推的下面的數據存儲層。所以 TDSQL 的 SQLENGINE 在通過大量業務打磨後，實現了基於 shard key 下推、索引條件下推、驅動表結果下推、null 下推、子查詢下推、left join 轉化成 inner join 等多達 18 種下推優化手段，儘可能下降數據在多個節點傳輸帶來的壓力，以提供更好的分佈式查詢的能力，支撐金融交易的關聯操做。

若是說騰訊雲數據庫歷史是一部從蟄伏到發展再到突破的歷史，那麼能夠說接下來CynosDB的推出，讓騰訊雲數據庫迎來了新一輪的突破變遷。

真正雲原生數據庫CynosDB技術解析

2017年，在騰訊雲服務了百萬客戶以後，騰訊雲數據庫迎來了突破。由開源數據庫適配業務和具體場景，騰訊雲自主研發了一款真正的雲原生數據庫CynosDB。做爲騰訊雲在數據庫領域的重要佈局，CynosDB單節點讀性能能夠達到130萬QPS，全面超越業內目前最高的100萬QPS水平。它將傳統數據庫與雲計算的優點相結合，解決了傳統數據庫雲上的難題，其設計思路能夠歸納爲如下幾點：

1. 首先是計算存儲分離，好比把運算CPU或者內存放在一塊兒統一分配，能夠得到彈性調度能力。
2. 第二個是日誌下沉及異步回放，同時移除了數據頁面的刷髒邏輯，這樣下降了計算存儲分離的架構下的網絡開銷。
3. 第三個是分佈式存儲，這也是咱們騰訊雲自研的分佈存儲系統，共享的分佈式存儲能夠橫向擴展。
4. 第四個是後臺的持續日誌備份，傳統數據庫的備份是在數據庫主機上去拷日誌完成備份，而CynosDB的持續備份是在存儲上進行，不干擾數據庫實例，減輕因爲備份對數據庫的衝擊，而且用戶沒必要關心備份策略和備份存儲資源規劃。

計算存儲分離架構的實現和優化

這裏須要重點說下計算和存儲分離。傳統數據庫的優化演進歷史，基本上是和IO作鬥爭的歷史，由於數據庫是有狀態、重IO的服務，傳統MySQL架構有多個IO類型，存儲相同的文件，因此主機和備機的磁盤會有不少相同的IO和冗餘的文件。即使數據庫被搬上雲，爲了在雲上作彈性的擴容，開發者依然面臨傳統數據庫所面臨的問題。

基於以上痛點， CynosDB以軟件優化與新硬件結合爲理念，採用了先進的計算和存儲分離架構，同時實現了計算無節點狀態，支持秒級故障切換和恢復，數據備份時間縮短到60秒以內，速度提高了180倍。

CynosDB架構有以下幾個特色：

1. 日誌即數據庫。架構中只有日誌流，於是只有日誌能表達數據庫；
2. IO卸載。除了日誌，其餘全部類型IO所有卸載，如數據文件、源數據文件、biglog文件等；
3. 無狀態。本地文件將不復存在，包括日誌文件，因此計算層是無狀態的。

在新架構中，日誌處理無可厚非具備很是重要的做用。其中連續的日誌在存儲層被打散成了不少的小的分片，分別存儲在不一樣的cell裏。而日誌處理的邏輯是將存儲引擎將日誌發給存儲節點，存儲節點將日誌放到一個日誌隊列裏面，並將其持久化，以後當即返回給存儲引擎，當存儲引擎得到日誌的反饋後就能夠將一部分事務提交。其中，存儲節點會異步的進行一些操做，這些操做和事務的提交過程無關，不影響事務的提交響應速度。

而在數據庫裏面，若是buffer足夠的話，數據庫的寫性能是和日誌的落盤時間相關的，傳統數據庫組提交機制可能存在幾個問題，一是若是有大量的鏈接進來，MySQL將會爲每個鏈接建立一個線程，若是用戶的業務沒有鏈接管理，那麼將會存在頻繁的線程建立與銷燬，浪費不少資源，同時，大量併發線程的鎖衝突以及切換代價也會很是大。

針對以上問題，CynosDB引入了線程池，直接解決了資源管理和線程切換的問題，但線程池只適合處理短任務。爲此，CynosDB同時引入了異步組提交的機制，基於線程池實現，再增長獨立的日誌寫線程log writer，每個工做線程提交事務的時候，並非去作寫和刷的操做，而是將本身的請求提交到一個提交隊列裏去，而後當即返回給Server層，以便釋放本身的線程資源。若是某一段日誌持久化成功以後，log writer會喚醒提交隊列裏面等待的請求，將其從新調度到線程池的高優先級隊列，從新得到工做線程執行事務提交後的工做。如此一來就能高效的利用線程池的資源，同時作到資源的控制，避免上下文頻繁切換帶來的性能問題。

日誌下沉、異步回放的關鍵設計

日誌下沉是什麼意思？好比開發者在一個頁面作插入操做，生成的日誌會放到日誌管理子系統的日誌buffer裏，日誌buffer的重用、刷新、併發管理等都是由數據庫來作。CynosDB會把日誌管理作成獨立模塊，並在CynosStore Client中實現。任何數據庫若是想接入這個系統的話，都不用去關心日誌管理，直接調相關接口完成日誌記錄便可。這裏的日誌和普通日誌存在區別，好比PG的日誌更偏向邏輯的概念，而CynosDB的日誌，記錄的是物理修改（對某頁面的什麼位置作了什麼內容的修改）。另外，日誌向日志buffer的插入過程是並行的，如有5個用戶同時生成日誌，往日誌buffer copy都是並行進行的而非串行。

總結來講，日誌下沉是指DB層產生的日誌都會放到CynosStore Client的buffer中，而後異步發送到分佈式存儲中，而不是存到本地。而在分佈式存儲中有一塊固定的存儲空間來專門存儲日誌，因爲空間大小固定，所以在CynosStore中會有特定的線程，定時地把日誌異步地合併到數據頁面上，經過這種日誌回收機制能夠有效的利用日誌空間，保證寫的連續性。

CynosDB應用場景及將來規劃

近日，騰訊雲數據庫CynosDB正式亮相MariaDB用戶者大會，並受到了MariaDB基金會以及衆多國際參會者的承認。

與此同時，騰訊雲數據庫產品總監王義成還向記者透露，今年Q3，CynosDB將會完全完成商業化。CynosDB的技術能力以及存儲層早已具有按使用量計費的能力，計算層也正在進行相應的適配，待CynosDB商業化後將逐步推上日程。

因爲CynosDB對主流開源數據庫的兼容，以及快速彈性升級、海量數據存儲等優點，王義成表示，CynosDB將來將持續落地應用於包括互聯網及遊戲等廣闊的行業，幫助用戶更好地應對業務高峯，加速業務創新。
後記
從2012年到2019年，這七年，騰訊雲數據庫無不見證、參與數據庫技術發展史上的一次次突破與迭代。回望這段從開源到適配，從適配到自研的歷程，騰訊雲能夠說將每一次經由業務適配考驗後的思考、經驗都化做數據庫服務的「活水」，灌溉自身業務的同時也灌溉了開發者社區。

值得注意的是，在長達幾十年的時間裏，因爲國內數據庫市場啓動較晚，國外巨頭始終佔據數據庫絕對領先優點，使得國產數據庫的發展十分艱難。將來，由雲原生技術帶來的一系列新技術與市場機遇，不只僅是對數據庫管理員的挑戰，也是對數據庫產品內核與工具的考驗，接下來騰訊雲數據庫「風」往何處吹？且看「行雲」。

本文轉載自InfoQ