[[431011]]

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

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

首先讓我們來看在單個站點上的數(shù)據(jù)庫部署類型：

單節(jié)點

單個站點上的單節(jié)點部署

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

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

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

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

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

多節(jié)點

我們再來看單個站點上的多節(jié)點架構(gòu)。顯然，在技術(shù)實現(xiàn)上，它會對DR和HA有所改進。在此類部署中，我們一般可以選用主-被模式、或多主模式，并配置出2個或更多的節(jié)點。而且，這些節(jié)點通常可以分布在不同的故障域中，例如：某個機架、某組網(wǎng)絡(luò)交換機或磁盤。

主-被模式

主-被

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

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

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

主-被模式的缺點是：

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

多主模式

單個站點上的多活模式

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

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

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

多主模式的缺點是：

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

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

多個站點上的多活模式

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

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

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

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

小結(jié)

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

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

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