Galera Cluster—MySQL新型的高並發集群架構

一丶 何謂Galera Cluster

何謂Galera Cluster？就是集成了Galera插件的MySQL集群，是一種新型的，數據不共享的，高度冗餘的高可用方案，目前Galera Cluster有兩個版本，分別是Percona Xtradb Cluster及MariaDB Cluster，都是基於Galera的，所以這裡都統稱為Galera Cluster了，因為Galera本身是具有多主特性的，所以Galera Cluster也就是multi-master的集群架構，如圖1所示：

Galera Cluster架構

上圖中有三個實例，組成了一個集群，而這三個節點與普通的主從架構不同，它們都可以作為主節點，三個節點是對等的，這種一般稱為multi-master架構，當有客戶端要寫入或者讀取數據時，隨便連接哪個實例都是一樣的，讀到的數據是相同的，寫入某一個節點之後，集群自己會將新數據同步到其它節點上面，這種架構不共享任何數據，是一種高冗餘架構。

一般的使用方法是，在這個集群上面，再搭建一個中間層，這個中間層的功能包括建立連接、管理連接池，負責使三個實例的負載基本平衡，負責在客戶端與實例的連接斷開之後重連，也可以負責讀寫分離（在機器性能不同的情況下可以做這樣的優化）等等，使用這個中間層之後，由於這三個實例的架構在客戶端方面是透明的，客戶端只需要指定這個集群的數據源地址，連接到中間層即可，中間層會負責客戶端與伺服器實例連接的傳遞工作，由於這個架構支持多點寫入，所以完全避免了主從複製經常出現的數據不一致的問題，從而可以做到主從讀寫切換的高度優雅，在不影響用戶的情況下，離線維護等工作，MySQL的高可用，從此開始，非常完美。

二丶為什麼需要Galera Cluster

MySQL在互聯網時代，可謂是深受世人矚目的。給社會創造了無限價值，隨之而來的是，在MySQL基礎之上，產生了形形色色的使用方法、架構及周邊產品。本文所關注的是架構，在這方面，已經有很多成熟的被人熟知的產品，比如MHA、MMM等傳統組織架構，而這些架構是每個需要資料庫高可用服務方案的入門必備選型。

不幸的是，傳統架構的使用，一直被人們所詬病，因為MySQL的主從模式，天生的不能完全保證數據一致，很多大公司會花很大人力物力去解決這個問題，而效果卻一般，可以說，只能是通過犧牲性能，來獲得數據一致性，但也只是在降低數據不一致性的可能性而已。所以現在就急需一種新型架構，從根本上解決這樣的問題，天生的擺脫掉主從複製模式這樣的「美中不足」之處了。

幸運的是，MySQL的福音來了，Galera Cluster就是我們需要的——從此變得完美的架構。

相比傳統的主從複製架構，Galera Cluster解決的最核心問題是，在三個實例（節點）之間，它們的關係是對等的，multi-master架構的，在多節點同時寫入的時候，能夠保證整個集群數據的一致性，完整性與正確性。

三丶 Galera Cluster如何解決問題

Galera的引入

現在已經知道，Galera Cluster是MySQL封裝了具有高一致性，支持多點寫入的同步通信模塊Galera而做的，它是建立在MySQL同步基礎之上的，使用Galera Cluster時，應用程序可以直接讀、寫某個節點的最新數據，並且可以在不影響應用程序讀寫的情況下，下線某個節點，因為支持多點寫入，使得Failover變得非常簡單。

所有的Galera Cluster，都是對Galera所提供的介面API做了封裝，這些API為上層提供了豐富的狀態信息及回調函數，通過這些回調函數，做到了真正的多主集群，多點寫入及同步複製，這些API被稱作是Write-Set Replication API，簡稱為wsrep API。

通過這些API，Galera Cluster提供了基於驗證的複製，是一種樂觀的同步複製機制，一個將要被複制的事務（稱為寫集），不僅包括被修改的資料庫行，還包括了這個事務產生的所有Binlog，每一個節點在複製事務時，都會拿這些寫集與正在APPLY隊列的寫集做比對，如果沒有衝突的話，這個事務就可以繼續提交，或者是APPLY，這個時候，這個事務就被認為是提交了，然後在資料庫層面，還需要繼續做事務上的提交操作。

這種方式的複製，也被稱為是虛擬同步複製，實際上是一種邏輯上的同步，因為每個節點的寫入和提交操作還是獨立的，更準確的說是非同步的，Galera Cluster是建立在一種樂觀複製的基礎上的，假設集群中的每個節點都是同步的，那麼加上在寫入時，都會做驗證，那麼理論上是不會出現不一致的，當然也不能這麼樂觀，如果出現不一致了，比如主庫（相對）插入成功，而從庫則出現主鍵衝突，那說明此時資料庫已經不一致，這種時候Galera Cluster採取的方式是將出現不一致數據的節點踢出集群，其實是自己shutdown了。

而通過使用Galera，它在裡面通過判斷鍵值的衝突方式實現了真正意義上的multi-master，Galera Cluster在MySQL生態中，在高可用方面實現了非常重要的提升，目前Galera Cluster具備的功能包括如下幾個方面：

1. 多主架構：真正的多點讀寫的集群，在任何時候讀寫數據，都是最新的。

2. 同步複製：集群不同節點之間數據同步，沒有延遲，在資料庫掛掉之後，數據不會丟失。

3. 並發複製：從節點在APPLY數據時，支持並行執行，有更好的性能表現。

4. 故障切換：在出現資料庫故障時，因為支持多點寫入，切的非常容易。

5. 熱插拔：在服務期間，如果資料庫掛了，只要監控程序發現的夠快，不可服務時間就會非常少。在節點故障期間，節點本身對集群的影響非常小。

6. 自動節點克隆：在新增節點，或者停機維護時，增量數據或者基礎數據不需要人工手動備份提供，Galera Cluster會自動拉取在線節點數據，最終集群會變為一致。

7. 對應用透明：集群的維護，對應用程序是透明的，幾乎感覺不到。 以上幾點，足以說明Galera Cluster是一個既穩健，又在數據一致性、完整性及高性能方面有出色表現的高可用解決方案。

Galera Cluster的並發控制

Galera Cluster可以實現集群中，數據的高度一致性，並且在每個節點上，生成的Binlog順序都是一樣的，這與Galera內部，實現的並發控制機制是分不開的。所有的上層到下層的同步、複製、執行、提交都是通過並發控制機制來管理的。這樣才能保證上層的邏輯性，下層數據的完整性等。

galera原理圖

從圖中可以大概看出，從事務執行開始，到本地執行，再到寫集發送，再到寫集驗證，再到寫集提交的整個過程，以及從節點（相對）收到寫集之後，所做的寫集驗證、寫集APPLY及寫集提交操作，通過對比這個圖，可以很好的理解每一個階段的意義及性能等。

四丶 流量控制

在PXC中，有一個參數叫fc_limit，它的全名其實是叫flow control limit，顧名思義，是流量控制大小限制的意思，它的作用是什麼呢？

如果一套集群中，某個節點，或者某幾個節點的硬體資源比較差，或者由於節點壓力大，導致複製效率低下，等等各種原因，導致的結果是，從節點APPLY時，非常慢，也就是說，主庫在一秒鐘之內做的操作，從庫有可能會用2秒才能完成，那麼這種情況下，就會導致從節點執行任務的堆積，接收隊列的堆積。

假設從節點真的堆積了，那麼Galera會讓它一直堆積下去么？這樣延遲會越來越嚴重，這樣Galera Cluster就變成一個主從架構的集群了，已經失去了強一致狀態的屬性了，那麼很明顯，Galera是不會讓這種事情發生的，那麼此時，就說回到開頭提到的參數了，gcs.fc_limit，這個參數是在MySQL參數wsrep_provider_options中來配置的，這個參數是Galera的一個參數集合，有關於Flow Control的，還包括gcs.fc_factor，這兩個參數的意義是，當從節點堆積的事務數量超過gcs.fc_limit的值時，從節點就發起一個Flow Control，而當從節點堆積的事務數小於gcs.fc_limit * gcs.fc_factor時，發起Flow Control的從節點再發起一個解除的消息，讓整個集群再恢復。

但我們一般所關心的，就是如何解決，下面有幾個一般所採用的方法：

1. 發送FC消息的節點，硬體有可能出現問題了，比如IO寫不進去，很慢，CPU異常高等

2. 發送FC消息的節點，本身資料庫壓力太高，比如當前節點承載太多的讀，導致機器Load高，IO壓力大等等。

3. 發送FC消息的節點，硬體壓力都沒有太大問題，但做得比較慢，一般原因是主庫並發高，但從節點的並發跟不上主庫，那麼此時可能需要觀察這兩個節點的並發度大小，可以參考狀態參數wsrep_cert_deps_distance的值，來調整從節點的wsrep_slave_threads，此時應該是可以解決或者緩解的，這個問題可以這樣去理解，假設集群每個節點的硬體資源都是相當的，那麼主庫可以執行完，從庫為什麼做不過來？那麼一般思路就是像處理主從複製的延遲問題一樣。

4. 檢查存不存在沒有主鍵的表，因為Galera的複製是行模式的，所以如果存在這樣的表時，主節點是通過語句來修改的，比如一個更新語句，更新了全表，而從節點收到之後，就會針對每一行的Binlog做一次全表掃描，這樣導致這個事務在從節點執行，比在主節點執行慢十倍，或者百倍，從而導致從節點堆積進而產生FC。

五丶適用場景

現在對Galera Cluster已經有了足夠了解，但這樣的「完美」架構，在什麼場景下才可以使用呢？或者說，哪種場景又不適合使用這樣的架構呢？針對它的缺點，及優點，我們可以揚其長，避其短。可以通過下面幾個方面，來了解其適用場景。

1. 數據強一致性：因為Galera Cluster，可以保證數據強一致性的，所以它更適合應用於對數據一致性和完整性要求特別高的場景，比如交易，正是因為這個特性，我們去哪兒網才會成為使用Galera Cluster的第一大戶。

2. 多點寫入：這裡要強調多點寫入的意思，不是要支持以多點寫入的方式提供服務，更重要的是，因為有了多點寫入，才會使得在DBA正常維護資料庫集群的時候，才會不影響到業務，做到真正的無感知，因為只要是主從複製，就不能出現多點寫入，從而導致了在切換時，必然要將老節點的連接斷掉，然後齊刷刷的切到新節點，這是沒辦法避免的，而支持了多點寫入，在切換時刻允許有短暫的多點寫入，從而不會影響老的連接，只需要將新連接都路由到新節點即可。這個特性，對於交易型的業務而言，也是非常渴求的。

3. 性能：Galera Cluster，能支持到強一致性，毫無疑問，也是以犧牲性能為代價，爭取了數據一致性，但要問：」性能犧牲了，會不會導致性能太差，這樣的架構根本不能滿足需求呢？」這裡只想說的是，這是一個權衡過程，有多少業務，QPS大到Galera Cluster不能滿足的？我想是不多的（當然也是有的，可以自行做一些測試），在追求非常高的極致性能情況下，也許單個的Galera Cluster集群是不能滿足需求的，但畢竟是少數了，所以夠用就好，Galera Cluster必然是MySQL方案中的佼佼者。

總結

到這裡，Galera Cluster—MySQL新型的高並發集群架構就結束了，，不足之處還望大家多多包涵！！覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持。（吹一波，233~~）

下面和大家交流幾點編程的經驗：

1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的

2丶 測試、測試再測試，如果你不徹底測試自己的代碼，那恐怕你開發的就不只是代碼，可能還會聲名狼藉。

3丶 簡化演算法，代碼如惡魔，在你完成編碼後，應回頭並且優化它。從長遠來看，這裡或那裡一些的改進，會讓後來的支持人員更加輕鬆。

4、可以去騰訊課堂的圖靈學院學習一下java架構實戰案例，還挺不錯的。

最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步。

內部交流群469717771 歡迎各位前來交流和分享， 驗證：（009）必過！！

你的讚賞是我堅持原創的動力