[[431011]]

【51CTO.com快譯】如今，在各種類型的應(yīng)用項(xiàng)目中，業(yè)務(wù)規(guī)則日趨復(fù)雜，數(shù)據(jù)體量也日益增多。這些都給應(yīng)用后端的數(shù)據(jù)庫(kù)帶來(lái)了不小的壓力。而隨著應(yīng)用程序持續(xù)被越來(lái)越多的用戶所使用，您會(huì)逐漸發(fā)現(xiàn)，數(shù)據(jù)庫(kù)層已經(jīng)成為了整個(gè)系統(tǒng)的關(guān)鍵節(jié)點(diǎn)和性能瓶頸。因此，實(shí)現(xiàn)數(shù)據(jù)層的高可用性，就成為了我們?cè)陧?xiàng)目設(shè)計(jì)與運(yùn)維過程中，經(jīng)常要考慮和解決的問題。

下面，我將以單個(gè)站點(diǎn)和多個(gè)站點(diǎn)的，主-備和多主模式為例，和您討論數(shù)據(jù)庫(kù)的各種部署類型，它們各自的特點(diǎn)和在功效上的利弊，以便您能夠設(shè)計(jì)出具有高可用性和業(yè)務(wù)彈性的數(shù)據(jù)庫(kù)架構(gòu)。

首先讓我們來(lái)看在單個(gè)站點(diǎn)上的數(shù)據(jù)庫(kù)部署類型：

單節(jié)點(diǎn)

單個(gè)站點(diǎn)上的單節(jié)點(diǎn)部署

最基本的部署方式當(dāng)屬單個(gè)站點(diǎn)上的單節(jié)點(diǎn)架構(gòu)。在業(yè)務(wù)連續(xù)性方面，這顯然是最不具備優(yōu)勢(shì)的部署模式。由于無(wú)法提供高可用性，其唯一的DR(災(zāi)難恢復(fù))機(jī)制只能通過現(xiàn)有的備份文件，去恢復(fù)數(shù)據(jù)庫(kù)?？梢?，這種類型的部署，通常出現(xiàn)在不太重要的環(huán)境中。例如，在CI/CD管道的技術(shù)中，自動(dòng)化測(cè)試已經(jīng)成為了該過程的一部分，那么在開發(fā)或使用過程中，我們就可以將諸如：CockroachDB、Oracle、以及SQL Server等幾乎所有數(shù)據(jù)庫(kù)，都按照這種方式進(jìn)行部署。

單節(jié)點(diǎn)部署模式的好處是：

• 由于只有一個(gè)節(jié)點(diǎn)需要獲得數(shù)據(jù)庫(kù)的許可證，因此它具有一定的成本效益。但是，如果在真實(shí)的生產(chǎn)中采用此模式，那么由于業(yè)務(wù)中斷所帶來(lái)的損失，以及引發(fā)的補(bǔ)救成本，則可能是一個(gè)天文數(shù)字。

單節(jié)點(diǎn)部署模式的缺點(diǎn)是：

• 缺乏HA(高可用性)。如果唯一的節(jié)點(diǎn)出現(xiàn)錯(cuò)誤或問題，則無(wú)法實(shí)現(xiàn)故障的轉(zhuǎn)移。因此，您必須手動(dòng)修復(fù)現(xiàn)有的失敗節(jié)點(diǎn)，然后再?gòu)膫浞葜羞M(jìn)行數(shù)據(jù)恢復(fù)。
• 任何可能導(dǎo)致停機(jī)的維護(hù)，都必須事先考慮到如何轉(zhuǎn)移數(shù)據(jù)流的傳輸;而任何對(duì)于系統(tǒng)的修補(bǔ)或升級(jí)，也都會(huì)以某種形式給客戶或服務(wù)造成影響。

多節(jié)點(diǎn)

我們?cè)賮?lái)看單個(gè)站點(diǎn)上的多節(jié)點(diǎn)架構(gòu)。顯然，在技術(shù)實(shí)現(xiàn)上，它會(huì)對(duì)DR和HA有所改進(jìn)。在此類部署中，我們一般可以選用主-被模式、或多主模式，并配置出2個(gè)或更多的節(jié)點(diǎn)。而且，這些節(jié)點(diǎn)通?？梢苑植荚诓煌墓收嫌蛑校纾耗硞€(gè)機(jī)架、某組網(wǎng)絡(luò)交換機(jī)或磁盤。

主-被模式

主-被

這種模式通常是由一個(gè)主節(jié)點(diǎn)和n個(gè)被節(jié)點(diǎn)組成。這意味著，如果主節(jié)點(diǎn)出現(xiàn)了問題，應(yīng)用程序可以立即指向被節(jié)點(diǎn)，并將被節(jié)點(diǎn)提升為主節(jié)點(diǎn)。該過程往往是自動(dòng)完成的。不過，由于應(yīng)用程序在重新指向新的節(jié)點(diǎn)時(shí)需要切換時(shí)間，因此服務(wù)有可能會(huì)出現(xiàn)中斷。可見，該模式雖然優(yōu)于單節(jié)點(diǎn)的架構(gòu)，但是仍非生產(chǎn)環(huán)境的完美部署方案?？梢员慌渲弥?被模式的數(shù)據(jù)庫(kù)包括：Oracle、SQL Server、MySQL、以及Postgres。

主-被模式的優(yōu)點(diǎn)是：

• 在您簽署了主數(shù)據(jù)庫(kù)支持協(xié)議后，某些數(shù)據(jù)庫(kù)提供商會(huì)允許您免費(fèi)地將其運(yùn)行在被節(jié)點(diǎn)上，因此該模式仍然具有一定的成本效益。
• 相比單節(jié)點(diǎn)架構(gòu)，該模式提供了更好的HA能力。

主-被模式的缺點(diǎn)是：

• 既然增加了被節(jié)點(diǎn)，那么它必然需要跑在相應(yīng)的硬件、或虛擬資源上，那么您將不得不為此支付額外的費(fèi)用。而且，它們只會(huì)在發(fā)生災(zāi)難或故障時(shí)，才會(huì)被用到。
• 由于在發(fā)生故障時(shí)，所有服務(wù)器都需要重新同步，才能統(tǒng)一為主-被配置，因此其運(yùn)維的成本較高。

多主模式

單個(gè)站點(diǎn)上的多活模式

在這個(gè)模式中，集群中的所有節(jié)點(diǎn)，都可以同時(shí)進(jìn)行讀寫操作。由于在多個(gè)活動(dòng)的集群中，所有節(jié)點(diǎn)都是平等的，因此它們沒有了所謂主節(jié)點(diǎn)和被節(jié)點(diǎn)的概念。據(jù)此，您不但擁有可控的HA和DR功能，而且還具有可以輕松擴(kuò)展的固有能力。目前，可以被部署為此類模式的數(shù)據(jù)庫(kù)包括：CockroachDB、Cassandra以及Couchbase。

多主模式的優(yōu)點(diǎn)是：

• 無(wú)論是讀取還是寫入操作，都具有可擴(kuò)展性。
• 其高可用性體現(xiàn)在系統(tǒng)執(zhí)行升級(jí)和修補(bǔ)等維護(hù)任務(wù)時(shí)，不會(huì)產(chǎn)生任何停機(jī)。
• 由于所有節(jié)點(diǎn)一直都處于活躍且被使用的狀態(tài)，因此它們?cè)谫Y源利用率方面具有較高的成本效益。雖然由此會(huì)產(chǎn)生更高的預(yù)購(gòu)許可證的相關(guān)成本，但是該方案在市場(chǎng)上最具有成本效益。
• 可以達(dá)到RPO(恢復(fù)數(shù)據(jù)點(diǎn)目標(biāo))為 0，而RTO(恢復(fù)時(shí)間目標(biāo))<10秒。

多主模式的缺點(diǎn)是：

• 由于會(huì)導(dǎo)致網(wǎng)絡(luò)流量的翻倍增加，因此該解決方案往往會(huì)影響到系統(tǒng)的整體性能。不過，這對(duì)于單個(gè)站點(diǎn)而言影響甚微，畢竟其網(wǎng)絡(luò)速度非常快，帶寬也很大。
• 諸如Cassandra之類的技術(shù)往往需要定期的維護(hù)工作。也就是說(shuō)，在完成了恢復(fù)操作之后，應(yīng)復(fù)查并確保所有節(jié)點(diǎn)上的數(shù)據(jù)，被已完成復(fù)制、且保持一致。

總體而言，在單個(gè)站點(diǎn)上進(jìn)行數(shù)據(jù)庫(kù)部署的總體缺點(diǎn)在于，它無(wú)法應(yīng)對(duì)整個(gè)站點(diǎn)或區(qū)域的中斷情況。對(duì)此，我們往往需要用到下面將要討論到的多個(gè)站點(diǎn)部署的模式。

多個(gè)站點(diǎn)上的多活模式

多站點(diǎn)模式主要體現(xiàn)在不同的節(jié)點(diǎn)分布在不同的站點(diǎn)或區(qū)域中。如果我們需要通過在線狀態(tài)監(jiān)測(cè)的方式，及時(shí)發(fā)現(xiàn)掉線的站點(diǎn)或區(qū)域，那么該部署模式則非常適合。也就是說(shuō)，與單個(gè)站點(diǎn)的部署相比，多個(gè)站點(diǎn)部署的最大優(yōu)勢(shì)在于，您可以在某個(gè)或某幾個(gè)區(qū)域性數(shù)據(jù)中心、或站點(diǎn)出現(xiàn)中斷時(shí)，仍然可以提供原有的數(shù)據(jù)服務(wù)。

如前所述，在單個(gè)站點(diǎn)中，多主與主-被模式有著許多相似的優(yōu)缺點(diǎn)。但是，對(duì)于多個(gè)站點(diǎn)而言，我們應(yīng)當(dāng)更多地考慮以下兩個(gè)方面：

• 網(wǎng)絡(luò)延遲 - 由于各個(gè)站點(diǎn)通常是通過在地理上分散性，來(lái)提高服務(wù)的魯棒性，因此，由此帶來(lái)的網(wǎng)絡(luò)延遲，往往會(huì)影響到應(yīng)用程序的響應(yīng)時(shí)間。不過，諸如CockroachDB之類的數(shù)據(jù)庫(kù)會(huì)允許您使用其地理分區(qū)(Geo-Partitioning)的功能，來(lái)管控部分延遲的現(xiàn)象。您可以通過閱讀鏈接--https://www.cockroachlabs.com/docs/v19.1/demo-geo-partitioning，來(lái)了解更多相關(guān)內(nèi)容。當(dāng)然，您也必須為保持區(qū)域性數(shù)據(jù)中心的魯棒性，而承擔(dān)相應(yīng)的貨幣成本。
• DR — 您必須為集群內(nèi)的所有節(jié)點(diǎn)實(shí)施備份，而不僅僅只是為了單個(gè)節(jié)點(diǎn)的主-被方案。

當(dāng)然，您可以根據(jù)應(yīng)用的實(shí)際需求，選用其他更為可靠的解決方案。

小結(jié)

正如我們?cè)谏鲜雒恳环N部署方案的優(yōu)缺點(diǎn)中所介紹的那樣，無(wú)論您選擇的哪一種解決方案，都需要考慮和滿足應(yīng)用業(yè)務(wù)的連續(xù)性(如HA和DR)、總體擁有成本(完整的TCO，不僅包括前期的構(gòu)建支出，還包含了運(yùn)維與中斷所產(chǎn)生的成本)、以及性能上的綜合需求。

原文標(biāo)題：Active-Passive vs Multi-Active Database Topologies，作者：Daniel Holt

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】