溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
騰訊云數據庫國產數據庫專題線上技術沙龍正在火熱進行中，3月12日張文的分享已經結束，沒來得及參與的小伙伴不用擔心，以下就是直播的視頻和文字回顧。
關注“騰訊云數據庫”公眾號，回復“0312張文”，即可下載直播分享PPT。
破解分布式數據庫的高可用難題：TDSQL高可用方案實現_騰訊視頻
大家好，今天我分享的主題是TDSQL多地多中心高可用方案。TDSQL是騰訊推出的金融級分布式數據庫。在可用性和數據一致性方面，基于自主研發的強同步復制協議，在保證數據的跨IDC雙副本的同時，具備較高的性能。 在強同步復制的基礎上，TDSQL又實現了一套自動化容災切換方案，保證切換前后數據零丟失，為業務提供7×24小時連續高可用服務。
事實上，不光是數據庫，任何對可用性有較高要求的系統都需要具備高可用的部署架構。這里面會涉及到一些專業術語如：異地、多活、雙活、選舉等，今天的分享中都會講到，除此之外還包括我們耳熟能詳的兩地三中心、兩地四中心、同城雙活等概念。值得一提的是，今天這次分享不光是對數據庫，對任何高可用系統的部署架構都具有參考借鑒的意義。
本次分享我們會介紹TDSQL的幾種典型部署架構，以及各種架構的優缺點。因為在實際生產實踐中，會有各種各樣的資源條件限制，比如同城有一個機房和有兩個機房的容災效果就完全不一樣。再比如雖然有兩個機房，但是這兩個機房的規格相差比較大，有的機房可能網絡鏈路比較好，而有的機房可能網絡鏈路比較差，等等…所以，如何在有限的資源條件下搭建一套性價比高或者說效能比高TDSQL，是我們這次分享要探討的主要內容。
在正式切入正題前，我們先回顧一下上一次分享有關TDSQL的核心特性以及整體架構。
好，接下來我們先看一下TDSQL核心特性。
我們今天的重點聚焦在“金融級高可用”上。TDSQL如何做到99.999%以上的可用性呢？所謂五個九的高可用意味著的是，全年不可用時間不可超過5分鐘。我們知道，故障是一種無法避免的現象，同時故障也是分級的，從軟件故障，操作系統故障，再到機器重啟、機架掉電這是一個災難級別從低到高的過程，對于金融級數據庫需要考慮和應對更高級別的故障場景，如：整個機房掉電甚至機房所在的城市發生地震、爆炸等自然災害。如果發生這類故障，我們的系統首先能否保證數據不丟，其次在保證數據不丟的前提下需要多久恢復服務，這都是金融級高可用數據庫需要考慮的問題。
首先，我們回顧一下TDSQL的關鍵特性—強同步機制，它是TDSQL保證數據不會丟、不會錯的關鍵，并且相比于MySQL的半同步復制，TDSQL強同步復制的性能更是接近于異步。
那么這個高性能強同步是如何工作的呢？強同步復制要求任何一筆應答業務成功的請求，除了在主機落盤成功以外，還需在至少一個備機落盤成功。所以我們看到，一個請求到了主機之后，立刻發送發給備機，當兩臺備機中的一臺應答成功之后主機才能應答業務成功。也就是說任何成功應答給前端業務的請求一定會有兩個副本，一份在主節點上，另外一份在備節點上。所以，強同步是數據多副本的關鍵性保障。TDSQL通過引入了線程池模型與靈活的調度機制，將工作線程異步化，實現了對強同步的性能大幅提升，改造后其吞吐量接近于異步。
（TDSQL核心架構）
看完強同步，我們接下來再回顧一下TDSQL的核心架構。負載均衡是業務的入口，業務請求經過負載均衡到達SQL引擎模塊，SQL引擎再將SQL轉發到后端數據節點。圖中的上半部分是集群的管理調度模塊，作為集群的總控制器承擔著資源管理、故障調度等工作。所以，TDSQL整體分為：計算層、數據存儲層，以及集群管理節點。集群管理節點我們之前強調過，一個集群部署一套就行，一般是3個、5個、7個這樣的奇數個部署。為什么是奇數呢？因為當發生災難的時候，奇數個能夠形成選舉，話句話說，比如3個節點部署在3個機房，其中有1個機房故障的話，而另外兩個機房可以互通并且都連不上第三個機房，就可以對第三個機房故障達成共識將其踢除。我們可以把三個機房的管理模塊理解為集群的三顆大腦，這組大腦壞掉一個后，如果剩余的大腦能夠在數量上達到初始數量的一半就可以繼續提供服務反之則不行。
以上是對TDSQL一些核心特性的回顧，接下來我們看一下各個模塊在機型上的選擇。對于計算與存儲相分離的分布式架構數據庫，我們該如何選擇機器？我們知道，要想讓一個IT系統發揮出最大的價值，就是要盡可能地榨干機器的資源，讓這些資源物有所值效能比高。如果這個機器CPU跑得很滿，但是IO沒有什么負載，或者說內存配128個G但實際上只用了2個G。這種就屬于效能比非常低的部署，無法發揮出機器以及系統的整體性能。
首先是LVS模塊，首先作為接入層它不是一個TDSQL的內部組件，TDSQL的SQL引擎兼容不同的負載均衡，比如軟件負載LVS、硬件負載L5等。作為接入層的負載均衡一般都是CPU集型服務，因為它需要維護管理大量鏈接請求，相對較為耗CPU和內存。所以這里推薦的配置中CPU比較高，16vCPU，32G內存，一定是萬兆網口。到了今天，網卡設備的成本已經非常低了，所以一般都給裝配萬兆網卡。而vCPU這里強調的是邏輯核16核就可以（可能實際物理核只有8個），因為我們大部分程序都是多線程的。
我們再看計算節點。如果集群規模較小，同時資源相對比較緊張，計算節點可以跟存儲節點復用機器，因為存儲節點的機型基本能夠滿足計算節點的需求，一個16vCPU，32G+內存，萬兆網口。
說完了接入層和計算層，下面我們再看看數據存儲層。存儲節點負責數據存取，屬于IO密集型服務，建議用PCI-E的SSD，并且需要獨站物理機。對于數據庫來說，我們推薦部署在真實的物理機上，相比虛擬機更為穩定。此外，有條件的建議再做一層Raid0，讓數據節點的讀寫能力更為強勁。有些同學肯定會問，數據節點為什么不做一個Raid5、Raid10而直接做Raid0。因為TDSQL本身已經是一主多從的架構，甚至可以加更多從機，在磁盤陣列這里我們就沒必要繼續做冗余，無限冗余只會讓效能比降低。作為數據節點，這里推薦的配置是32vCPU，64G內存。數據節點采用的Innodb引擎是一個優先使用緩存的引擎，也就是說大內存對性能的提升具有顯著的作用。所以，這里推薦大內存，萬兆網，PCI-E的SSD的機型。
接下來是管理節點：推薦配置是8核CPU、16G內存，萬兆網口。管理節點任務比較輕，一個集群也只需要少量的管理節點。如果說沒有物理機用虛擬機也可以，配置相對于前面的計算、存儲節點明顯可以低一些。
備份節點的話，硬盤越大越好，它主要負責存儲冷數據，用普通的SATA盤就可以。
以上機器的型號不用太關注，是騰訊內部的一個編號，沒有什么實際意義。這里簡單做一個總結，計算節點依賴CPU和內存，對磁盤沒有太多要求。存儲節點雖然對CPU內存也要求較高，但它更強調IO的強勁（需要PCI-E的SSD）。
通過剛剛的介紹希望可以幫助大家進一步加深對TDSQL，尤其是這種計算存儲相分離的數據庫的認識。從機型配置的解讀我們可以清楚的了解，怎樣的機型搭配能夠讓系統的性能發揮最佳。
總結起來，如果機型正確搭配，業務也按照規范使用，那么就可以輕松發揮出數據庫強勁的性能，即以較低的運營成本獲取較高的業務支撐能力。海量的業務都是伴隨著現金流，比如說廣告、游戲、電商，一套低成本的系統如果在滿負荷工作下輕松高效處理這類業務請求，帶來的經濟效應是比較可觀的。
第三部分，開始切入我們的正題，這一章我們將介紹比較典型的幾種部署方案，那些耳熟能詳的名詞：同城三中心，兩地三中心，異地多活，同城雙活分別代表什么意義，或者說能帶來什么樣的效果呢。接下來就為大家一一將這些問題的答案揭開。
第一部分是同城三中心架構。同城三中心顧名思義：在一個城市有A、B、C三個機房，TDSQL仍采用“一主兩備”結構，很顯然我們需要將三個數據節點分別部署在三個機房，其中主節點在一個機房，兩個備節點分別部署在另外兩個機房。
每個IDC提供兩臺高可用的LV5做負載均衡系統。為什么每臺IDC都要放一個LV5？因為每個IDC有自己的業務，對應都需要有一個獨立的負載接入。從接入層看三個機房是一個相對平行的對等架構，三個機房都放了自身的業務，可能第一個機房支撐的是一個全國大區的業務，第二個機房是另外一個大區，對等就是這樣的含義。這種架構比較簡單，整體也比較清晰。
我們再看架構圖，剛剛說了它是一個對稱的結構。從上往下首先看業務，每個機房可能都部署有業務系統，每個機房的業務通過LVS負載接入訪問到TDSQL的SQL引擎。由于在同一機房需要部署多個SQL引擎提供高可用服務，而對于業務來說更希望屏蔽后端多個SQL引擎的訪問方式，所以這里引入一層LVS接入層，業務只需訪問負載均衡的VIP即可。當請求到達SQL引擎后，根據路由信息將SQL發到master或者slave節點，最后返回業務數據。我們再看數據節點，一主兩備分別部署在三個機房，任何一個機房故障，master節點都可以切換到另外兩個機房中的一個。同城三中心架構下，從計算層到存儲層都不存在單點，做到了高可用容災。任意一個機房的故障都不會造成數據丟失，同時在TDSQL一致性切換機制的保證下，能夠在30s內完成故障節點的切換。
這個圖里面沒有畫出管理節點，我們剛剛也說了管理節點可以看做整個集群的大腦，負責判斷當前的全局態勢。三個機房很明顯需要部署三顆大腦，之所以是“三”剛剛也講過，當其中一個大腦出問題的時候，另外兩個可以形成多數派，完成相互投票確認將故障大腦踢除。
“同城單中心”架構的場景有幾種情況：
第一種場景是IDC資源比較緊張，只有一個數據中心。這種場景下做不到跨機房部署，只能按照跨機架方式部署，當主節點故障或者主節點所在的機架故障，能夠自動切換。
第二種場景是業務追求極致的性能，甚至不能容忍跨IDC網絡延遲。雖然現在的機房之間都是光纖網絡，相隔50km的兩個機房之間的網絡延遲也只有不到1ms。但有些特殊的業務甚至無法忍受1毫秒的延遲。這種情況下我們只能將主備部署在同一機房。
第三類是作為異地災備機房。作為災備儲存一般也沒有實際業務訪問，更多的可能是做備份歸檔，因此對它的資源投入比較有限。
第四種是作為測試環境，這個就不多說了。
接下來跟大家聊一聊這次分享的主角——“兩地三中心”架構，它是銀行常見的部署方式，更是監管要求的基本部署架構。這種架構通過同城兩個數據中心加異地一個數據中心，在較低的成本下，提供較好的可用性和數據一致性。在節點異常、IDC異常都能做到自動切換，非常適合金融場景，是TDSQL重點推薦的部署方式。
（“兩地三中心”數據庫實例的部署架構）
部署方式方面，我們從上往下看，分別是同城兩個機房和異地一個災備機房。最上層是集群的大腦管理模塊，分別跨三個機房部署。
管理模塊的部署可以采用“2+2+1”也可以“1+1+1”的方式。我們知道，如果按照“2+2+1”的部署方式，當第一個機房故障時，還剩下“2+1”顆大腦，“2+1”比5的一半要多，剩下的“2+1”形成多數派將故障節點踢掉，同時繼續提供服務。
繼續往下看，我們看到數據節點采用的是“一主三備”的模式，并且是跨機房強同步，同機房異步。為什么同機房這里是異步，不能做強同步？如果同機房是強同步的話，由于它和主節點距離上要比另外兩個跨機房的備節點近（IDC1、IDC2之間相隔了平均至少50公里），業務每次發送給主節點的請求都是這個同機房的強同步節點率先應答，最新的數據永遠都只會落到同機房的備節點。而我們希望數據的兩個副本應該位于相隔50km以上的不同機房，這樣才能保證跨機房主備切換時數據能夠保持一致。
可能有人會問，這個 IDC1 配置的異步節點和不放沒有區別。這里解釋一下為什么有了這個異步節點后更好呢。我們考慮一種情況，當備機房IDC2 發生了故障，備機房里面的兩個節點全部宕機，IDC 1 這里的master節點就成單點了。此時，如果開啟強同步，由于沒有備機應答，主節點依然無辦法提供服務；但如果關閉強同步繼續提供服務，數據存在單點風險，如果這時主節點發生軟件硬件故障，數據就再也無法找回。一個比較好的方案是：給IDC1增加了一個跨機架的異步節點，當IDC2掛掉之后，這個異步節點會提升為強同步。這樣在只剩下一個機房的前提下，我們仍然能夠保證一個跨機架的副本，降低主機的單點風險。
看完主城兩個機房，我們再看看異地災備機房。作為異地災備機房，一般是和主節點相隔500公里以上，延遲在10ms以上的機房。在這樣的網絡條件下，災備節點和主城之間只能采用異步復制的方式同步數據，因而異地災備節點承擔的更多是備份的職責，日常不會有太多正式業務訪問。雖然表面上看有點花瓶，沒有它卻也萬萬不行。假如有一天發生了城市級別故障，災備實例仍可以為我們挽回99%以上的數據。正是由于災備節點和主節點的這種異步弱關系，才允許我們的災備實例在備城是一個獨立部署的單元。
異地災備機房除了作為異步數據備份外，另外一個重要的職責是：當主城的一個機房故障，通過和主城另外一個正常的機房形成多數派，將故障機房踢掉進而完成主備切換。部署在異地的這個大腦，在大部分時間都不參與主城的事宜，只有在主城的一個機房發生故障時才介入。正常情況下，主城的模塊訪問主城的大腦，備城的模塊訪問備城的大腦，不會交叉訪問導致延遲過高的問題。
聊完“三中心”，我們再來聊聊“兩中心”架構。具體來說，同城只有兩個機房，根據我們上一個PPT的經驗，在兩機房部署TDSQL需要按照同機房異步，跨機房強同步的方式部署。因而采用四節點的模式，分布式在2個IDC。
然而“兩中心”架構有個需要權衡的地方是，只有部署在備機房而且故障的不是備中心，才能實現自動跨IDC容災。但如果是備中心故障，事實上，在同機房異步，跨機房強同步的方式下，不管是部署在主機房還是備機房，假如發生故障，無法順利完成多數派選舉以及自動故障切換，要么強同步節點無法被提升形成多數派，要么多數派隨機房故障而故障，需要人工介入。因而在高可用要求的場景下，一般更為推薦“兩地三中心”等7*24小時高可用部署架構。
最后我們總結一下今天的分享：
1. 首先，對于跨城市容災一般建議在異地搭建獨立的集群模式，通過異步復制實現同步。主城和備城可以采用不同的部署方式，如主城一主三備，備城一主一備的方式靈活自由組合。
2. 現網運營的最佳方案是同城三中心加一個異地災備中心，其次是金融行業標準的兩地三中心的架構。這兩種架構都能輕松實現數據中心異常自動切換。
3. 如果只有兩個數據中心，做不到任意數據中心異常都能自動切換，需要一些權衡。
不光是對于數據庫系統，任何做一種高可用系統都需要做基于部署架構方面的考量，這就是本次分享的全部，謝謝大家。
Q：同城主備切換一次多長時間？
A：30秒以內。
Q：兩地三中心的主城是不是設置成級聯？
A：這個問題非常好，如果從主城的視角看，這顯然是一個級聯關系，數據先由主城的master同步到主城的slave，再通過主城的slave同步到備城的master，一層層向下傳遞數據。
Q：請教一下強同步會等SQL回放嗎？
A：不會等，只要IO線程拉到數據即可。因為基于行格式的binlog是具備冪等寫的，我們通過大量的案例證明它是可靠的。此外，增加了apply反而會使得平均時耗的上升和吞吐量的下降。最后，假如apply有問題，TDSQL的監控平臺會立刻識別并告警，提醒DBA確認處理。
Q：備機只存binlog不回放，性能上跟得上主嗎？
A：備機拉取binlog和回放binlog是兩組不同的線程，分別叫IO線程和SQL線程，并且兩組線程互不干擾。IO線程只負責到master上下載binlog，SQL線程只回放拉取到本地的binlog。上一個問題說的是強同步機制不等待回放，并不是說到備機的binlog不會被回放。
Q：同城三中心寫存儲節點都在IDC1，那么在IDC2的業務延遲是不是很大？
A：同城機房現在都是光纖傳輸，時耗基本都是做到1毫秒以下，完全沒必要擔心這種訪問時耗。當然，如果機房設施比較陳舊，或者相隔距離間的網絡鏈路極為不穩定，為了追求卓越性能可能需要犧牲一部分容災能力。
Q：一主兩備，SQL引擎做成故障切換有VIP方式嗎？
A：當然有，多個SQL引擎綁定負載均衡設備，業務通過VIP方式訪問TDSQL，當SQL引擎故障后負載均衡會自動將其踢掉。
Q：這樣不是三個業務各自寫一個庫嗎？
A：不是的，三個業務都寫到主庫。SQL引擎都會路由到主庫，一主兩備。TDSQL強調任何一個時刻只有一個主提供服務，備機只提供讀服務不提供寫服務。
Q：同城多副本，多SET對同城IDC之間網絡要求有什么？
A：5毫秒以內的延遲。
Q：如果兩個強同步主從可以設置其中一個返回？
A：TDSQL強同步默認機制就是等待一臺強同步的備機應答。
Q：中間一個節點掛了，異地節點會不會自動連接到主節點？
A：當然會。
Q：強同步和半同步復制相比的優勢是什么？
A：強同步跟半同步復制相比，最直觀的理解可能有人會問，強同步不就是把半同步的超時時間改成無限嗎？其實不是這樣的，TDSQL強同步這里的關鍵不是在解決備機應答的問題，而是要解決這種增加了等待備機的機制之后，如何能保證高性能、高可靠性。換句話說，如果在原生半同步的基礎上不改造性能，僅把超時時間改成無限大的時候，其實跑出來的性能和異步比甚至連異步的一半都達不到。這個在我們看來也是無法接受的。相當于為了數據的一致性犧牲了很大一部分性能。
TDSQL強同步復制的性能是在原生半同步的基礎上做了大量的優化和改進，使得性能基本接近于異步，并且能實現數據零丟失——多副本，這是DSQL強同步的一個特點。上一期的直播我們介紹了，TDSQL如何實現高性能強同步的。比如經過一系列的線程異步化，并且引入了線程池模型，并增加一個線程調度的優化等。
Q：仲裁協議用的哪一個？
A：多數派選舉。
好的，如果后續有其他問題的話，歡迎在我們技術交流群里面溝通，今天的直播到這里就結束了，再見。謝謝大家！
直播回顧 | 騰訊分布式數據庫TDSQL金融級能力的架構原理解讀
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
