騰訊計費平臺部為了解決基于內(nèi)存的NoSQL解決方案HOLD平臺在應(yīng)對多種業(yè)務(wù)接入時的不足，結(jié)合團隊在MySQL領(lǐng)域多年應(yīng)用和優(yōu)化經(jīng)驗，最終在MySQL存儲引擎基礎(chǔ)上，打造一套分布式SQL系統(tǒng)TDSQL。本文是對該系統(tǒng)架構(gòu)分析。
騰訊計費平臺部托管著公司90%以上的虛擬賬戶，如QB、Q點、包月服務(wù)、游戲的二級賬戶等，為了保證能順暢支撐公司各大業(yè)務(wù)的實時在線交易，并且在各種災(zāi)難場景下數(shù)據(jù)是一致并且可用的，對系統(tǒng)的可用性、一致性切換要求非常高，因此計費團隊歷來都非常重視高一致性存儲系統(tǒng)的建設(shè)。
到目前為止，計費高一致性存儲層的解決方案大致經(jīng)過了3個階段，本文將分享最新的基于MySQL的分布式解決方案。
隨著業(yè)務(wù)的發(fā)展，基于內(nèi)存的NoSQL解決方案HOLD平臺在高峰期一天支撐3000億讀寫，證明了分布式Cache的巨大價值；但隨著各種業(yè)務(wù)的接入，NoSQL方案的不足也逐步顯現(xiàn)出來了，如下所示。
1.適用的業(yè)務(wù)場景比較有限，僅提供get/set操作，有不少業(yè)務(wù)場景希望能通過記錄中的其他字段做索引來查詢，比如流水類業(yè)務(wù)。
2.不是所有的數(shù)據(jù)都是熱點，一臺64GB內(nèi)存機器提供的有效內(nèi)存空間大概在50GB左右，而采用Fusion卡的機型容量一般在1TB以上，對比起來，如果所有數(shù)據(jù)放入分布式Cache明顯是一種極大的浪費，最合理的當(dāng)然是熱點在HOLD，冷數(shù)據(jù)采用基于磁盤的存儲。
3.計費平臺部多年來在支付領(lǐng)域有了相當(dāng)多的技術(shù)積累，HOLD作為NoSQL系統(tǒng)功能有限，因此建造一套更加強大通用的高一致性存儲系統(tǒng)將整個支付領(lǐng)域的實時數(shù)據(jù)（重點是賬戶數(shù)據(jù)、用戶訂單數(shù)據(jù)，以及海量的流水?dāng)?shù)據(jù)）統(tǒng)一管理起來非常有價值。
基于上面的分析，結(jié)合我們在MySQL領(lǐng)域多年的應(yīng)用和優(yōu)化經(jīng)驗，最終決定在MySQL存儲引擎基礎(chǔ)之上，打造一套分布式的SQL系統(tǒng)。
1.保持原來的MySQL協(xié)議，這樣以前訪問MySQL系統(tǒng)的C++、Java各類系統(tǒng)都不需要修改，DBA能繼續(xù)保持原來大部分使用習(xí)慣。
2.自動的跨IDC容災(zāi)切換，同時保證數(shù)據(jù)一致性，對于提交成功的事務(wù)保證一筆不丟，達到銀行級對容災(zāi)的要求。
3.靈活的容量伸縮機制，對業(yè)務(wù)透明，解決MySQL本身擴容不靈活的問題。
4.重點支持OLTP類型的在線業(yè)務(wù)。
整體架構(gòu)
針對上面的需求，TDSQL最終的結(jié)構(gòu)如圖1所示（與當(dāng)前大部分中心化的分布式系統(tǒng)類似）。
Scheduler作為集群的管理調(diào)度中心，主要功能包括：
1.管理set，提供創(chuàng)建、刪除set、set內(nèi)節(jié)點替換等工作；
2.所有的DDL操作統(tǒng)一下發(fā)和調(diào)度；
3.監(jiān)控set內(nèi)各個節(jié)點的存活狀態(tài)，當(dāng)set內(nèi)主節(jié)點故障，發(fā)起高一致性主備切換流程；
4.監(jiān)控各個set的CPU、磁盤容量、各個表的資源消耗情況，必要的時候自動發(fā)起擴容流程；
5.Scheduler自身的容災(zāi)通過ZooKeqzer的選舉機制完成，保證中心控制節(jié)點無單點。
Agent模塊負責(zé)監(jiān)控本機MySQL實例的運行情況，主要功能包括：
1.用短連接的方式周期性訪問本機的MySQL實例，檢測是否可讀、可寫，若發(fā)生異常，會將異常信息上報到ZooKeeper，最終會由上面描述的Scheduler模塊檢測到這個異常情況，從而發(fā)起容災(zāi)切換；
2.檢測主備復(fù)制的執(zhí)行情況，會定期上報主備復(fù)制的延時和延遲的事務(wù)數(shù)，若發(fā)生了主備切換，自動向新主機重建主備，因此MySQL的主備不需要DBA干預(yù)，對于新增的實例會3.自動采用 xtrabackup通過主機自動重建數(shù)據(jù)；
4.檢測MySQL實例的CPU利用率和各個表的請求量、數(shù)據(jù)量、CPU利用率，上報到ZooKeeper，ZooKeeper通過全局的資源情況抉擇如何擴容、縮容；
5.監(jiān)控是否有下發(fā)到自身的擴容任務(wù)，如有則會執(zhí)行擴容流程（下面會有描述）；
監(jiān)控是否要發(fā)生容災(zāi)切換，并按計劃執(zhí)行主備切換流程。
網(wǎng)關(guān)基于MySQL Proxy開發(fā)，在網(wǎng)絡(luò)層、連接管理、SQL解析、路由等方面做了大量優(yōu)化，主要特點和功能如下：
1.解析SQL，將識別出的DDL語句直接存到ZooKeeper，讓Keeper來統(tǒng)一調(diào)度；
2.Watch ZooKeeper的路由信息，拉取最新的路由表保存到本地文件和內(nèi)存；
3.將SQL請求路由到對應(yīng)的set，支持讀寫分離；
4.對接入的IP、用戶名、密碼進行鑒權(quán)；
5.記錄完整的SQL執(zhí)行信息，與秒級監(jiān)控平臺對接完成實時的SQL請求的時耗，成功率等指標(biāo)監(jiān)控分析；
6.對count、distinct、sum、avg、max、min、order by、group by等聚合類SQL一般需要訪問后端的多個set，網(wǎng)關(guān)會分析結(jié)果并做合并再返回，暫不支持跨set join和分布式事務(wù)；
7.網(wǎng)關(guān)無狀態(tài)，既支持與業(yè)務(wù)部署到一起，也可以獨立部署（可通過TGW或者LVS做容災(zāi)）。
自動擴容機制
目前，針對MySQL的擴容，一般有下面兩種策略。
1.垂直擴容。一般通過升級硬件來實現(xiàn)，比如更換更好的CPU，將傳統(tǒng)的sas盤換成FusionIO卡這類，然后針對新硬件調(diào)整好參數(shù)，在硬件結(jié)構(gòu)變化比較大的時候，性能甚至能達到上十倍的提升。但垂直擴容有比較大的局限，就是這種模式隨著業(yè)務(wù)的突增還是比較容易達到瓶頸，特別是面對互聯(lián)網(wǎng)海量用戶的時候，所以在互聯(lián)網(wǎng)應(yīng)用場景下，一般僅將垂直擴容當(dāng)做一個輔助的手段。
2.水平擴容。常用的有2種方法，一是不同的庫或者表部署到不同的實例，二是一張表需要根據(jù)某個字段拆分到不同的字表中（數(shù)據(jù)分片），這種策略在互聯(lián)網(wǎng)系統(tǒng)中非常常見，很多系統(tǒng)會將這2種水平擴容的方法結(jié)合起來使用；
通過上述2種擴容方法的比較，為了應(yīng)對海量擴展的需求，應(yīng)該是重點選用水平擴容的方法。但水平擴容的實現(xiàn)一般對業(yè)務(wù)是有感知的，比如采用什么規(guī)則來拆表，拆開的表放到哪些節(jié)點，如果某個子表還有瓶頸應(yīng)該怎么擴容，擴容是否還需要業(yè)務(wù)配合等等這些事情如果全部交給業(yè)務(wù)會比較繁瑣，因此這些需求應(yīng)該盡量全部交給TDSQL自身來完成，對業(yè)務(wù)完全透明。
分表邏輯
在TDSQL中，每個表（邏輯表）可能會拆分成多個子表（建表的時候通過在建表語句中嵌入注釋的方式提供一個shard字段名，最多會拆分出1W個子表），每個子表在MySQL上都是一個真實的物理表，這里稱為一個shard，因此一張表的數(shù)據(jù)可能會按這樣的方式分布在多個Set中，如圖2所示
每個SQL請求到達網(wǎng)關(guān)之后，網(wǎng)關(guān)會做詞法和語法解析，重點會解析出shard字段，如果帶了shard字段就可以直接查詢路由表并發(fā)送到某個具體的set中。計費的OLTP類業(yè)務(wù)99%的請求都會帶上shard字段；如果某筆請求沒有shard字段，查詢路由之后會將請求發(fā)送到所有的shard對應(yīng)的set中，并對所有返回的結(jié)果做一些聚合運算。
擴容流程
上面描述了shard的方式，但是這樣的shard結(jié)構(gòu)不是固定不變的，當(dāng)Scheduler檢測到某個set，某個表的CPU、磁盤超過閾值之后就會啟動擴容流程。
這里描述下具體的擴容流程。
擴容過程中一般都要盡量避免影響業(yè)務(wù)，目前來看存在2種比較成熟的策略。
策略1先切后搬：先修改路由，將需要遷走的數(shù)據(jù)的請求直接發(fā)送到新set，在新set交易過程中如發(fā)現(xiàn)本地的數(shù)據(jù)不存在，則去原set拉取數(shù)據(jù)，然后再通過一些離線的策略將要遷移的數(shù)據(jù)全量再搬遷一次，HOID平臺就是采用這樣的策略。
策略2先搬后切：讓請求繼續(xù)在原set交易，擴容程序首先記錄一個binlog位置點，并將源set中符合遷移條件的數(shù)據(jù)全部遷移出去，最后再將搬遷過程中新增的binlog追完，最后修改路由規(guī)則，將請求發(fā)送到新set。
綜合來看，策略1最大的優(yōu)點是假如是因為壓力大做的遷移，可能很快就能將部分請求發(fā)送新set了，實現(xiàn)對原set的壓力分擔(dān)；策略2實現(xiàn)上在最后的追路由階段需要更多的精細化控制，實現(xiàn)會稍微復(fù)雜點，但策略2有個非常大的好處就是擴容過程中回滾非常方便，如有異常直接干掉擴容任務(wù)即可。
對于TDSQL這類數(shù)據(jù)庫業(yè)務(wù)系統(tǒng)來說，策略1實現(xiàn)會非常麻煩，因為請求到達新set之后可能需要去源set拉取數(shù)據(jù)，這個需要對MySQL本身進行修改；另外假如一個批量更新的update操作，可能要往新老set都發(fā)送一次請求，比較復(fù)雜，所以最終選擇了策略2。策略2會有更大的通用性，開發(fā)模式基本上可以統(tǒng)一到所有類似的系統(tǒng)。
下面描述采用策略2具體的擴容流程。假如要將Set1中的t_shard_1的數(shù)據(jù)遷移一半到Set4中的t_shard_4(1667-3333)。
后將擴容任務(wù)下發(fā)到Set1中的agent模塊，agent檢測到擴容任務(wù)之后會采用mysqldump+where條件的方式將t_shard_1中shard號段為1667-3333的記錄導(dǎo)出來并通過管道用并行的方式插入到Set4（不會在本地存文件，避免引起過多的IO），用mysqldump導(dǎo)出鏡像的時候會有一個binlog位置。
從mysqldump記錄的binlog位置開始讀取binlog并插入到到Set4，追到所有binlog文件末尾的時候（這需要一個循環(huán)，每次循環(huán)記錄從開始追binlog截止到追到文件結(jié)尾消耗的時間，必須保證追單次循環(huán)要在幾秒之內(nèi)完成，避免遺留的binlog太多導(dǎo)致最后一次追binlog消耗太多的時間，從而影響業(yè)務(wù)過久），對原來的表t_shard_1重命名t_shard_5，此時針對這個表不會再有新請求，若還有請求過來都會失敗，然后再追一次binlog到文件結(jié)尾（因為上面的循環(huán)保證了追binlog不會太耗時間了，所以此次會快速完成），然后上報狀態(tài)到ZooKeeper，表明擴容任務(wù)完成。
Scheduler收到擴容完成的信息之后會修改路由表，最后由網(wǎng)關(guān)拉取到新路由完成整體的擴容；從表重命名開始到網(wǎng)關(guān)拉取到新路由，這段時間這個原始shard不可用，從我們測試結(jié)果來看這個不可用的時間是200毫秒左右；如果某個網(wǎng)關(guān)異常，拉取不到新路由，繼續(xù)訪問老表t_shard_1會一直失敗，這樣就可以保證數(shù)據(jù)的一致性。
容災(zāi)機制
對于TDSQL來說，我們希望容災(zāi)做到自動切換，自動恢復(fù)，主備一致性（保證業(yè)務(wù)提交的事務(wù)在切換過程不丟失），跨IDC容災(zāi)。
【MySQL異步復(fù)制】
在MySQL發(fā)展的早期，就提供了異步復(fù)制的技術(shù)，只要寫的壓力不是特別大，在網(wǎng)絡(luò)條件較好的情況下，發(fā)生主備切換基本上能將影響控制到秒級別，因此吸引了很多開發(fā)者的關(guān)注和使用。但這套方案提供的一致性保證，對于計費或者金融行業(yè)是不夠的。
圖4是異步復(fù)制的大致流程，很顯然主機提交了binlog就會返回給業(yè)務(wù)成功，沒有保證binlog同步到了備機，這樣在切換的瞬間很有可能丟失這部分事務(wù)。
【Cluster方案】
除了上面的方案外，開源社區(qū)還有三個Cluster解決方案，分別是Oracle的NDB引擎、Percona XtraDB Cluster和MariaDB Galera Cluster，從公開資料的性能對比上來看，后2者在性能和系統(tǒng)靈活性等方面都強于NDB（同時采用NDB意味著也放棄了InnoDB引擎，NDB主要是基于全內(nèi)存的，并且需要高速網(wǎng)絡(luò)環(huán)境支持，所以不考慮了）；Percona XtraDB Cluster和MariaDB Galera Cluster強同步機制的底層都是采用Galera這套強同步的架構(gòu)。MariaDB Galera Cluster具有如下非常吸引人的特性：
1.MariaDB Galera Cluster 是一套在MySQL InnoDB存儲引擎上面實現(xiàn)multi-master及數(shù)據(jù)實時同步的系統(tǒng)架構(gòu)，業(yè)務(wù)層面無需做讀寫分離工作，數(shù)據(jù)庫讀寫壓力都能按照既定的規(guī)則分發(fā)到各個節(jié)點上去；
2.同步復(fù)制Synchronous replication：保證節(jié)點間數(shù)據(jù)一致性；
3.Active-active multi-master拓撲邏輯：多主的拓撲結(jié)構(gòu)，可以認為沒有備機的概念；
4.可對集群中任一節(jié)點進行數(shù)據(jù)讀寫：假如一個set有3個節(jié)點，則3個節(jié)點可以同時讀寫，上次完全不用關(guān)心主備切換和讀寫分離；
5.自動成員控制，故障節(jié)點自動從集群中移除；
6.自動節(jié)點加入；
7.真正并行的復(fù)制，基于行級：同一個表可以在集群中任何節(jié)點更新，支持不帶where條件，但一次更新的記錄條數(shù)有限制；
8.每個節(jié)點都包含完整的數(shù)據(jù)副本。
目前來看，Galera是一套相當(dāng)完美的方案。但是，在跨IDC的性能測試中，其性能下降比較大，另外，實現(xiàn)方案也比較復(fù)雜，目前對它的代碼理解還不夠透徹，所以暫時沒有在計費領(lǐng)域大范圍推廣使用。但我相信這個方向是對的，有吸引力的，隨著后續(xù)Galera越來越完善，我們對它研究得越透徹，也許有一天會采用這套方案。
【性能測試和分析】
上面的三種復(fù)制模式對比測試，數(shù)據(jù)如圖6所示。
為什么性能損耗會這么嚴(yán)重呢？這個看明白MySQL的網(wǎng)絡(luò)模型就清楚了。外界可查的MySQL最早的公開版本應(yīng)該是1996年的3.1.1.1版本，這么多年來，網(wǎng)絡(luò)模型基本上變化不大，與Apache有點類似，有點區(qū)別的是MySQL采用的是每個連接一個線程的模型，這套模型最大的好處就是開發(fā)特別簡單，線程內(nèi)部都是同步調(diào)用，只要不訪問外部接口，支撐每秒幾百上千的請求量也基本夠用，因為大部分情況下IO是瓶頸。不過隨著當(dāng)前硬件的發(fā)展，尤其是SSD、FusionIO的出現(xiàn)，IOPS從200+/s進化到幾十萬甚至百萬次/s，IO基本上不再是瓶頸，若再采用這套模型并采用阻塞的方式調(diào)用延遲較大的外部接口，則CPU都會阻塞在等網(wǎng)絡(luò)應(yīng)答上了，性能自然上不去。
不過在MySQL5.6企業(yè)版和MariaDB、Percona中都引入了線程池，使得網(wǎng)絡(luò)模型靈活了很多，圖7是簡化后的對比模型。
TDSQL采用的強同步方案
從上面的分析可知，半同步半異步是比較輕量級的高一致性容災(zāi)方案，但受限于已有的同步網(wǎng)絡(luò)模型，CPU利用不起來。我們?nèi)绻诰€程池基礎(chǔ)之上做一些修改，參考半同步的思路就可以實現(xiàn)一個高性能的強同步方案。
目前的做法是采用與Linux內(nèi)核處理中斷的思路：將上面線程池模型的第三個環(huán)節(jié)（執(zhí)行SQL的邏輯）拆成兩個部分：
1.上半部分：任務(wù)執(zhí)行到寫binlog為止，然后將會話保存到session中，接著執(zhí)行下一輪循環(huán)去處理其他請求了，這樣就避免讓線程阻塞等待應(yīng)答了；
2.然后：MySQL自身負責(zé)主備同步的dump線程會將binlog立即發(fā)送出去，備機的IO線程收到binlog并寫入到relay log之后，再通過UDP給主機一個應(yīng)答；
3.在主機上，開一組線程來處理應(yīng)答，收到應(yīng)答之后找到對應(yīng)的會話，執(zhí)行下半部分的commit，send應(yīng)答，綁定到epoll等操作。綁定到epoll之后這個連接又可以被其他線程檢測到并執(zhí)行了。
改造后性能提升明顯，如圖8所示。
數(shù)據(jù)高可用性保障機制
除上述強同步機制外，TDSQL還做了以下增強，以提升數(shù)據(jù)的可用性。
1.推薦一個set最少配置3個跨IDC的節(jié)點，可以按業(yè)務(wù)的要求對備機開放查詢服務(wù)。
2.支持靈活增加節(jié)點，比如覺得3個節(jié)點還不夠，可以非常方便地增加節(jié)點。TDSQL會自動完成數(shù)據(jù)的全量和增量復(fù)制，此處主要依賴Xtrabackup實現(xiàn)物理復(fù)制，性能測試數(shù)據(jù)表明：一個小時大概可以拷貝500GB數(shù)據(jù)到新節(jié)點。那么對于Z3（1.1TB盤，一般最多用800GB左右），新加入的節(jié)點大概1.5個小時左右就有了全量數(shù)據(jù)，此功能也可以用在壞盤等情況下替換節(jié)點的時候使用，非常方便。
3.細心的同學(xué)可能會發(fā)現(xiàn)上面的強同步還有點小缺陷：比如主機用kill -9殺掉，那么可能寫了binlog但沒有來得及發(fā)送到遠端，此時當(dāng)然也不會返回給業(yè)務(wù)成功，備機上不存在這筆數(shù)據(jù)，但主機起來之后會多出來這筆事務(wù)。我們的做法是對新增的事務(wù)根據(jù)row格式的binlog做閃回，當(dāng)然回退不了的比如drop table之類的，就直接提醒運維手工確認是否清除數(shù)據(jù)庫，然后會由Xtrabakcup機制自動從新的備機全量拉取數(shù)據(jù)重構(gòu)。
4.節(jié)點的監(jiān)控通過跨IDC部署的ZooKeeper來保證，并且主備切換由一套自動化的嚴(yán)格流程來保證。
接下來的方向
1.當(dāng)將高一致性容災(zāi)、高可用性、自動容量伸縮做實后，隨著業(yè)務(wù)的接入，集群的規(guī)模會越來越大，TDSQL必將會更加依賴實時的資源調(diào)度、隔離框架，因此有必要研究如何將TDSQL與Docker結(jié)合起來。
2.如前所述，Galera集群是個非常好的發(fā)展方向，我們會持續(xù)研究并實踐。
3.目前大部分MySQL還在使用單個連接單線程模型，線程池也剛起步，以后隨著大家對性能要求越來越高，這塊也許可以繼續(xù)突破，比如結(jié)合線程池+協(xié)程也許是個很好的方向，如果真能引入?yún)f(xié)程，也許為MySQL增加調(diào)用外部接口的結(jié)構(gòu)會靈活很多。
4.TDSQL將數(shù)據(jù)拆是拆的徹底了，但作為完整的分布式數(shù)據(jù)庫、合也需要考慮，比如跨庫少量記錄的join，規(guī)模受限的分布式事務(wù)等，目前的做法是數(shù)據(jù)按小時入TDW，在TDW上做OLAP分析。
