0
近年來，金融行業(yè)數(shù)據(jù)泄漏事故頻發(fā)，遠高于其他行業(yè)。
通過永安在線數(shù)據(jù)資產(chǎn)泄露風險監(jiān)測平臺統(tǒng)計，金融行業(yè)是數(shù)據(jù)資產(chǎn)泄露的主要來源，占到了42%，而數(shù)據(jù)資產(chǎn)泄露高發(fā)的互聯(lián)網(wǎng)行業(yè)也只排名第二，占27%。出現(xiàn)這種情況是因為金融行業(yè)涉及到的人群大多是高凈值人群，數(shù)據(jù)轉化率高，變現(xiàn)能力強。
騰訊云數(shù)據(jù)庫TDSQL首席架構師張文認為：“雖然企業(yè)數(shù)據(jù)安全不只依靠數(shù)據(jù)庫，但數(shù)據(jù)庫一定要做這種最后一根救命稻草的保障?！?/p>
張文還介紹到，“數(shù)據(jù)的誤刪、誤操作，對于一些銀行客戶而言，可能一年或者幾個月都不會發(fā)生一次，但是，我們面對著云上的客戶，每天都有客戶誤刪、誤操作，在這方面TDSQL積累、總結了大量的經(jīng)驗、教訓。對此，我們也有很多的解決方案包括SQL防火墻、透明加密、自動備份等——如何更快速的幫助用戶找回數(shù)據(jù)、恢復其可用性，經(jīng)過這么多年的打磨，我認為我們是非常專業(yè)的?！?/p>
恰逢新年，雷鋒網(wǎng)《AI金融評論》邀請到張文參加「銀行業(yè)AI生態(tài)云峰會」，他分享了騰訊云是如何在「銀行數(shù)據(jù)庫」這一領域深耕發(fā)展；如何在國外商用數(shù)據(jù)庫的“壓力”下，突破求生，拿下多個銀行核心系統(tǒng)大單。
目前「銀行業(yè)AI生態(tài)云峰會」已成功舉辦4場，微眾銀行區(qū)塊鏈安全科學家嚴強、達觀數(shù)據(jù)聯(lián)合創(chuàng)始人紀傳俊、騰訊云數(shù)據(jù)庫TDSQL首席架構師張文、阿里云金融科技AI產(chǎn)品負責人王巍給觀眾帶來了十分精彩的演講，后續(xù)還將有360數(shù)科首席科學家張家興、融慧金科董事長兼CEO王勁、華為云FusionInsight首席架構師徐禮峰、摸象科技董事長高鵬等眾多大咖前來分享最新、最有貨的科技觀點。
以下為張文的演講內(nèi)容，雷鋒網(wǎng)AI金融評論作了不改變原意的編輯：
大家晚上好，很高興能在雷鋒網(wǎng)這個平臺帶來關于分布式數(shù)據(jù)庫的分享，今天主要的議題是《騰訊云分布式數(shù)據(jù)庫在銀行核心系統(tǒng)的改造實踐》。
眾所周知，2020年12月24日，騰訊云數(shù)據(jù)庫官宣TDSQL品牌整合升級計劃，集中發(fā)力數(shù)據(jù)庫技術創(chuàng)新突破。騰訊云原有的TDSQL、TBase、CynosDB三大產(chǎn)品線統(tǒng)一升級為“騰訊云企業(yè)級分布式數(shù)據(jù)庫TDSQL”。全新升級后的騰訊云TDSQL將涵蓋金融級分布式、分析型、云原生等多引擎融合的完整數(shù)據(jù)庫產(chǎn)品體系。本次分享將主要以金融級分布式版TDSQL的實踐進行介紹，下述以“TDSQL”為簡稱。
銀行的“核心系統(tǒng)”，對于數(shù)據(jù)庫廠商而言是一個比較大的挑戰(zhàn)。
銀行，我們都知道有核心系統(tǒng)和外圍系統(tǒng)，核心系統(tǒng)是銀行心臟中的心臟。
銀行的核心系統(tǒng)改造，對于數(shù)據(jù)庫廠商而言是一個很大的考驗。數(shù)據(jù)庫廠商需要面對包括數(shù)據(jù)的一致性、高可用，以及SQL的兼容性等等一系列復雜問題。
過去我們的核心系統(tǒng)，包括銀行核心，還有一些政務核心系統(tǒng)，對外國廠商的依賴度超過了90%，包括軟、硬件，硬件主要是依賴于國外的大型機，小型機。
軟件方面，像操作系統(tǒng)和數(shù)據(jù)庫軟件，整個一套技術架構都采用的是國外的產(chǎn)品。直到現(xiàn)在，在技術自主創(chuàng)新大趨勢浪潮下，從硬件到軟件，我們逐步在進行國產(chǎn)化的探索。
硬件上，我們開始嘗試用基于X86或者是ARM的國產(chǎn)化硬件，以構成底層的硬件平臺；軟件上，從操作系統(tǒng)到數(shù)據(jù)庫，包括一些中間件，在國產(chǎn)化方面近幾年涌現(xiàn)出了很多基礎類軟件。
所以，現(xiàn)在整體的技術導向是：從軟件到硬件整個基礎平臺開始向國產(chǎn)化的態(tài)勢發(fā)展，而不僅僅局限于數(shù)據(jù)庫。
對于分布式數(shù)據(jù)庫而言，如何迎合這樣的契機和挑戰(zhàn)？
為什么早期國外的商用數(shù)據(jù)庫和商用的基礎軟件，在國內(nèi)的銀行、政務系統(tǒng)占據(jù)了大量份額？大部分企業(yè)選擇這些基礎軟件，主要訴求是其穩(wěn)定性。以穩(wěn)定性為口碑，經(jīng)過多年打磨，因而國外廠商的這些軟件占據(jù)了壟斷性的地位。
這種壟斷性地位在短時間內(nèi)是不容易被打破的，因為它有個長時間的市場效應，對于使用國外軟件的這些廠商而言，一旦涉及到替換或者升級，就容易產(chǎn)生一些兼容性問題，還有一些遷移成本和改造難度等問題。
對于國產(chǎn)的分布式數(shù)據(jù)庫，如果想要切入政務及銀行系統(tǒng)，首先需要打破長期被國外商用數(shù)據(jù)庫建立起來的一系列壁壘，這些壁壘對于國產(chǎn)物數(shù)據(jù)庫是一系列的挑戰(zhàn)點。
強一致性高可用
作為金融級數(shù)據(jù)庫，可用性和數(shù)據(jù)強一致性是至關重要的，因為在金融場景下，一條數(shù)據(jù)的價值是無法估量的，沒法評估它到底是錯了一分錢還是一個億，或者更多，所以金融級高可用是國產(chǎn)分布式數(shù)據(jù)庫首要面對的一個挑戰(zhàn)。
性能成本
在國產(chǎn)化方面主要基于廉價存儲，因為在分布式的架構下，可以實現(xiàn)線性水平擴展。但是數(shù)量對于分布式數(shù)據(jù)庫而言，并不是一昧的堆機器、堆存儲、堆計算，那樣實際上是很浪費資源的。分布式數(shù)據(jù)庫組成一個較大的集群，假如有上千臺機器，那么如果在性能方面提高20%，就能節(jié)省上百臺的機器，甚至能節(jié)省出來一個機房。
所以，性能成本也是分布數(shù)據(jù)庫一直在探索的以較低的成本獲取較高的性能，這也是我們追求的一個性價比。
水平伸縮
對于分布式數(shù)據(jù)庫，水平伸縮能力是必須要具備的，因為分布式數(shù)據(jù)庫在互聯(lián)網(wǎng)場景算是需要比較常態(tài)化的水平伸縮。
例如應對如雙11購物節(jié)、春晚紅包的突增流量，需要有一個迅速的彈性擴展能力以承載這些流量。而業(yè)務有峰值就有谷值，活動結束后，需要再將這些資源進行回收。這種水平伸縮能力，是分布式數(shù)據(jù)庫應當具備的基本點，任何分布式數(shù)據(jù)庫都需要具備這種可伸縮、可拓展的能力。
產(chǎn)品化程度
產(chǎn)品化程度是用戶能否快速上手的關鍵。
比如從一個傳統(tǒng)的集中式數(shù)據(jù)庫轉換到分布式數(shù)據(jù)庫，尤其是對于一些政企類、金融客戶而言，他們能否從傳統(tǒng)觀念或者傳統(tǒng)數(shù)據(jù)庫的環(huán)境下，過渡到分布式數(shù)據(jù)庫的環(huán)境和條件，這類客戶其網(wǎng)絡往往跟外網(wǎng)是隔離的，也就是在用戶出了問題之后，我們沒法第一時間登錄他的環(huán)境，幫助其進行調(diào)試，就需要他自助的完成。
如果沒有比較成熟且產(chǎn)品化的一套解決方案，用戶出了問題只能7x24小時找到廠商解決，非常低效。所以，產(chǎn)品化程度也是至關重要的。
早期那些國外的商務數(shù)據(jù)庫也是歷經(jīng)多年打磨，才慢慢的讓這些傳統(tǒng)廠商的數(shù)據(jù)庫團隊、科技團隊接受的。
關鍵案例
前面幾點做得再好、再花哨，如果是沒有關鍵案例的驗證，一切都是竹籃打水一場空，“實踐是檢驗真理的唯一標準”，做得再好都需要有案例加以證明其可行性，對于分布式數(shù)據(jù)庫的挑戰(zhàn)，最重要的一點也是最為關鍵的一點，就是實實在在的案例。
如果沒有人用，大家都處于觀望狀態(tài)。關鍵案例是分布式數(shù)據(jù)庫面臨的最大挑戰(zhàn)，目前來看，國內(nèi)的傳統(tǒng)廠商、銀行、政企，還是外企的份額居多，國內(nèi)的分布式數(shù)據(jù)庫也是在近幾年才殺出一條血路。
所以，關鍵案例方面，除了需要TDSQL，也需要所有的友商共同探索，將關鍵案例不斷的迭代、鋪開，有了更多案例的證明，國產(chǎn)分布式數(shù)據(jù)庫的影響力也好，口碑也罷，包括大家的接受程度，才能慢慢地得到提高。
這里的非技術層次的挑戰(zhàn)更偏向于產(chǎn)品側，主要分為以下4個挑戰(zhàn)：
質量可靠
對于一款分布式數(shù)據(jù)庫，需要經(jīng)過大量業(yè)務的驗證，產(chǎn)品在成熟或者說正式用于外部之前，一定需要經(jīng)過內(nèi)部的打磨和錘煉，像TDSQL數(shù)據(jù)庫，我們往往都是在內(nèi)部打磨得非常成熟后才將其推向外部。
因為我們的內(nèi)部場景非常多，騰訊也有很多業(yè)務線，例如在類金融場景、社交場景、醫(yī)療健康、互動娛樂，以及各種各樣的公有云的場景加以打磨。
我們秉承著對自己產(chǎn)品認真、負責的態(tài)度，先經(jīng)過內(nèi)部的打磨才推送到外部客戶。因為將產(chǎn)品推送到外部客戶時，實際上已經(jīng)是一個黑盒的環(huán)境，要求我們一定要在內(nèi)部盡可能的提前發(fā)現(xiàn)一些比較關鍵和顯而易見的問題，比如用戶的體驗性和一些使用方面的問題。
持續(xù)投入
數(shù)據(jù)庫的更新迭代非常快，從TB級PB級再到更高數(shù)量級的提升。
因為迭代更新比較快，所以要求廠商要有一個穩(wěn)定的數(shù)據(jù)庫團隊持續(xù)地跟進演進。
對于TDSQL而言，作為騰訊內(nèi)部唯一的自研數(shù)據(jù)庫品牌，我們團隊也要緊跟技術的演進和變化，除了服務外部客戶還要服務內(nèi)部，因為無論是內(nèi)部還是外部都是我們的關鍵的客戶，都是我們非常重視的使用場景。
像騰訊這種體量的互聯(lián)網(wǎng)公司，需要一支比較穩(wěn)定，并且可以不斷緊跟著技術的演進和發(fā)展不斷迭代的數(shù)據(jù)庫團隊。
團隊建設
需要我們的數(shù)據(jù)庫有自己的生態(tài)，包括用戶從集中式轉換到分布式的配套工具，周邊文檔資料，人員的招聘，還有一些過渡保障措施。
TDSQL是兼容MySQL、PostgreSQL生態(tài)的，而這些生態(tài)是一個非常龐大的數(shù)據(jù)庫圈子，其文檔和資料，以及全世界的活躍社區(qū)都給我們提供了很多的學習參考的途經(jīng)，我們一些技術水平比較高的銀行合作伙伴往往在出了問題之后，對于一些比較基本的問題，都是自己通過查閱相關資料加以解決。
對于我們的客戶而言，選用了一款分布式數(shù)據(jù)庫，它也要考慮自己團隊對新型分布式數(shù)據(jù)庫的維護能力。
服務能力
服務能力要求分布式數(shù)據(jù)庫的具有完善的服務機制與生態(tài)體系。比如用戶出了問題之后，能夠第一時間真的需要到現(xiàn)場，能夠第一時間去就近服務，包括一個完善的區(qū)域的合作伙伴的服務機制。
在服務能力方面，TDSQL也在全國培養(yǎng)了很多的技術支持團隊幫助，引導客戶解決問題。比如一些重大的節(jié)日保障，或者是涉及到一些重大變更，需要我們的合作伙伴立刻到達現(xiàn)場，做業(yè)務的割接、切換或者是大規(guī)模的災備演練。比如對一個機房進行斷電的容災演練，我們也有專門的團隊去支持，DBA團隊也有服務合作伙伴，共同為客戶保駕護航。
目前，我們在華東、華南、華北都有專門的服務團隊。
作為一款成熟的分布式數(shù)據(jù)庫產(chǎn)品，除了要在技術側加以打磨，還需要有足夠的案例輸出，同時在服務體系、整合能力還有持續(xù)演進能力方面，都要有與之相匹配的能力。否則，它就沒有辦法成為一個成熟完善的商業(yè)化產(chǎn)品。
為什么在騰訊的土壤下能誕生出像TDSQL這樣的數(shù)據(jù)庫？
首先，騰訊是一個依托百億級賬戶數(shù)量的互聯(lián)網(wǎng)公司，其數(shù)據(jù)規(guī)模、場景相對而言比較有挑戰(zhàn)性。
例如，幾年前微信春節(jié)紅包的峰值超過了每秒20萬筆，對于任何數(shù)據(jù)庫而言都是一個比較大的考驗，如果不按照分布式進行拆分，那么，沒有任何一個大機或者小機能承載這樣的業(yè)務壓力。
眾所周知，互聯(lián)網(wǎng)業(yè)務營銷活動比較多，在活動前、活動后，其請求還有峰值都是指數(shù)級的數(shù)量，對數(shù)據(jù)庫的容量、伸縮能力是一個很大的考驗。
TDSQL，依托騰訊云這個載體，服務于政務、金融、電商、社交，還有智慧城市等等各種場景的打磨。另外，TDSQL在公有云上服務于各行各業(yè)和各種場景的用戶，這些都是對TDSQL各種場景的打磨。
最后就是持續(xù)的投入。
伴隨著TDSQL迭代的這10年，騰訊加以持續(xù)的投入，不斷的打磨產(chǎn)品。因為數(shù)據(jù)庫對于這種體量的互聯(lián)網(wǎng)公司而言至關重要。騰訊有著百億的賬戶，豐富的內(nèi)部產(chǎn)品線和業(yè)務線，任何一個這種互聯(lián)網(wǎng)業(yè)務產(chǎn)品都會對數(shù)據(jù)庫有著強依賴。在數(shù)據(jù)庫方面，TDSQL不僅是作為外部的一個產(chǎn)品，在內(nèi)部也是承擔了一個比較重要的作用。
在這里，詳細的介紹一下到底什么是TDSQL，其應對的主要場景有哪些？
按照官方最新解讀，TDSQL是騰訊推出的一款多引擎融合分布式數(shù)據(jù)庫品牌。
所以TDSQL覆蓋三類數(shù)據(jù)庫場景，分別是：分布式數(shù)據(jù)庫，云原生數(shù)據(jù)庫以及分析型數(shù)據(jù)庫。所以，TDSQL分為三個產(chǎn)品序列，分別是金融級分布式TDSQL、云原生共享存儲的TDSQL-C以及分析型數(shù)據(jù)庫的 TDSQL-A。
這樣的多引擎超融合體系針對數(shù)據(jù)庫場景的幾個關鍵領域，都提供了特定場景的解決方案，比如云原生數(shù)據(jù)庫，在存儲層基于共享存儲做分布式的就是TDSQL-C。
在面對金融場景或者政務系統(tǒng)的聯(lián)機交易和離線跑批場景，分別是分布式TDSQL和分析型TDSQL-A的兩個產(chǎn)品。實際上，TDSQL是騰訊整個一套分布式數(shù)據(jù)庫的解決方案，無論是在線聯(lián)機型的，還是離線分析型的，或者是基于共享存儲的分布式型場景，它都可以輕松應對。
金融級分布式版TDSQL的核心特性包括以下幾點：
首先，數(shù)據(jù)強一致，因為在金融場景下，數(shù)據(jù)不丟不錯是至關重要的。
第二，金融級高可用，在金融場景至少要保證99.999%的可用性，因為金融除了其本身的行業(yè)因素外，更重要的是它還受到監(jiān)管的約束。無論是對內(nèi)還是對外服務，TDSQL是按照99.9999%的可用性要求的。高性能低成本，作為分布式數(shù)據(jù)庫，盡可能要讓所有的X86、ARM的廉價存儲方式榨干機器的資源，帶給整個分布式數(shù)據(jù)庫高吞吐量的增益效果。
再者，企業(yè)級安全，雖然需要實現(xiàn)企業(yè)級安全的不只是數(shù)據(jù)庫，但數(shù)據(jù)庫一定要做這種最后一根救命稻草的保障。比如數(shù)據(jù)的誤刪、誤操作，對于一些銀行客戶而言，可能一年或者幾個月都不會發(fā)生一次，但是，我們面對著云上的客戶，每天都有客戶誤刪、誤操作，在這方面TDSQL積累、總結了大量的經(jīng)驗、教訓。對此，我們也有很多的解決方案包括SQL防火墻、透明加密、自動備份等——如何更快速的幫助用戶找回數(shù)據(jù)、恢復其可用性，經(jīng)過這么多年的打磨，我認為我們是非常專業(yè)的。
線性水平擴展能力：分布式數(shù)據(jù)庫一定要具備伸縮、可擴展能力。
最后，便捷的運維——這套分布式數(shù)據(jù)庫交付到客戶手里，用戶要能夠自行掌控、操作。而不是出了問題后，只能7×24小時的給廠商打電話，這也不是我們的初衷和訴求。
最底層的是資源池。
TDSQL既可以基于物理機部署，也可以基于虛擬機，我們可以將這個資源池簡單理解成一個iaas 服務層的概念，在資源池上方提供了兩種形態(tài)的存儲節(jié)點，一種是Noshard數(shù)據(jù)庫，另外一種是分布式數(shù)據(jù)庫，分別代表了單機版和分布式兩種形態(tài)。
作為分布式TDSQL，為什么還要有一種形態(tài)是單機版的？
對于一個廠商、一個銀行或者一個金融客戶而言，并非所有業(yè)務都會用到分布式數(shù)據(jù)庫，或者不一定所有的都是業(yè)務大表，它可能是多個業(yè)務之間有交叉，真正涉及到分布式的可能是一部分表，還有一部分可能是非分布式的。
在這種產(chǎn)品形態(tài)下，同時兼容分布式和非分布式，因為分布式下有一些使用限制，比如語法的限制、分布式事務的性能損耗，以及跨數(shù)據(jù)節(jié)點的join.
在分布式下，因為兩個數(shù)據(jù)節(jié)點是一定分布在兩個不同的物理節(jié)點上的，如果在這兩個物理節(jié)點之間的數(shù)據(jù)做join，很容易造成拉表，相當于是把兩個物理節(jié)點上的數(shù)據(jù)要統(tǒng)一匯總到一個節(jié)點上進行join，這樣的效率不是很高。
而單機版的則沒有這個問題，因為數(shù)據(jù)的拖拽都是在單臺物理節(jié)點的內(nèi)存中，所以，Noshard的形態(tài)可以自由做表與表之間的join，但是在分布式上會有性能方面的消耗，這也說明了分布式和非分布式兩者各有優(yōu)缺點。
所以，我們在存儲節(jié)點保留了兩種形態(tài)，用戶可以根據(jù)需要自行選擇，比如業(yè)務實例要求必須得做到分布式，需要將數(shù)據(jù)分散，包括將來考慮到業(yè)務的拆分，我們就要用分布式的；如果沒有強烈的訴求，我們提供單機版的就能滿足需求。此外，從單機模式轉換成分布式模式，TDSQL自帶的同步遷移工具也是支持的。
再往上是計算節(jié)點。
首先，OLTP型引擎主要包括了讀寫分離、SQL改寫、分布式事務以及關聯(lián)查詢。
除此之外，對于計算節(jié)點，需要處理一些比較復雜的SQL，需要對其進行拆分，包括將執(zhí)行計劃下推等等，就屬于OLAP型的計算邏輯。
所以，計算節(jié)點在分布式下的工作相對還是比較復雜的，在內(nèi)部，計算節(jié)點又被稱為SQL引擎，作為所有SQL的入口，它會對SQL進行分發(fā)，對一些復雜SQL拆解成對應的SQL，再發(fā)到對應的存儲節(jié)點，當存儲節(jié)點取完數(shù)據(jù)之后再回吐到計算節(jié)點，計算節(jié)點對其進行分類匯總，最后回吐到客戶端。
如果把計算節(jié)點、存儲節(jié)點、資源池比作一個黑盒，那么赤兔運營管理平臺就是一個用戶接口，所有的DBA操作都是通過赤兔管理平臺來操縱存儲節(jié)點、計算節(jié)點、資源池。
以往，DBA要做數(shù)據(jù)庫的變更，比如主備切換或者重啟，需要登錄到后臺，比如計算節(jié)點，存儲節(jié)點執(zhí)行SQL命令，現(xiàn)在只要通過赤兔管理平臺頁面按鈕可以完成90%以上的操作，極大地減少了DBA的誤操作風險。
雖然有用戶界面，但是如果DBA確實是要登錄到后臺了解更詳細的信息也沒有問題，一樣允許登錄到對應節(jié)點的后臺進行查看。
赤兔運營管理平臺主要是為DBA提供用戶接口，它還對計算節(jié)點、存儲節(jié)點，包括機器IO、CPU網(wǎng)絡等各種信息的上百項指標進行統(tǒng)計匯總，并且當監(jiān)控告警系統(tǒng)的指標出現(xiàn)異常時，可以在第一時間發(fā)出告警。
那么，“扁鵲”智能DBA平臺有什么作用？
打個比方，某天晚上發(fā)生了機房斷電，數(shù)據(jù)庫也發(fā)生了切換，第二天早上DBA收到一個告警，線上前一天晚上發(fā)生了切換（當然這個業(yè)務是正常切換過來了，然后對業(yè)務的影響也是可控的），DBA需要知道為什么會發(fā)生切換，只需要在智能DBA平臺上點一下“故障分析”，智能DBA自動到機器上分析操作系統(tǒng)和數(shù)據(jù)庫日志，原來是操作系統(tǒng)發(fā)生了重啟，這樣 DBA就不需要再手動登錄到機器上查看信息。
再比如上線了一個新業(yè)務，上線了新業(yè)務之后瞬間卡死不可用。這時就找到DBA投訴，“之前數(shù)據(jù)庫用得好好的，怎么一上新業(yè)務就不行了？”
實際上，可能是新上線的業(yè)務產(chǎn)生了一條慢SQL，慢SQL并發(fā)量又比較大，然后把數(shù)據(jù)庫連接耗盡。按照傳統(tǒng)的做法，這時DBA也是先分析日志，找到這條慢SQL，然后再一點點的進行分析。
而通過智能DBA平臺，可以進行一鍵診斷，智能DBA平臺可自動篩選出那條慢SQL，并且告訴DBA需要對這條慢SQL如何進行優(yōu)化。
有了智能DBA平臺，就可以將我們從一些日常的、重復性的繁雜工作中解放出來，這套平臺也是我們對外口碑最好的一套平臺，尤其對于傳統(tǒng)客戶而言是非常受用的，能極大地提高DBA的工作效率，同時降低處理問題時在時間上的損失。
調(diào)度系統(tǒng)，負責整個集群的資源調(diào)度和管理，包括計算節(jié)點，如何組成一套數(shù)據(jù)庫實例，跟下方資源池里的資源如何進行重組、搭配，都是調(diào)度系統(tǒng)需要做的事情。
備份系統(tǒng)，沒有備份的數(shù)據(jù)庫屬于一個裸奔狀態(tài)，在這方面，TDSQL提供了豐富的備份策略，如全量的、增量的、物理的、邏輯的、日志的等各種各樣的策略?？梢酝瓿啥c恢復、庫表結構恢復、指定表的恢復等等。
服務模塊，服務模塊屬于比較高級功能，主要應對一些特殊性場景，如：審計、數(shù)據(jù)訂閱、數(shù)據(jù)治理，以及SQL防火墻，數(shù)據(jù)遷移等等。
比如用戶需要從原生的MySQL遷移到TDSQL，或者從其它異構數(shù)據(jù)庫把TDSQL遷移到其中，都涉及到數(shù)據(jù)遷移，我們有專門的數(shù)據(jù)遷移模塊，包括TDSQL的兩種形態(tài)之間，包括從分布式到單機版，從單機版到分布式，都依賴于這樣的數(shù)據(jù)遷移。
數(shù)據(jù)遷移也彰顯了TDSQL不綁架用戶的一個初衷，這也是TDSQL開放生態(tài)的一個特點，基于MySQL生態(tài)的數(shù)據(jù)庫在遷移過來之后一定不用擔心將你綁架——也就是它不讓你遷出去，因為日志、數(shù)據(jù)結構都是開源的，有很多種工具提供了在線、離線的遷移方式。
如果用戶覺得TDSQL不好用，可以通過我們的遷移工具再將數(shù)據(jù)遷走，數(shù)據(jù)進出自由，并非綁死在TDSQL。
運營管理
赤兔監(jiān)控：這里羅列的幾項指標，是SQL引擎請求量的對比，包括與前一日的對比曲線。
智能告警：如果報警標紅就會閃爍，如果只有監(jiān)控而沒有告警，其實是起不到任何作用的，一定要將監(jiān)控與告警關聯(lián)，才能起到預警作用。
扁鵲系統(tǒng)：其內(nèi)部邏輯非常復雜，主要是基于騰訊多年來海量運維的經(jīng)驗，形成的策略庫、語法庫。通過在這方面經(jīng)驗的積累，對一些常見的故障進行分析和識別并處理。
一鍵運維：TDSQL赤兔管理臺的首頁，它包含的功能在我們看來如果DBA數(shù)據(jù)庫管理員有這套東西，基本上是可以做到只在頁面上完成所有的操作，不需要登錄到后臺進行變更、維護。
第一個案例：微眾銀行
微眾銀行是在2014年開始籌建，最終采用了TDSQL，并搭建分布式架構核心系統(tǒng)。微眾銀行對于機房的部署是，在同城有5個機房異地有2個機房，按照傳統(tǒng)意義上的理解，這同城的5個機房如果做成1主4備，其余4個機房都有可能會浪費。因為只有1個機房沒有讀寫請求。
微眾銀行對上述機房的部署肯定沒法充分利用機房的資源。對此，又是怎么解決的呢？
首先，將數(shù)據(jù)庫規(guī)劃成一個個的 DCN，一個DCN模型就是一個小的微眾銀行的分行、網(wǎng)絡分行，一個分行只固定500萬的賬戶數(shù)，這500萬的客戶數(shù)也是經(jīng)過了一系列的壓測驗證，至少這500萬放在這個單機版的TDSQL上是安全的，不會有性能的瓶頸。
如果超過500萬，比如客戶數(shù)到了600萬，就再加一個DCN，實際數(shù)據(jù)庫的實例層是由多個DCN組成了一套集群，而多個DCN之間相互沒有聯(lián)系，因為用的都是單機版的TDSQL。
那么，微眾銀行是如何利用這種單機版的Noshard模式實現(xiàn)整體的分布式呢？
微眾銀行還引入了一個組件GNS， GNS被稱作全局路由，業(yè)務訪問數(shù)據(jù)庫一定要經(jīng)過GNS，之后，GNS告訴他所需要的數(shù)據(jù)在DCN的具體位置，業(yè)務再把對應的SQL發(fā)到對應的DCN。
所以，GNS解決了路由的問題。
在這種情況下，如果要做分布式事務該怎么辦？傳統(tǒng)的分布式數(shù)據(jù)庫，對于用戶側而言就是一個begin，然后增刪、改查、commit。
如果增刪、改、查里涉及到的多個DCN對業(yè)務是透明的，但是在這種情況下，實際上沒法做到完全的透明。
對此，微眾銀行又引入了一個組件RMB——可靠的消息隊列，是處理分布式事務的，也就是在一筆分布式事務到達后，首先要在RMB這里注冊一個分布式事務的總事務，之后再由RMB完成子事務的分發(fā)，最后它會確保所有的分布式事務所涉及到的 DCN在處理完成后，返回給業(yè)務端。
微眾的數(shù)據(jù)庫是怎么部署的呢？利用多個IDC交叉部署，第一個DCN的主放在IDC1，第二個DCN的主放在IDC2，以此類推，其所有DCN的主是交叉部署在這5個機房的。
如果最后是500個DCN，有5個機房，每個機房就放100個DCN，這樣的好處在于每個機房的讀寫流量是均勻的，并不會造成像原來所有的讀寫都壓在1個機房，其余4個機房都是stand by的角色。
所以，微眾銀行這套架構從整體上看，實現(xiàn)了5個機房資源的充分利用。
任何一個機房的故障都只會影響1/5的流量，不會造成系統(tǒng)性的宕機。
像以前這種1主4備的模式，如果主節(jié)點壞掉，整個全行所有的服務都會癱瘓，雖然最后也會切換，但是其過程對全行的業(yè)務是有影響的。
如果按照分散的方式，就會產(chǎn)生另外一個問題，一個節(jié)點壞掉之后，使得1/5的業(yè)務受到影響，而原來的1主4備的模式，如果壞掉的是一個備機，那正常業(yè)務就不會受到影響。所以，這其中存在著可用性和成本之間的博弈。
第二個案例：張家港銀行
張家港銀行是我們對傳統(tǒng)銀行核心系統(tǒng)進行的一次徹頭徹尾地改造。
首先，它是一家傳統(tǒng)銀行，并非新成立。其次，它的核心系統(tǒng)是針對傳統(tǒng)銀行打造的。從微眾銀行到張家港銀行已經(jīng)過去大概5年的時間，整個TDSQL在產(chǎn)品迭代方面已經(jīng)有了很大的變化。
對于張家港銀行而言，首要考慮的問題是性能，其早期的數(shù)據(jù)庫是Sybase數(shù)據(jù)庫，大概是10年前的一個架構。在張家港銀行在業(yè)務高峰期經(jīng)常有卡頓、超時的問題，所以其訴求就是要升級成一個能滿足行里現(xiàn)在業(yè)務場景的數(shù)據(jù)庫。
第二，張家港銀行的量級相對較小，其訴求就是成本。
另外，改造的難度，在業(yè)務方面，微眾銀行在數(shù)據(jù)庫方面做了很多的自身的改造。
比如引入了GNS、RMB，這些都是微眾自己進行維護的。并且從一開始，微眾銀行基于自身的定位，更多地還是想?yún)⑴c金融創(chuàng)新，定位自身為一家金融科技公司。而張家港銀行更希望能快速地解決自身的問題并且把東西用起來。
所以，張家港銀行的架構圖就非常清晰和簡單，就是一個標準的分布式兩地三中心的架構，同城總行機房部署一組主節(jié)點和一組備機節(jié)點，同城的災備機房部署一組備節(jié)點，整個分布式實例采用一主三備四分片的架構。
此外，在異地還有一組異步節(jié)點。從整體看，沒有任何的復雜組件，張家港銀行采用的這種形態(tài)與微眾銀行的截然不同。
TDSQL有兩種形態(tài)——Noshard和shard，張家港銀行完全采用了后者的形態(tài)，這樣，張家港銀行就不需要引入諸如GNS、RMB等組件,因為我們的SQL引擎會助其自動做路由，以及分布式事務管理。
所以，張家港銀行直接使用分布式shard版的TDSQL，對于業(yè)務而言，只需進行細微的調(diào)整和改動，例如重新設計庫表。按照這種分片關鍵字，一些大表需要選擇其分片關鍵字。
再者，就是將之前用到的存儲過程、觸發(fā)器的一些計算邏輯，盡可能地上提到業(yè)務代碼中。因為在分布式數(shù)據(jù)庫下，數(shù)據(jù)庫盡可能的只做數(shù)據(jù)的存取，否則很容易產(chǎn)生性能問題。
按照這種策略和思路，對張家港銀行的改造大概歷時半年完成，改造完之后，整個性能提升非常明顯，查詢交易在100毫秒以內(nèi)完成，高頻交易在300毫秒內(nèi)完成，像貸款結息這種跑批業(yè)務與原來相比得到成倍的提升，體現(xiàn)出分布式的一個優(yōu)勢。
性能方面，原來在硬件成本方面需要4~5000萬，現(xiàn)在不足1000萬。同樣的成本，在oracle下是8000的TPS而在TDSQL下是6200的TPS。
在整體性能差異不大的情況下，成本已下降到了不足原來的1/5。同時TDSQL可以通過繼續(xù)加機器來提高集群的吞吐能力，所以性能還可以不斷地提升，具備橫向擴展的能力。
第三個案例：平安銀行
平安銀行更具代表性。平安銀行的體量與張家港銀行相比又上升了一個數(shù)量級，同時其應用改造的難度相對而言也是一個比較有挑戰(zhàn)性的工作。今年，我們完成了支持平安銀行信用卡核心從傳統(tǒng)集中式架構的大型機下移至分布式平臺。
平安銀行采用了TDSQL Noshard和Groupshard兩種架構。為了配合此次改造，應用引入了微服務架構對應用進行了拆分和解耦。對賬號的分布進行了單元化劃分，以DSU為一個邏輯單元，單個DSU包含200萬個客戶信息，單個DSU同時處理聯(lián)機和賬務兩種業(yè)務。這樣做的好處：一方面避免跑批時段消耗資源過多對聯(lián)機交易的，另外一方面避免由于基礎架構的故障導致全局不可用。。
平安銀行也有統(tǒng)計分析類型的業(yè)務，如果按照Noshard架構，對應用開發(fā)要求比較高，需要將統(tǒng)計類的SQL拆分成多個子SQL分發(fā)給多個noshard實例。
groupshard架構更適合， 從邏輯上來看，Groupshard架構對于應用而言就是多個獨立的邏輯表，應用不需要關心數(shù)據(jù)是如何組織分布的。由于要對數(shù)據(jù)進行統(tǒng)計分析，數(shù)據(jù)訪問量較大。所以，這種場景下，在訪問需要的數(shù)據(jù)時，應用只需把SQL發(fā)給SQL引擎，SQL引擎會對SQL進行拆分、并行下推,再進行結果集的聚合。
同時，TDSQL Noshard和Groupshard兩套集群之間通過TDSQL自帶的同步組件完成實時數(shù)據(jù)同步。
政務系統(tǒng)
第七次全國人口普查的數(shù)據(jù)采集處理工作，對于我們的TDSQL而言也是具有重要意義的。
首先，其數(shù)據(jù)量的規(guī)模是10億級別的，峰值QPS是百萬級。
這種情況，無論在我們內(nèi)部業(yè)務還是外部業(yè)務都是非常罕見的，對于TDSQL性能的要求，包括跨節(jié)點之間的通信、分布式事務的處理都是比較大的挑戰(zhàn)。
因為人口普查涉及到國家政務的敏感信息，我們不便將其詳細的架構圖畫出來。
但可以肯定的是，基于TDSQL多引擎融合技術，第七次全國人口普查穩(wěn)健完成了數(shù)據(jù)采集處理工作。
欲了解更多活動詳情，可聯(lián)系負責人周舟（微信：18811172358）。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權禁止轉載。詳情見轉載須知。
