騰訊資料庫RTO<30s,RPO=0高可用方案首次全景揭祕

為幫助開發者更好地瞭解和學習分散式資料庫技術，2020年3月，騰訊雲資料庫、雲加社群聯合騰訊TEG資料庫工作組特推出為期3個月的國產資料庫專題線上技術沙龍《你想了解的國產資料庫祕密，都在這！》，邀請數十位鵝廠資深資料庫專家每週二和週四晚上線上深入解讀TDSQL、TBase、CynosDB三款鵝廠自研資料庫的核心架構、技術實現原理和最佳實踐等。三月為TDSQL專題月，本文將帶來直播回顧第三篇《破解分散式資料庫的高可用難題：TDSQL高可用方案實現》。點選下圖觀看直播回放及領取PPT：

以下是分享全文：

大家好，今天我分享的主題是TDSQL多地多中心高可用方案。TDSQL是騰訊推出的金融級分散式資料庫。在可用性和資料一致性方面，基於自主研發的強同步複製協議，在保證資料的跨IDC雙副本的同時，具備較高的效能。在強同步複製的基礎上，TDSQL又實現了一套自動化容災切換方案，保證切換前後資料零丟失，為業務提供7×24小時連續高可用服務。

事實上，不光是資料庫，任何對可用性有較高要求的系統都需要具備高可用的部署架構。這裡面會涉及到一些專業術語如：異地、多活、雙活、選舉等，今天的分享中都會講到，除此之外還包括我們耳熟能詳的兩地三中心、兩地四中心、同城雙活等概念。值得一提的是，今天這次分享不光是對資料庫，對任何高可用系統的部署架構都具有參考借鑑的意義。

本次分享我們會介紹TDSQL的幾種典型部署架構，以及各種架構的優缺點。因為在實際生產實踐中，會有各種各樣的資源條件限制，比如同城有一個機房和有兩個機房的容災效果就完全不一樣。再比如雖然有兩個機房，但是這兩個機房的規格相差比較大，有的機房可能網路鏈路比較好，而有的機房可能網路鏈路比較差，等等…所以，如何在有限的資源條件下搭建一套價效比高或者說效能比高TDSQL，是我們這次分享要探討的主要內容。

在正式切入正題前，我們先回顧一下上一次分享有關TDSQL的核心特性以及整體架構。

好，接下來我們先看一下TDSQL核心特性。

我們今天的重點聚焦在“金融級高可用”上。TDSQL如何做到99.999%以上的可用性呢？所謂五個九的高可用意味著的是，全年不可用時間不可超過5分鐘。我們知道，故障是一種無法避免的現象，同時故障也是分級的，從軟體故障，作業系統故障，再到機器重啟、機架掉電這是一個災難級別從低到高的過程，對於金融級資料庫需要考慮和應對更高階別的故障場景，如：整個機房掉電甚至機房所在的城市發生地震、爆炸等自然災害。如果發生這類故障，我們的系統首先能否保證資料不丟，其次在保證資料不丟的前提下需要多久恢復服務，這都是金融級高可用資料庫需要考慮的問題。

首先，我們回顧一下TDSQL的關鍵特性—強同步機制，它是TDSQL保證資料不會丟、不會錯的關鍵，並且相比於MySQL的半同步複製，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仍採用“一主兩備”結構，很顯然我們需要將三個資料節點分別部署在三個機房，其中主節點在一個機房，兩個備節點分別部署在另外兩個機房。

我們再看架構圖，剛剛說了它是一個對稱的結構。從上往下首先看業務，每個機房可能都部署有業務系統，每個機房的業務通過LVS負載接入訪問到TDSQL的SQL引擎。由於在同一機房需要部署多個SQL引擎提供高可用服務，而對於業務來說更希望遮蔽後端多個SQL引擎的訪問方式，所以這裡引入一層LVS接入層，業務只需訪問負載均衡的VIP即可。當請求到達SQL引擎後，根據路由資訊將SQL發到master或者slave節點，最後返回業務資料。我們再看資料節點，一主兩備分別部署在三個機房，任何一個機房故障，master節點都可以切換到另外兩個機房中的一個。同城三中心架構下，從計算層到儲存層都不存在單點，做到了高可用容災。任意一個機房的故障都不會造成資料丟失，同時在TDSQL一致性切換機制的保證下，能夠在30s內完成故障節點的切換。

這個圖裡面沒有畫出管理節點，我們剛剛也說了管理節點可以看做整個叢集的大腦，負責判斷當前的全域性態勢。三個機房很明顯需要部署三顆大腦，之所以是“三”剛剛也講過，當其中一個大腦出問題的時候，另外兩個可以形成多數派，完成相互投票確認將故障大腦踢除。

“同城單中心”架構的場景有幾種情況：

第一種場景是IDC資源比較緊張，只有一個資料中心。這種場景下做不到跨機房部署，只能按照跨機架方式部署，當主節點故障或者主節點所在的機架故障，能夠自動切換。

第二種場景是業務追求極致的效能，甚至不能容忍跨IDC網路延遲。雖然現在的機房之間都是光纖網路，相隔50km的兩個機房之間的網路延遲也只有不到1ms。但有些特殊的業務甚至無法忍受1毫秒的延遲。這種情況下我們只能將主備部署在同一機房。

第三類是作為異地災備機房。作為災備儲存一般也沒有實際業務訪問，更多的可能是做備份歸檔，因此對它的資源投入比較有限。

第四種是作為測試環境，這個就不多說了。

“兩地三中心”資料庫例項的部署架構

部署方式方面，我們從上往下看，分別是同城兩個機房和異地一個災備機房。最上層是叢集的大腦管理模組，分別跨三個機房部署。

管理模組的部署可以採用“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小時高可用部署架構。

最後我們總結一下今天的分享：

• 首先，對於跨城市容災一般建議在異地搭建獨立的叢集模式，通過非同步複製實現同步。主城和備成可以採用不同的部署方式，如主城一主三備，備城一主一備的方式靈活自由組合。
• 現網運營的最佳方案是同城三中心加一個異地災備中心，其次是金融行業標準的兩地三中心的架構。這兩種架構都能輕鬆實現資料中心異常自動切換。
• 如果只有兩個資料中心，做不到任意資料中心異常都能自動切換，需要一些權衡。

不光是對於資料庫系統，任何做一種高可用系統都需要做基於部署架構方面的考量，這就是本次分享的全部，謝謝大家。

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：多數派選舉。