為幫助開發(fā)者更好地了解和學(xué)習分布式數(shù)據(jù)庫技術(shù)，2020年3月，騰訊云數(shù)據(jù)庫、云加社區(qū)聯(lián)合騰訊TEG數(shù)據(jù)庫工作組特推出為期3個月的國產(chǎn)數(shù)據(jù)庫專題線上技術(shù)沙龍《你想了解的國產(chǎn)數(shù)據(jù)庫秘密，都在這！》，邀請數(shù)十位鵝廠資深數(shù)據(jù)庫專家每周二和周四晚上在線深入解讀TDSQL、TBase、CynosDB三款鵝廠自研數(shù)據(jù)庫的核心架構(gòu)、技術(shù)實現(xiàn)原理和最佳實踐等。三月為TDSQL專題月，本文將帶來直播回顧第三篇《破解分布式數(shù)據(jù)庫的高可用難題：TDSQL高可用方案實現(xiàn)》。點擊下圖觀看直播回放及領(lǐng)取PPT：

以下是分享全文：

大家好，今天我分享的主題是TDSQL多地多中心高可用方案。TDSQL是騰訊推出的金融級分布式數(shù)據(jù)庫。在可用性和數(shù)據(jù)一致性方面，基于自主研發(fā)的強同步復(fù)制協(xié)議，在保證數(shù)據(jù)的跨IDC雙副本的同時，具備較高的性能。在強同步復(fù)制的基礎(chǔ)上，TDSQL又實現(xiàn)了一套自動化容災(zāi)切換方案，保證切換前后數(shù)據(jù)零丟失，為業(yè)務(wù)提供7×24小時連續(xù)高可用服務(wù)。

事實上，不光是數(shù)據(jù)庫，任何對可用性有較高要求的系統(tǒng)都需要具備高可用的部署架構(gòu)。這里面會涉及到一些專業(yè)術(shù)語如：異地、多活、雙活、選舉等，今天的分享中都會講到，除此之外還包括我們耳熟能詳?shù)膬傻厝行摹傻厮闹行摹⑼请p活等概念。值得一提的是，今天這次分享不光是對數(shù)據(jù)庫，對任何高可用系統(tǒng)的部署架構(gòu)都具有參考借鑒的意義。

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

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

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

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

TDSQL數(shù)據(jù)庫一致性：強同步機制是最核心的保障

首先，我們回顧一下TDSQL的關(guān)鍵特性—強同步機制，它是TDSQL保證數(shù)據(jù)不會丟、不會錯的關(guān)鍵，并且相比于MySQL的半同步復(fù)制，TDSQL強同步復(fù)制的性能更是接近于異步。

那么這個高性能強同步是如何工作的呢？強同步復(fù)制要求任何一筆應(yīng)答業(yè)務(wù)成功的請求，除了在主機落盤成功以外，還需在至少一個備機落盤成功。所以我們看到，一個請求到了主機之后，立刻發(fā)送發(fā)給備機，當兩臺備機中的一臺應(yīng)答成功之后主機才能應(yīng)答業(yè)務(wù)成功。也就是說任何成功應(yīng)答給前端業(yè)務(wù)的請求一定會有兩個副本，一份在主節(jié)點上，另外一份在備節(jié)點上。所以，強同步是數(shù)據(jù)多副本的關(guān)鍵性保障。TDSQL通過引入了線程池模型與靈活的調(diào)度機制，將工作線程異步化，實現(xiàn)了對強同步的性能大幅提升，改造后其吞吐量接近于異步。

TDSQL核心架構(gòu)

看完強同步，我們接下來再回顧一下TDSQL的核心架構(gòu)。負載均衡是業(yè)務(wù)的入口，業(yè)務(wù)請求經(jīng)過負載均衡到達SQL引擎模塊，SQL引擎再將SQL轉(zhuǎn)發(fā)到后端數(shù)據(jù)節(jié)點。圖中的上半部分是集群的管理調(diào)度模塊，作為集群的總控制器承擔著資源管理、故障調(diào)度等工作。所以，TDSQL整體分為：計算層、數(shù)據(jù)存儲層，以及集群管理節(jié)點。集群管理節(jié)點我們之前強調(diào)過，一個集群部署一套就行，一般是3個、5個、7個這樣的奇數(shù)個部署。為什么是奇數(shù)呢？因為當發(fā)生災(zāi)難的時候，奇數(shù)個能夠形成選舉，話句話說，比如3個節(jié)點部署在3個機房，其中有1個機房故障的話，而另外兩個機房可以互通并且都連不上第三個機房，就可以對第三個機房故障達成共識將其踢除。我們可以把三個機房的管理模塊理解為集群的三顆大腦，這組大腦壞掉一個后，如果剩余的大腦能夠在數(shù)量上達到初始數(shù)量的一半就可以繼續(xù)提供服務(wù)反之則不行。

高可用集群的部署實踐

以上是對TDSQL一些核心特性的回顧，接下來我們看一下各個模塊在機型上的選擇。對于計算與存儲相分離的分布式架構(gòu)數(shù)據(jù)庫，我們該如何選擇機器？我們知道，要想讓一個IT系統(tǒng)發(fā)揮出最大的價值，就是要盡可能地榨干機器的資源，讓這些資源物有所值效能比高。如果這個機器CPU跑得很滿，但是IO沒有什么負載，或者說內(nèi)存配128個G但實際上只用了2個G。這種就屬于效能比非常低的部署，無法發(fā)揮出機器以及系統(tǒng)的整體性能。

首先是LVS模塊，首先作為接入層它不是一個TDSQL的內(nèi)部組件，TDSQL的SQL引擎兼容不同的負載均衡，比如軟件負載LVS、硬件負載L5等。作為接入層的負載均衡一般都是CPU集型服務(wù)，因為它需要維護管理大量鏈接請求，相對較為耗CPU和內(nèi)存。所以這里推薦的配置中CPU比較高，16vCPU，32G內(nèi)存，一定是萬兆網(wǎng)口。到了今天，網(wǎng)卡設(shè)備的成本已經(jīng)非常低了，所以一般都給裝配萬兆網(wǎng)卡。而vCPU這里強調(diào)的是邏輯核16核就可以（可能實際物理核只有8個），因為我們大部分程序都是多線程的。

我們再看計算節(jié)點。如果集群規(guī)模較小，同時資源相對比較緊張，計算節(jié)點可以跟存儲節(jié)點復(fù)用機器，因為存儲節(jié)點的機型基本能夠滿足計算節(jié)點的需求，一個16vCPU，32G+內(nèi)存，萬兆網(wǎng)口。

說完了接入層和計算層，下面我們再看看數(shù)據(jù)存儲層。存儲節(jié)點負責數(shù)據(jù)存取，屬于IO密集型服務(wù)，建議用PCI-E的SSD，并且需要獨站物理機。對于數(shù)據(jù)庫來說，我們推薦部署在真實的物理機上，相比虛擬機更為穩(wěn)定。此外，有條件的建議再做一層Raid0，讓數(shù)據(jù)節(jié)點的讀寫能力更為強勁。有些同學(xué)肯定會問，數(shù)據(jù)節(jié)點為什么不做一個Raid5、Raid10而直接做Raid0。因為TDSQL本身已經(jīng)是一主多從的架構(gòu)，甚至可以加更多從機，在磁盤陣列這里我們就沒必要繼續(xù)做冗余，無限冗余只會讓效能比降低。作為數(shù)據(jù)節(jié)點，這里推薦的配置是32vCPU，64G內(nèi)存。數(shù)據(jù)節(jié)點采用的Innodb引擎是一個優(yōu)先使用緩存的引擎，也就是說大內(nèi)存對性能的提升具有顯著的作用。所以，這里推薦大內(nèi)存，萬兆網(wǎng)，PCI-E的SSD的機型。

接下來是管理節(jié)點：推薦配置是8核CPU、16G內(nèi)存，萬兆網(wǎng)口。管理節(jié)點任務(wù)比較輕，一個集群也只需要少量的管理節(jié)點。如果說沒有物理機用虛擬機也可以，配置相對于前面的計算、存儲節(jié)點明顯可以低一些。

備份節(jié)點的話，硬盤越大越好，它主要負責存儲冷數(shù)據(jù)，用普通的SATA盤就可以。

以上機器的型號不用太關(guān)注，是騰訊內(nèi)部的一個編號，沒有什么實際意義。這里簡單做一個總結(jié)，計算節(jié)點依賴CPU和內(nèi)存，對磁盤沒有太多要求。存儲節(jié)點雖然對CPU內(nèi)存也要求較高，但它更強調(diào)IO的強勁（需要PCI-E的SSD）。

通過剛剛的介紹希望可以幫助大家進一步加深對TDSQL，尤其是這種計算存儲相分離的數(shù)據(jù)庫的認識。從機型配置的解讀我們可以清楚的了解，怎樣的機型搭配能夠讓系統(tǒng)的性能發(fā)揮最佳。

總結(jié)起來，如果機型正確搭配，業(yè)務(wù)也按照規(guī)范使用，那么就可以輕松發(fā)揮出數(shù)據(jù)庫強勁的性能，即以較低的運營成本獲取較高的業(yè)務(wù)支撐能力。海量的業(yè)務(wù)都是伴隨著現(xiàn)金流，比如說廣告、游戲、電商，一套低成本的系統(tǒng)如果在滿負荷工作下輕松高效處理這類業(yè)務(wù)請求，帶來的經(jīng)濟效應(yīng)是比較可觀的。

跨城跨機房級別容災(zāi)部署方案

第三部分，開始切入我們的正題，這一章我們將介紹比較典型的幾種部署方案，那些耳熟能詳?shù)拿~：同城三中心，兩地三中心，異地多活，同城雙活分別代表什么意義，或者說能帶來什么樣的效果呢。接下來就為大家一一將這些問題的答案揭開。

“同城三中心”架構(gòu)

第一部分是同城三中心架構(gòu)。同城三中心顧名思義：在一個城市有A、B、C三個機房，TDSQL仍采用“一主兩備”結(jié)構(gòu)，很顯然我們需要將三個數(shù)據(jù)節(jié)點分別部署在三個機房，其中主節(jié)點在一個機房，兩個備節(jié)點分別部署在另外兩個機房。

每個IDC提供兩臺高可用的LV5做負載均衡系統(tǒng)。為什么每臺IDC都要放一個LV5？因為每個IDC有自己的業(yè)務(wù)，對應(yīng)都需要有一個獨立的負載接入。從接入層看三個機房是一個相對平行的對等架構(gòu)，三個機房都放了自身的業(yè)務(wù)，可能第一個機房支撐的是一個全國大區(qū)的業(yè)務(wù)，第二個機房是另外一個大區(qū)，對等就是這樣的含義。這種架構(gòu)比較簡單，整體也比較清晰。

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

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

“同城單中心”架構(gòu)

“同城單中心”架構(gòu)的場景有幾種情況：

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

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

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

第四種是作為測試環(huán)境，這個就不多說了。

“兩地三中心”架構(gòu)

接下來跟大家聊一聊這次分享的主角——“兩地三中心”架構(gòu)，它是銀行常見的部署方式，更是監(jiān)管要求的基本部署架構(gòu)。這種架構(gòu)通過同城兩個數(shù)據(jù)中心加異地一個數(shù)據(jù)中心，在較低的成本下，提供較好的可用性和數(shù)據(jù)一致性。在節(jié)點異常、IDC異常都能做到自動切換，非常適合金融場景，是TDSQL重點推薦的部署方式。

“兩地三中心”數(shù)據(jù)庫實例的部署架構(gòu)

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

管理模塊的部署可以采用“2+2+1”也可以“1+1+1”的方式。我們知道，如果按照“2+2+1”的部署方式，當?shù)谝粋€機房故障時，還剩下“2+1”顆大腦，“2+1”比5的一半要多，剩下的“2+1”形成多數(shù)派將故障節(jié)點踢掉，同時繼續(xù)提供服務(wù)。

繼續(xù)往下看，我們看到數(shù)據(jù)節(jié)點采用的是“一主三備”的模式，并且是跨機房強同步，同機房異步。為什么同機房這里是異步，不能做強同步？如果同機房是強同步的話，由于它和主節(jié)點距離上要比另外兩個跨機房的備節(jié)點近（IDC1、IDC2之間相隔了平均至少50公里），業(yè)務(wù)每次發(fā)送給主節(jié)點的請求都是這個同機房的強同步節(jié)點率先應(yīng)答，最新的數(shù)據(jù)永遠都只會落到同機房的備節(jié)點。而我們希望數(shù)據(jù)的兩個副本應(yīng)該位于相隔50km以上的不同機房，這樣才能保證跨機房主備切換時數(shù)據(jù)能夠保持一致。

可能有人會問，這個 IDC1 配置的異步節(jié)點和不放沒有區(qū)別。這里解釋一下為什么有了這個異步節(jié)點后更好呢。我們考慮一種情況，當備機房IDC2 發(fā)生了故障，備機房里面的兩個節(jié)點全部宕機，IDC 1 這里的master節(jié)點就成單點了。此時，如果開啟強同步，由于沒有備機應(yīng)答，主節(jié)點依然無辦法提供服務(wù)；但如果關(guān)閉強同步繼續(xù)提供服務(wù)，數(shù)據(jù)存在單點風險，如果這時主節(jié)點發(fā)生軟件硬件故障，數(shù)據(jù)就再也無法找回。一個比較好的方案是：給IDC1增加了一個跨機架的異步節(jié)點，當IDC2掛掉之后，這個異步節(jié)點會提升為強同步。這樣在只剩下一個機房的前提下，我們?nèi)匀荒軌虮ＷC一個跨機架的副本，降低主機的單點風險。

看完主城兩個機房，我們再看看異地災(zāi)備機房。作為異地災(zāi)備機房，一般是和主節(jié)點相隔500公里以上，延遲在10ms以上的機房。在這樣的網(wǎng)絡(luò)條件下，災(zāi)備節(jié)點和主城之間只能采用異步復(fù)制的方式同步數(shù)據(jù)，因而異地災(zāi)備節(jié)點承擔的更多是備份的職責，日常不會有太多正式業(yè)務(wù)訪問。雖然表面上看有點花瓶，沒有它卻也萬萬不行。假如有一天發(fā)生了城市級別故障，災(zāi)備實例仍可以為我們挽回99%以上的數(shù)據(jù)。正是由于災(zāi)備節(jié)點和主節(jié)點的這種異步弱關(guān)系，才允許我們的災(zāi)備實例在備城是一個獨立部署的單元。

異地災(zāi)備機房除了作為異步數(shù)據(jù)備份外，另外一個重要的職責是：當主城的一個機房故障，通過和主城另外一個正常的機房形成多數(shù)派，將故障機房踢掉進而完成主備切換。部署在異地的這個大腦，在大部分時間都不參與主城的事宜，只有在主城的一個機房發(fā)生故障時才介入。正常情況下，主城的模塊訪問主城的大腦，備城的模塊訪問備城的大腦，不會交叉訪問導(dǎo)致延遲過高的問題。

“兩中心”架構(gòu)

聊完“三中心”，我們再來聊聊“兩中心”架構(gòu)。具體來說，同城只有兩個機房，根據(jù)我們上一個PPT的經(jīng)驗，在兩機房部署TDSQL需要按照同機房異步，跨機房強同步的方式部署。因而采用四節(jié)點的模式，分布式在2個IDC。

然而“兩中心”架構(gòu)有個需要權(quán)衡的地方是，只有部署在備機房而且故障的不是備中心，才能實現(xiàn)自動跨IDC容災(zāi)。但如果是備中心故障，事實上，在同機房異步，跨機房強同步的方式下，不管是部署在主機房還是備機房，假如發(fā)生故障，無法順利完成多數(shù)派選舉以及自動故障切換，要么強同步節(jié)點無法被提升形成多數(shù)派，要么多數(shù)派隨機房故障而故障，需要人工介入。因而在高可用要求的場景下，一般更為推薦“兩地三中心”等7*24小時高可用部署架構(gòu)。

標準化高可用部署方案總結(jié)

最后我們總結(jié)一下今天的分享：

• 首先，對于跨城市容災(zāi)一般建議在異地搭建獨立的集群模式，通過異步復(fù)制實現(xiàn)同步。主城和備成可以采用不同的部署方式，如主城一主三備，備城一主一備的方式靈活自由組合。

• 現(xiàn)網(wǎng)運營的最佳方案是同城三中心加一個異地災(zāi)備中心，其次是金融行業(yè)標準的兩地三中心的架構(gòu)。這兩種架構(gòu)都能輕松實現(xiàn)數(shù)據(jù)中心異常自動切換。

• 如果只有兩個數(shù)據(jù)中心，做不到任意數(shù)據(jù)中心異常都能自動切換，需要一些權(quán)衡。

不光是對于數(shù)據(jù)庫系統(tǒng)，任何做一種高可用系統(tǒng)都需要做基于部署架構(gòu)方面的考量，這就是本次分享的全部，謝謝大家。

Q&A環(huán)節(jié)

Q：同城主備切換一次多長時間？

A：30秒以內(nèi)。

Q：兩地三中心的主城是不是設(shè)置成級聯(lián)？

A：這個問題非常好，如果從主城的視角看，這顯然是一個級聯(lián)關(guān)系，數(shù)據(jù)先由主城的master同步到主城的slave，再通過主城的slave同步到備城的master，一層層向下傳遞數(shù)據(jù)。

Q：請教一下強同步會等SQL回放嗎？

A：不會等，只要IO線程拉到數(shù)據(jù)即可。因為基于行格式的binlog是具備冪等寫的，我們通過大量的案例證明它是可靠的。此外，增加了apply反而會使得平均時耗的上升和吞吐量的下降。最后，假如apply有問題，TDSQL的監(jiān)控平臺會立刻識別并告警，提醒DBA確認處理。

Q：備機只存binlog不回放，性能上跟得上主嗎？

A：備機拉取binlog和回放binlog是兩組不同的線程，分別叫IO線程和SQL線程，并且兩組線程互不干擾。IO線程只負責到master上下載binlog，SQL線程只回放拉取到本地的binlog。上一個問題說的是強同步機制不等待回放，并不是說到備機的binlog不會被回放。

Q：同城三中心寫存儲節(jié)點都在IDC1，那么在IDC2的業(yè)務(wù)延遲是不是很大？

A：同城機房現(xiàn)在都是光纖傳輸，時耗基本都是做到1毫秒以下，完全沒必要擔心這種訪問時耗。當然，如果機房設(shè)施比較陳舊，或者相隔距離間的網(wǎng)絡(luò)鏈路極為不穩(wěn)定，為了追求卓越性能可能需要犧牲一部分容災(zāi)能力。

???

Q：一主兩備，SQL引擎做成故障切換有VIP方式嗎？

A：當然有，多個SQL引擎綁定負載均衡設(shè)備，業(yè)務(wù)通過VIP方式訪問TDSQL，當SQL引擎故障后負載均衡會自動將其踢掉。

Q：這樣不是三個業(yè)務(wù)各自寫一個庫嗎？

A：不是的，三個業(yè)務(wù)都寫到主庫。SQL引擎都會路由到主庫，一主兩備。TDSQL強調(diào)任何一個時刻只有一個主提供服務(wù)，備機只提供讀服務(wù)不提供寫服務(wù)。

Q：同城多副本，多SET對同城IDC之間網(wǎng)絡(luò)要求有什么？

A：5毫秒以內(nèi)的延遲。

Q：如果兩個強同步主從可以設(shè)置其中一個返回？

A：TDSQL強同步默認機制就是等待一臺強同步的備機應(yīng)答。

Q：中間一個節(jié)點掛了，異地節(jié)點會不會自動連接到主節(jié)點？

A：當然會。

Q：強同步和半同步復(fù)制相比的優(yōu)勢是什么？

A：強同步跟半同步復(fù)制相比，最直觀的理解可能有人會問，強同步不就是把半同步的超時時間改成無限嗎？其實不是這樣的，TDSQL強同步這里的關(guān)鍵不是在解決備機應(yīng)答的問題，而是要解決這種增加了等待備機的機制之后，如何能保證高性能、高可靠性。換句話說，如果在原生半同步的基礎(chǔ)上不改造性能，僅把超時時間改成無限大的時候，其實跑出來的性能和異步比甚至連異步的一半都達不到。這個在我們看來也是無法接受的。相當于為了數(shù)據(jù)的一致性犧牲了很大一部分性能。

TDSQL強同步復(fù)制的性能是在原生半同步的基礎(chǔ)上做了大量的優(yōu)化和改進，使得性能基本接近于異步，并且能實現(xiàn)數(shù)據(jù)零丟失——多副本，這是DSQL強同步的一個特點。上一期的直播我們介紹了，TDSQL如何實現(xiàn)高性能強同步的。比如經(jīng)過一系列的線程異步化，并且引入了線程池模型，并增加一個線程調(diào)度的優(yōu)化等。

Q：仲裁協(xié)議用的哪一個？

A：多數(shù)派選舉。

---

推薦閱讀：

騰訊分布式數(shù)據(jù)庫TDSQL金融級能力的架構(gòu)原理解讀

丁奇：深入解讀騰訊云國產(chǎn)數(shù)據(jù)庫技術(shù)演進歷程

總結(jié)

以上是生活随笔為你收集整理的腾讯数据库RTOlt;30s,RPO=0高可用方案首次全景揭秘的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。