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