背景

金融行業的資料庫市場，尤其是銀行的核心交易系統，一直是Oracle、DB2這類傳統商業資料庫的天下，但是：

2014年，微眾銀行選用TDSQL作為其核心交易系統的資料庫解決方案；

2015年，騰訊金融雲正式推出TDSQL資料庫解決方案，在公有云以及私有云上投入商用，覆蓋包括銀行、保險、網際網路金融、物聯網等多個行業領域。

這標誌著TDSQL已經開始進入這個領域，雖然目前，金融、傳統行業的核心資料庫依然是Oracle、DB2們佔主導，但是TDSQL對外開放僅兩年，已經為40個金融政企機構提供資料庫服務，部署Set數已達800+（一個Set由一主兩備三個資料庫結點組成），算是開了一個好頭。

選擇TDSQL？

首先是金融行業自身受到了網際網路行業的衝擊。例如目前中國網民的兩大節日：阿里巴巴的“11.11剁手節”，微信的“春節紅包節”，給銀行的支付系統，尤其是快捷支付系統，帶來了很大沖擊，原有的IOE架構面領比較大的挑戰。此外，金融行業內部也開始思考，如何通過雲端計算、大資料等技術，提供更為普惠的金融服務，提升金融行業的服務效率。這些都使得基於TDSQL的分散式網際網路架構來代替集中式的IOE架構成為可能。

其次，在諸多資料庫產品以及內外競爭對手之中，TDSQL有著其自身明顯的優勢：十年在計費及支付行業的使用，在資料的安全性，可用性等方面有大量的實戰積累，填了不少的坑。計費平臺部從2007年開始，探索資料庫的高可用、高一致性，著力研究如何為計費支付應用提供7*24的高可用服務，系統經歷三代更迭。

1）7*24容災機制，是一套基於黑名單機制的主備容災切換機制，犧牲極少數使用者的可用性，確保系統的資料高一致性。

2）厚德（HOLD）KV儲存，是第一代容災機制的延續，主要是將黑名單等容災機制下沉到儲存系統，徹底將容災與業務邏輯解耦，業務開發人員不再需要關心容災。同時引入叢集管理機制，及自動擴容技術，在請求量及時耗要求特別高的場景下，目前依然大量使用，目前部署節點數達400+。

3）TDSQL，2012年開始，團隊開始思考如何將我們在資料庫容災切換、資料高一致性等方面的經驗輸出出去，於是就有了TDSQL，其可以說對計費前幾代儲存系統的整合之作：使用MySQL作為底層資料節點，把厚德（HOLD）中驗證過的叢集架構直接移植過來，將金融場景下最關注的一致性保障和水平伸縮等關鍵特性，都直接融入底層架構中。這樣能完美相容MySQL協議，降低原有基於資料庫的業務系統的割接難度。

最後，當然也有硬體行業的快速發展的契機，尤其是SSD在公司的大規模使用，使得TDSQL的雲化成為可能。

前期的挑戰？

第一階段是2014年，微眾接入之初。在此之前，TDSQL並沒有為公司外部客戶提供過服務，其產品化是一個比較初級的階段，雖然有十年計費使用經驗作為背書，但是雙方團隊依然有一個信任的磨合期。

關於TDSQL服務承諾的信任？TDSQL承諾在任意單點故障情況下，RPO為0，RTO為40秒，但是並沒有其他第三方機構針對TDSQL出過類似資料。對此，雙方測試團隊坐在一起，耗時1個月，構造100+測試用例，在高併發場景下，模擬各種異常情況，以確保能符合TDSQL的服務承諾。

關於資料庫及應用架構的設計？因為雙方實際生產環境的網路架構不一樣，導致雙方前期在資料庫及應用架構部署上，有較大的分歧，對此，雙方架構師團隊也是經過頻繁的多層次的交流，最後在綜合成本及系統安全性之間做好平衡，分階段設計出不同架構體系。

第二個階段是在2015年，TDSQL正式為金融雲提供服務後，較多的外部客戶接入進來，帶來了新的一些新的挑戰。

TDSQL能否適應更為複雜的場景？之前TDSQL更多的使用於OLTP場景，尤其是大量高併發的短事務場景，為了提升吞吐量，並解決MySQL的連線數限制問題，引入的資料庫執行緒池功能，而這個功能在某些場景下有些不適用，例如在同時有大量複雜SQL（耗時至少幾秒以上的SQL）併發時，系統吞吐量急劇降低。而云上大量接入進來的金融客戶業務開發團隊，卻依然將TDSQL當作Oracle來用，這導致問題凸顯，對此團隊深入MySQL核心，做了大量優化，例如對執行緒池的優先順序佇列進行優化，有效解決複雜SQL高併發帶來的吞吐量降低問題。

傳統思維與網際網路思維的衝突？團隊與大量傳統金融行業的IT人員交流之後發現，雙方在如何使用分散式資料庫等方面，依然有比較大的分歧，例如傳統行業的業務系統極為依賴資料庫，基本上一條SQL用A4紙都列印不完，大量使用儲存過程，而網際網路行業則將大量的邏輯放在應用層，資料層儘可能的輕量化、服務化。類似的衝突，可能不是一時半會能統一的，在不同的場景下，可能需要作出不同的選擇與權衡。TDSQL需要向Oracle學習，聯合各個上下游服務提供商或整合商，儘量為客戶提供一套完整的分散式解決方案。

TDSQL的解決之道

下面將從核心架構、核心優化、部署方案、周邊配套、產品化等方面來分析一下，TDSQL是如何適應金融行業需求的。

1、核心架構
在一致性方面，利用MySQL binlog的嚴格有序性以及強同步複製機制，再結合Raft協議思想（Raft協議核心兩點就是Leader選舉、日誌複製），我們最終實現了TDSQL的強一致性以及資料零丟失。

強同步機制：基於MySQL半同步複製優化，對於進入叢集的每筆更新操作，都將發到對應Set（每一個Set包含3個MySQL例項：一主兩備）的主機上，主機會將binlog發往兩個備機，且收到其中任一一個備機應答後（僅僅是備機收到了binlog，但可能還沒有執行這個binlog），然後才本地提交，並返回給客戶端應答，這就能確保資料零丟失。

可用性：在這種強同步機制下，建議是存3個數據副本，且分別分佈在3個 IDC，這樣在任一IDC故障情況下，剩下兩個IDC依然能夠提供服務。如果僅存2個副本，在某中一個副本故障情況下，系統將會降級為只讀服務。

Leader選舉：MySQL節點本身無法直接參與選舉，於是我們由Scheduler模組來負責這個事，如果主機發生故障，Scheduler會從兩個備機中，選擇一個數據較新的備機（因為MySQL binlog是嚴格有序的，所以誰同步主機binlog的偏移量更大，誰的資料就更新。當然也可以基於GTID來判斷）提升為主機。

自動擴容：目前TDSQL有兩個分支版本，一個是No-Sharding版本，一個是Group-Sharding版本，NS版本不支援自動擴容，GS版本支援自動擴容，但是該版本對SQL有一定的限制。

Group-Sharding雖然不支援跨節點事務和Join，但是在一個Group內，可以支援Join和事務。舉個例子，假設有兩張表：使用者資訊表與使用者賬戶表，我們可以將這兩張表組成一個邏輯Group，且這兩張表都按使用者ID欄位Sharding，後續Group內任意一張表需要Re-Sharding時，該組內所有表都同時進行Re-Sharding（相當於按Group進行Sharding），這樣單個使用者相關資料一定會落在一個Shard上（即同一個MySQL例項），於是在單個使用者條件下，這些表之間是可以做Join和關聯的。

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

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

效能優化。

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

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

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

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

類似的效能優化的點，還有不少，可能在某些場景下，單個點效果不明顯，但是集合起來看，目前效能指標整體是不錯的。目前TDSQL在雲上TS85機型下（24核、512G記憶體、6T磁碟），用sysbench測試，純寫入操作能到10萬TPS，純查詢操作能到40萬QPS。

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

3、部署方案
基於成本因素考慮，不同的客戶，甚至說同一客戶在不同階段，會有不同的網路架構，例如一些客戶前期可能做不到兩地三中心，後期也不會像騰訊那樣，擁有那麼多資料中心。所以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）整個城市故障可以人工切換；

4、周邊配套
給一個已經相對成熟的行業去推一款新型資料庫，如果僅僅提供資料庫底層是遠遠不夠的，其配套設施、可維護性、透明性等對於客戶來說至關重要，因為這決定了他們能否及時發現問題，針對問題能快速的做出變更及應對。所以TDSQL私有云版本，提供完善的周邊配套體系，例如：

1）冷備系統。基於HDFS或其他分散式檔案系統，可以做到自動備份，一鍵恢復。

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

3）資源管理。基於cgroup的對TDSQL例項進行編排，提高機器資源利用率。

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

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

6）監控平臺。業務可以基於資料採集模組採集到的所有資料，對接自建的監控系統，亦可直接使用TDSQL自帶的監控系統（需單獨部署）。

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

以上這些模組可以自由組合，沒有強依賴關係，對於TDSQL的推廣極為有力，因為純介面方式，鬆耦合對於TDSQL對接客戶的自建系統，例如監控平臺等極為方便。

5、產品化即雲化
諸多案例來看，TDSQL及網際網路架構完全有能力支撐金融核心業務。而其低成本、高彈性以及開放的架構又恰好能彌補傳統IOE架構的不足。

看起來，TDSQL就是去IOE的銀彈。但是，事實真的如此嗎？

大家都知道，網際網路分散式架構的底層基礎是開放的硬體和開源的軟體，初始獲取成本會比較低。但是，要用於生產的話，還需要進行大量的、持續的優化和改進，而且對運維團隊的能力要求也比較高。如果企業想直接遷入分散式架構上，勢必需要組建一個技術團隊來搞定這些問題，這就相當於將原來IOE架構下投在軟硬體上的成本轉投到人力上。在IT系統規模較小時，完全沒有優勢，甚至是得不償失的。這也是“去IOE”喊了這麼久，實質性進展卻比較小的一個原因。

但是，雲端計算的出現改變了這一切。在雲端計算架構下，這些本來要招一幫牛人才能搞得定的事情，現在已經有一幫甚至更牛、更專業的人幫你搞定了。你要做的，只是“申請、使用”，就這麼簡單！

所以，TDSQL不是去IOE的良藥，TDSQL on Cloud才是。目前與騰訊金融雲團隊，除了鞏固TDSQL在金融公有云這塊的優勢，還在積極探索私有云業務（銀行一般都是私有云部署），這對我們系統的可用性、文件全備性、周邊配套完整性等提出了更高的要求，這也是我們未來的投入方向之一。