騰訊云數(shù)據(jù)庫【國產(chǎn)數(shù)據(jù)庫專題線上技術(shù)沙龍】正在火熱進(jìn)行中，4月28日陳愛聲的分享已經(jīng)結(jié)束，沒來得及參與的小伙伴不用擔(dān)心，以下就是直播的視頻和文字回顧。
創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的蘇州網(wǎng)站設(shè)計(jì)、移動媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
關(guān)注“騰訊云數(shù)據(jù)庫”公眾號，回復(fù)“0428陳愛聲”，即可下載直播分享PPT。
TBase多中心多活與高可用方案實(shí)踐_騰訊視頻
大家好，我是陳愛聲，目前負(fù)責(zé)騰訊云TBase產(chǎn)品實(shí)施和運(yùn)維相關(guān)工作。
今天的主題是TBase多中心多活與高可用方案的實(shí)踐，集中圍繞著多中心多活以及高可用切換方案進(jìn)行講解，分享的方案都已經(jīng)有實(shí)施案例。
分享總共分四個(gè)部分：
第一部分：介紹TBase的服務(wù)組件，即TBase由哪些服務(wù)組件組成，這些服務(wù)組件在部署的時(shí)候有哪些要注意的地方，以及部署的拓?fù)浣Y(jié)構(gòu)是怎樣的。
第二部分：TBase多活部署的介紹，在這個(gè)章節(jié)里會涉及到兩地兩中心部署，VPC隔離、主備讀寫分離，各種方案的介紹。
第三部分：節(jié)點(diǎn)級故障的切換，比如我們在單機(jī)的實(shí)例里面，主節(jié)點(diǎn)故障了，備節(jié)點(diǎn)如何切換過來。針對TBase來說，由于它的服務(wù)組件非常多，每個(gè)服務(wù)組件也有主備節(jié)點(diǎn)，這一章節(jié)中將詳細(xì)講述各個(gè)組件故障，影響力的范圍，以及它是怎樣進(jìn)行切換的，切換完以后對整個(gè)服務(wù)的影響。
第四部分：中心級的故障切換，這個(gè)章節(jié)主要講述應(yīng)用場景，為什么會存在中心級的切換，以及它的切換成本。中心級切換這個(gè)是最難實(shí)現(xiàn)的，整個(gè)切換成本以及切換的復(fù)雜度非常大。
我們先看下TBase的服務(wù)架構(gòu)，下圖我相信經(jīng)常關(guān)注TBase的同學(xué)，應(yīng)該對這張圖并不陌生。我今天會重點(diǎn)對這張圖里各個(gè)服務(wù)組件進(jìn)行非常詳細(xì)的介紹。
圖中我們可以看到整個(gè)TBase由三大組件組成，最左邊是GTM組件，右上角是CN組件，下面是DN組件，接下來將詳細(xì)介紹下這三個(gè)組件，以及它部署的時(shí)候應(yīng)該注意的地方。
首先我們看最左邊的GTM組件，這個(gè)是做什么用的呢？這個(gè)實(shí)際上跟全局事務(wù)ID的（分發(fā)器）一樣。在使用單機(jī)的時(shí)候，事務(wù)管理是放在內(nèi)存里面的，TBase是一個(gè)分布式數(shù)據(jù)庫，也有事務(wù)ID的管理，事務(wù)ID的管理是通過一個(gè)叫GTM的組件來進(jìn)行管理，所有你的請求，不管是讀還是寫，你首先要拿到這樣一個(gè)事務(wù)ID，來實(shí)現(xiàn)讀寫的一致性。
GTM的組件在部署的時(shí)候是支持一主多備的，圖上只是畫了一主一備的，但部署的時(shí)候它可以支持一個(gè)主多個(gè)備，主備的復(fù)制級別可以配置成強(qiáng)同步，也可以配置成異步。GTM只有主能夠提供服務(wù)，備機(jī)永遠(yuǎn)不會提供服務(wù)，備機(jī)的作用就是拿來同步主節(jié)點(diǎn)上有兩個(gè)信息，一個(gè)是事務(wù)ID，第二個(gè)是GTM上有全局的序列，我們要請求序列訪問時(shí)它也必須要訪問這個(gè)GTM，所以GTM的負(fù)載主要來自于這兩方面：
GTM對CPU的需求比較高，一個(gè)實(shí)例里面如果它有幾十個(gè)節(jié)點(diǎn)、上百個(gè)節(jié)點(diǎn)的時(shí)候，所有節(jié)點(diǎn)都向它請求事務(wù)ID，那么它主要消耗就是在CPU，所以在要求部署GTM節(jié)點(diǎn)時(shí)首先要考慮這臺機(jī)器必須具備多個(gè)核。那么到底有多少個(gè)呢？就看你的請求量，如果你是高并發(fā)業(yè)務(wù)的話，那么你的CPU的核數(shù)需要更多，它甚至可以運(yùn)行到幾十個(gè)。雖然GTM只有主能提供服務(wù)，但基本上已經(jīng)能夠覆蓋所有業(yè)務(wù)的請求，每秒會達(dá)到千萬級的請求。
GTM同時(shí)也會寫日志，雖然GTM對磁盤IO性能要求不高，但還是有一定IO的保證，在部署GTM的時(shí)候，大家一定要注意如果是和別的服務(wù)在一起的時(shí)候，要有一定的IO量給它，最好有一個(gè)獨(dú)立的磁盤，哪怕是一個(gè)比較普通的sas盤也可以，它雖然不需要那么多，但它一定要保證，沒有保證可能會導(dǎo)致請求失敗。內(nèi)存可以適當(dāng)，因?yàn)榛旧戏?wù)是很輕的，對內(nèi)存的計(jì)算量是要求不會很高，一般像幾十個(gè)核的CPU上面可能就配個(gè)64G的內(nèi)存，可以配個(gè)200G空間的SSD或者那種sas盤就可以滿足一個(gè)GTM的部署要求。最簡單的就是一主一備，就可以實(shí)現(xiàn)高可用。
接下來我們再談一下右上角的CN，這個(gè)是協(xié)調(diào)節(jié)點(diǎn)。在其他的分布式數(shù)據(jù)庫上也可能叫PROXY節(jié)點(diǎn)，CN可以有多個(gè)主提供服務(wù)，是業(yè)務(wù)連接的入口，即應(yīng)用程序要連哪個(gè)IP，連哪個(gè)PORT就是到CN這邊來，比如說我們這里可能有三個(gè)IP，三個(gè)PORT，那么任何一個(gè)IP、一個(gè)PORT都可以提供給應(yīng)用程序連接，他們都是對等的。那么CN上面存儲的是什么？存儲的是元數(shù)據(jù)，我們定義的庫、表、用戶、視圖等等之類，這些元數(shù)據(jù)都會存在于每個(gè)CN上面，除了這個(gè)之外還有一個(gè)非常重要的信息，上面每一個(gè)CN節(jié)點(diǎn)還存有一份全局的路由信息，那么為什么要存路由信息呢？是因?yàn)樗械膽?yīng)用SQL請求，需要根據(jù)路由信息才能計(jì)算SQL要發(fā)到那一個(gè)存儲節(jié)點(diǎn)。CN在部署的時(shí)候，一般最少兩個(gè)，或者你可以部署一個(gè)，但是需要部署一個(gè)CN備機(jī)，就是CN需要主備，建議每一個(gè)CN有主備，CN做為分布式事務(wù)的協(xié)調(diào)者，CN故障，分布式事務(wù)就會存在問題，這個(gè)時(shí)候如果有備機(jī)的話那很簡單，備機(jī)切換為主，就能夠保證這個(gè)事務(wù)繼續(xù)往下面執(zhí)行。
CN在部署的時(shí)候有硬件的要求，一般要求CPU的核數(shù)比較多，如果有業(yè)務(wù)類型是必須把數(shù)據(jù)拉到CN節(jié)點(diǎn)進(jìn)行計(jì)算等等之類的，那么它對內(nèi)存的要求比較高，大多數(shù)計(jì)算是可以推到DN下面執(zhí)行。磁盤的要求也就我剛才前面所說的，如是果需要數(shù)據(jù)拉回CN落盤計(jì)算，即需要配置高性能SSD盤。如果你有物化視圖，那么這些物化視圖的數(shù)據(jù)實(shí)際上是會存在CN的，那你的CN要有比較大的存儲空間才可以。CN部署建議二個(gè)及以上，然后都有主備，主備之間可以配置強(qiáng)同步，這樣的話一旦有故障你就可以切換過來，把事務(wù)繼續(xù)運(yùn)行下去。
最下面Datanode是DN節(jié)點(diǎn)。DN節(jié)點(diǎn)是拿來存用戶數(shù)據(jù)的，用戶數(shù)據(jù)是我們所有的用戶連接CN以后，他所有的請求會全部推到下面的DN上來，那么它是怎樣推的呢？它根據(jù)上面CN路由的信息，推到一個(gè)DN某個(gè)節(jié)點(diǎn)來，會把這個(gè)數(shù)據(jù)保存在Datanode，每個(gè)Datanode就是一個(gè)分片，如有一億條數(shù)據(jù)，有4個(gè)分片，那么合理分片存儲后，大概每個(gè)分片2500萬條數(shù)據(jù)左右。Datanode在部署時(shí)最少要一主一備，哪怕是單中心也是最少要一主一備，因?yàn)椴还苣囊粋€(gè)分片故障，沒有備機(jī)的話相當(dāng)于你整份數(shù)據(jù)就少了四分之一，實(shí)際上就是數(shù)據(jù)不完整了，相當(dāng)于數(shù)據(jù)缺失了，這個(gè)跟CN沒有備機(jī)的情況下，CN節(jié)點(diǎn)壞了都沒關(guān)系，實(shí)際上只要連接到另一個(gè)好的CN就可以。那到底要多少個(gè)分片呢？這個(gè)就取決于我們的業(yè)務(wù)，DN節(jié)點(diǎn)部署也是需要按單機(jī)的實(shí)例節(jié)點(diǎn)的規(guī)范來做基本規(guī)劃，比如說你要求每一個(gè)節(jié)點(diǎn)盡可能不要超過多少個(gè)T，超過了以后實(shí)際上對你運(yùn)維成本是很高的。
DN總體上是對硬件最苛刻的，機(jī)器要求CPU核心多、內(nèi)存大，IO要好，因?yàn)樗侵苯佑?jì)算存儲，簡而言之按照單機(jī)有什么樣好的配置就照著用就可以。
關(guān)于服務(wù)組件的介紹我總結(jié)如下圖，方便大家理解。
接下來我們進(jìn)入第二個(gè)章節(jié)，TBase多活部署介紹。我們可以看一下部署的拓?fù)浣Y(jié)構(gòu)，首先看的第一張圖是一種傳統(tǒng)的主備的部署模式。
圖上顯示可理解為不管是南北異地也好、還是同城雙中心也好，它永遠(yuǎn)只有一個(gè)主中心，也就是最上面只有一個(gè)主中心能夠提供一個(gè)讀寫的能力，其他的節(jié)點(diǎn)都只能提供一個(gè)只讀的能力。如果要求主備強(qiáng)同步，那么同城雙中心署，控制延遲在3毫秒以內(nèi)，對于大多數(shù)業(yè)務(wù)是能接受的。異地主備節(jié)點(diǎn)雖然也可以配置成強(qiáng)同步，但是實(shí)際上大延遲對業(yè)務(wù)的影響是非常大的，會導(dǎo)致TPS下降得非常厲害。比如說從北方到廣州，那么它的時(shí)延往往都是在30到50毫秒之間，根據(jù)不同網(wǎng)絡(luò)質(zhì)量，1個(gè)請求來回就是100毫秒，這樣一個(gè)延遲基本上是不能接受，服務(wù)器原來一條數(shù)據(jù)更新，就是幾個(gè)毫秒，現(xiàn)在一下子來回變成100毫秒，這樣你的硬件不管怎樣提升都沒辦法滿足你的業(yè)務(wù)需求。
還有一點(diǎn)，我們的應(yīng)用可能需要數(shù)據(jù)導(dǎo)到消息中間件，比如說最常見的（KAFKA），主備部署結(jié)構(gòu)，只有主節(jié)點(diǎn)能夠做到邏輯解析，這個(gè)本身是PG的技術(shù)限制，只有主節(jié)點(diǎn)才能做到邏輯解析，然后把這些數(shù)據(jù)解析到（KAFKA），異地的不管是同城的還是跨城的，它到異地的數(shù)據(jù)就沒辦法同步到消息中間件，那你在異地做消息交換的時(shí)候就必定成本會很高，每一個(gè)消息交換就只能在主中心完成。這個(gè)是傳統(tǒng)主備的部署方式的架構(gòu)。
接下來我分享下雙活的部署架構(gòu)，這是一個(gè)雙活的部署架構(gòu)，那么雙活的部署架構(gòu)是什么樣的呢？
大家可以看到南邊一套完整的實(shí)例，北邊也是一套完整的實(shí)例，這兩套是完全獨(dú)立的，你可以把它理解為兩套互不相干的實(shí)例一樣，但是我們又想把這兩套實(shí)例綁定在一起，認(rèn)為它是兩套一模一樣的數(shù)據(jù)庫，里面存的數(shù)據(jù)都是一樣的。這里采用了南北的雙向同步的技術(shù)，也就是邏輯復(fù)制技術(shù)，南邊的機(jī)器和北邊的機(jī)器這兩個(gè)實(shí)例他們之間是通過邏輯復(fù)制來實(shí)現(xiàn)雙向的數(shù)據(jù)同步，這里南北都可以提供讀寫，數(shù)據(jù)都是可以同步到消息中間件，從而可以實(shí)現(xiàn)本地化訪問，不管我的應(yīng)用在哪里，或者和別的應(yīng)用做數(shù)據(jù)交換。
對于原來是單中心應(yīng)用，現(xiàn)在把業(yè)務(wù)庫拆成南北以后，有一些共享的數(shù)據(jù)，這里要拆分是比較困難，現(xiàn)在共享的數(shù)據(jù)不拆開，南邊放一份，北邊放一份，使用雙活數(shù)據(jù)同步從而實(shí)現(xiàn)雙中心多活支撐。
傳統(tǒng)的主備部署和雙活部署架構(gòu)，他們連接的都是指向一個(gè)物理IP，就像我們前面說到的CN節(jié)點(diǎn)。但如果發(fā)生故障，連接物理IP就改變了，這對應(yīng)用來說它是有入侵性的，應(yīng)用要不斷的修改數(shù)據(jù)庫連接的IP，那么我們又改進(jìn)了一種架構(gòu)，我們基于TBase，再加上騰訊云的另外一個(gè)組件就是VPCGW，重新規(guī)劃了一種新的部署架構(gòu)。
如上圖所示，我們在最前面會加上一個(gè)VPC，相當(dāng)于加上一個(gè)虛擬網(wǎng)絡(luò)，所有的微服務(wù)不管是讀還是寫，都有一個(gè)VIP，然后由這個(gè)VIP再路由CN節(jié)點(diǎn)，這樣就可以實(shí)現(xiàn)連接透明性。另外VPCGW還能支持多個(gè)CN接入節(jié)點(diǎn)負(fù)載均衡。
這里我來總結(jié)下雙活與主備的差異。
那么雙活和主備對比有哪些優(yōu)勢呢？
那么雙活帶來挑戰(zhàn)是什么？
接下來這個(gè)章節(jié)會給大家重點(diǎn)介紹下關(guān)于節(jié)點(diǎn)級故障的切換方案。
如果GTM主備是強(qiáng)同步配置，則系統(tǒng)選擇新的備GTM。
如果沒有備GTM,就會影響GTM數(shù)據(jù)同步，影響業(yè)務(wù)訪問，那要對它同步模式進(jìn)行降級，由原來的主備強(qiáng)同步變成異步。
影響事務(wù)ID獲取，系統(tǒng)不可用，這時(shí)需要選擇日志同步最新的備機(jī)切換為GTM主。
切換完后還要修改路由，每一個(gè)DN、CN的GTM路由信息都修改需要。
GTM復(fù)制級別降級處理，如果切換后沒有GTM備機(jī)，降級成功以后才能夠?qū)ν馓峁┓?wù)。
DN備故障，只讀服務(wù)能力失效，這種故障發(fā)生時(shí)怎樣去切換呢？
這其實(shí)很簡單，由于我們前面加了一個(gè)VIP，這個(gè)VIP只要指向CN主就可以繼續(xù)訪問。
如果故障節(jié)點(diǎn)備機(jī)是有多個(gè)的話，把另外一個(gè)備機(jī)加進(jìn)只讀平面，則只讀取也能繼續(xù)使用。
原來主備是強(qiáng)同步的，如果這里沒有可用備機(jī)，主備同步就必須要降級，降為異步，不然數(shù)據(jù)寫不進(jìn)來。
系統(tǒng)進(jìn)行主備倒換，從多個(gè)同步備機(jī)就從中選出最新的備機(jī)來作為一個(gè)新主，另外你也可以人工強(qiáng)制倒換過去。
修改所有節(jié)點(diǎn)的訪問路由信息，指向新的DN節(jié)點(diǎn)
如果該DN節(jié)點(diǎn)主備切換后無備節(jié)點(diǎn)可用，則需要對原來的強(qiáng)同步進(jìn)行降級為異步。
如果有只讀平面，則只讀平面還要修改指向主平面。
如果CN節(jié)點(diǎn)配置為強(qiáng)同步，同時(shí)有新的CN備節(jié)點(diǎn)存在，則需要選擇新的備CN升級為強(qiáng)同步節(jié)點(diǎn)。
如果沒有新CN備節(jié)點(diǎn)，復(fù)制級別要降級為異步模式。
如果只讀平面所有節(jié)點(diǎn)不完整，則只讀VIP切換指向CN主節(jié)點(diǎn)。
故障的CN不影響其它CN主節(jié)點(diǎn)對應(yīng)提供服務(wù)，VIP會將故障的CN主節(jié)點(diǎn)從負(fù)載均衡表中刪除。
CN故障節(jié)點(diǎn)進(jìn)行主備切換，從可用的備節(jié)點(diǎn)中選擇新的主進(jìn)行切換。
修改各個(gè)節(jié)點(diǎn)中訪問故障CN節(jié)點(diǎn)的路由信息表。
切換后如果沒有可用的備CN節(jié)點(diǎn)，則節(jié)點(diǎn)的同步級別需要調(diào)整為異步復(fù)制 。
如果備平面VIP對應(yīng)的CN備機(jī)列表無IP可用，則系統(tǒng)修改只讀平面的VIP指向CN主節(jié)點(diǎn)。
介紹完三個(gè)節(jié)點(diǎn)，我們可以再來看一下中心級。
這里舉個(gè)例子方便大家理解，如對外光纖全部給挖斷了，或者整個(gè)實(shí)例是不能用的。如圖所示，南北網(wǎng)絡(luò)可能已經(jīng)是不通了，北邊不能用，只剩下南邊可用了，這個(gè)時(shí)候怎么辦呢？我們只要修改最上層的微服務(wù)訪問路由即可，可能是一個(gè)DNS變更，由于數(shù)據(jù)是近乎同步的，它能夠讀到的數(shù)據(jù)還是一致的，也可以提供讀寫服務(wù)，而對于還沒有同步過來的數(shù)據(jù)，在網(wǎng)絡(luò)或者系統(tǒng)正常后，差異的數(shù)據(jù)會自動同步過來。
如果使用主備同步數(shù)據(jù)，由于南部跨地域的物理位置決定不可能使用同步復(fù)制，在發(fā)生故障時(shí)，基本上是不可能去切換的，因?yàn)槟愕那袚Q成本太高了，首先管控平臺要進(jìn)行切換，再次數(shù)據(jù)庫要切換，后期的數(shù)據(jù)如何去修復(fù)是很困難的。
從中心級的故障切換來看，多活部署的架構(gòu)，異地切換時(shí)數(shù)據(jù)庫不需要做任何操作。對于微服務(wù)來說，是切DNS，等故障恢復(fù)，數(shù)據(jù)同步完成以后，只要把DNS回切回去，把流量切回去就可以了。對于業(yè)務(wù)可用性，體驗(yàn)性要好，雙活切換成本低，提供了一種相對輕量級的成本，讓這種真正的跨南北的切換成為可能。
Q：主備節(jié)點(diǎn)個(gè)數(shù)如何選擇？
A：雙活的部署南中心的DN節(jié)點(diǎn)肯定都是一主一備或者是一主兩備，北中心也是一主一備或者一主兩備，因?yàn)閮蛇叾际强梢詫憽Ｋ运渴鸬臅r(shí)候?qū)嶋H上是兩套完全獨(dú)立的實(shí)例，需要在本地提供高可用的保障。
Q：CN有沒有搞主備的必要性？
A：CN多個(gè)是要解決壓力負(fù)載均衡的問題，而主備還解決分布式事務(wù)的連續(xù)性的問題，CN是會參與一些分布式事務(wù)的，比如說我們建表，建數(shù)據(jù)庫，CN是做一個(gè)協(xié)調(diào)節(jié)點(diǎn)，如果一次事務(wù)有兩條數(shù)據(jù)，有一條是插入到DN1，有一條是更新到DN2，那么就屬于分布式事務(wù)，那么CN就要管理這些事務(wù)，如果沒有主備，一擔(dān)CN主完全故障不可用，則分布式事務(wù)就無法繼續(xù)下去。如果你是業(yè)務(wù)類型里是有分布式事務(wù)，還是建議CN節(jié)點(diǎn)有主備節(jié)點(diǎn)存在。
Q：多活是否支持強(qiáng)同步，延遲有多大？
A：多活是沒有強(qiáng)同步方式的，多活是基于邏輯復(fù)制的，只能采用異步同步模式，延遲大小，比如從北京到廣州的話，數(shù)據(jù)從這邊到那邊可見的延遲大概在200毫秒，但實(shí)際它是異步的，對你的業(yè)務(wù)不影響。也就是說，你的前端用戶感覺是很快，慢就慢在后端的數(shù)據(jù)同步那里，基本上如果你的網(wǎng)絡(luò)是可靠的，性能沒影響的情況下，你一條數(shù)據(jù)從南到北的話，這個(gè)由于物理網(wǎng)絡(luò)決定，也就大概在200毫秒左右。
Q：雙活這種結(jié)構(gòu)從目前來看，最大的是解決一個(gè)什么樣的問題呢？
A：當(dāng)前很多業(yè)務(wù)他們單中心的，幾百種業(yè)務(wù)可能1000多套實(shí)例全部放在一個(gè)中心里，不管是北京的、還是廣州、全部部署在廣州或者全部堆在北京，那么異地連接過來開銷比較大，延遲比較大。但是把它拆開，北京就放在北京，廣東就放到廣東，這樣的話你是把業(yè)務(wù)庫拆開了，但實(shí)際上由于原來在單中心的時(shí)候他們的交互在一個(gè)中心完成，那么他們之間交互的延遲是很低的，你拆分之后對于需要不同系統(tǒng)交換數(shù)據(jù)的應(yīng)用，延遲變大，雙活剛好解決用戶體驗(yàn)延遲問題。
VPCGW組件是騰訊云另一個(gè)產(chǎn)品，這個(gè)不包含在TBase里面?？梢再徺I騰訊云的TCE平臺。
Q：運(yùn)維管理系統(tǒng)是否為開源工具實(shí)現(xiàn)？
A：主備切換都是自己開發(fā)的工具，我們的運(yùn)維系統(tǒng)是自研的，這個(gè)沒有用到第三方現(xiàn)在組件，因?yàn)槟壳皝砜?，外面第三方的一些工具還是很難滿足整個(gè)復(fù)雜運(yùn)維管控系統(tǒng)，所以我們的運(yùn)維管控系統(tǒng)是自研的。
Q：單機(jī)和分布式的有哪些區(qū)別？
A：分布式可以實(shí)現(xiàn)多個(gè)分片在線擴(kuò)展，處理更多的并發(fā)請求，存儲數(shù)據(jù)量也更大，滿足業(yè)務(wù)不斷擴(kuò)大的需求。而單機(jī)的只能擴(kuò)展備機(jī)數(shù)量，但如果數(shù)據(jù)量和訪問量壓力不大的情況下，單機(jī)的運(yùn)行效率要好于分布式，運(yùn)維也比分布式要簡單。
以上是今天的分享和Q&A的解答，感謝大家的聆聽。
TBase是騰訊TEG數(shù)據(jù)庫工作組三大產(chǎn)品之一，是在開源的PostgreSQL基礎(chǔ)上研發(fā)的企業(yè)級分布式HTAP數(shù)據(jù)庫管理系統(tǒng)。通過單一數(shù)據(jù)庫集群同時(shí)為客戶提供高一致性的分布式數(shù)據(jù)庫服務(wù)和高性能的數(shù)據(jù)倉庫服務(wù)，形成一套融合完整的企業(yè)級解決方案。大家在數(shù)據(jù)庫領(lǐng)域遇到相關(guān)問題時(shí)，歡迎隨時(shí)留言。
微信支付用的數(shù)據(jù)庫開源了
重慶分公司
重慶分公司
