天天看點

架構設計之「資料庫叢集方案」

架構設計之「資料庫叢集方案」

在之前的文章中,我們知道資料庫服務可能已經成為了很多系統的性能關鍵點,甚至是瓶頸了。也給大家介紹了資料庫伺服器從主備架構、到主從架構、再到主主架構的基礎方案。但如果單台機器已經不能滿足完整業務資料存儲的時候,我們就需要考慮采用多機甚至多中心的部署方案了。

今天我們就再來聊一聊,在多機環境下,資料庫叢集的架構方案。

同樣,這裡先不看細節,不管底層資料源是什麼資料庫,我們先談架構方案。因為無論底層是 Mysql 還是 Redis、MongoDB,我們在架構設計上都是相通的。

針對多機的架構,常見有如下做法:

  • 單中心資料叢集
  • 多中心資料分區

下面我們來具體看看:

一、單中心的資料叢集架構(單中心多機)

單資料中心多機器的叢集又可以分為:

  • 資料集中模式
  • 資料分散模式

這兩種的主要差別在于叢集中的完整業務資料是全部集中在一台機器上,但是分散在多台機器上。

如圖,

架構設計之「資料庫叢集方案」

這種模式與「一主一從式」(主從式)比較類似,完整的業務資料還是存儲在一台主機的上,主機承擔讀服務和寫服務,從機隻承擔讀服務。但是從機有多台機器,從機實時的從主機同步資料。是以這種模式,也可以了解為「一主多從」式。

因為有多個從機,那麼也給這種架構帶來了一些額外需要處理問題,比如:

1.1,主機需要實時的将資料同步到多台從機上,涉及到主機的處理壓力問題。

1.2,需要保障多台從機之間的資料一緻性的問題,如果出現資料不一緻,如何處理。

1.3,多台從機是如何檢測主機狀态的,因為從機在關鍵時刻是要替換主機的,那麼如果多台從機監測到的主機狀态不一緻,那又可能會帶來其它問題。

1.4,從機切換為主機的時候,選擇哪一台從機來切換呢,這涉及到多台從機之間如何進行選舉的問題。

這些問題,在我們進行架構設計的時候,必須提前考慮。不過市面上也有一些工具可以輔助實作,例如 ZooKeeper等。

另外,由于資料集中模式的所有寫操作都隻到一台主機上,而讀操作可以到N台從機上。是以這種模式比較适用于業務資料量不大、讀操作遠遠大于寫操作、叢集規模較小的業務場景。

架構設計之「資料庫叢集方案」

資料分散模式是指,完整的業務資料并非是全部存儲在一台主機上的,而是由多台主機共同分擔,分散存儲。是以這種模式适用于大資料量、叢集規模較大的場景。

使用這種模式,也有幾點需要特别注意的:

1.1,盡量将資料均衡的分散的各個機上,這樣才能保證資源的均衡使用和性能的最佳。

1.2,多台機器上的資料雖然不同,但是也需要互相進行資料的備份。

1.3,要能動态的增加和删除節點,這樣可以便于随時擴充,通常采用一緻性HASH的方法。

聊完了單資料中心的叢集架構,我們再來看看多資料中心的資料分區架構。

二、多中心的資料分區架構(多中心多機)

出于容災的考慮,通常會在多個不同地區部署多套的資料叢集。畢竟在國内營運商網絡故障、光纖被山東藍翔技工鏟斷等事件還是不少的。輕則一個機房出問題,重則一個城市一個省份都可能故障。

如果我們資料存儲服務隻部署在一個機房,那如果這個機房出現了故障,很有可能導緻不能服務甚至是無法恢複業務了。是以我們就需要考慮多中心的資料分區架構,将資料按照一定的規則進行分區,部署在不同機房/城市裡,且每一個分區都存儲一部分資料,通過這種方式來保障資料和服務的可用性。

在多中心的資料分區模式下,我們需要提前規劃 “分區規則” 。畢竟将資料在地理位置上分區,在網絡通訊方面是有時延的,是以必須要考慮好我們是要以區域、還是以城市、還是省份來分節點部署。

除了 “分區規則” ,我們還需要考慮 “備份規則” 。

因為分區之後,各區都隻存儲一部分資料,并不是完整資料。如果其中一個區出故障了,雖然不會影響全局,但是也會帶來一定損失。是以我們需要考慮将每個區裡的資料備份起來,備份有幾種方式:

  • 集中備份式
  • 獨立備份式
  • 互相備份式

下面将這三種備份方式解釋一下:

架構設計之「資料庫叢集方案」

集中備份式是指建立一個獨立的資料備份中心,将各分區(節點)的資料都定期同步到這個備份中心,以保障資料的安全性。這種備份方式可以随意的擴充分區(節點),不受分區的個數限制,并且結構很簡單。但是

這種備份方式的缺點就是,投入成本有點高,因為需要額外建立這麼一個備份資料中心,平時也是閑置的,有點浪費資源。另外,備份中心自身也可能會有單點的故障,且備份中心中需存儲多個分區的資料,還可能會互相受到影響。

架構設計之「資料庫叢集方案」

獨立備份式就是給每一個資料分區(節點)都建立一個額外的備份節點,這個備份節點部署在不同的地域/城市,這樣才能起到容災的作用。

這種備份方式相比較于 集中備份式 ,建設成本就更大一些了,畢竟每一個分區都需要額外建立一個備份節點。但是結構更清晰簡單了,而且各個分區的資料之間還可以做到互不影響,完全是獨立的。後續擴充分區(節點)的時候,對前面的備份節點也沒有影響,擴充性好。

這個暫時沒有找到合适的圖。

互相備份式其實是結合了上面兩種特性在一起的模式。上面的方式不是成本大麼,那麼這種方式就不額外建立備份中心了,讓各個分區(節點)互相備份資料。比如 分區A 将自身資料同步一份給 分區B備份着,分區B 将自己的資料同步一份給 分區A 備份着,如果是三個以上分區,還可以做到循環備份。

這種備份方式,設計稍微複雜一些,擴充性也弱一些,但是可以節約資源。

無論采用哪種方式,都需要結合實際的業務場景來決定。

以上,就是對資料庫在多機叢集模式下的技術架構的分享,歡迎大家一起交流。

原文釋出時間為:2018-10-11

本文作者:奎哥

本文來自雲栖社群合作夥伴“雲時代架構”,了解相關資訊可以關注“雲時代架構”。