RocketMQ4.2 最佳實踐之集羣搭建

學習了RocketMQ的基本概念後，咱們來看看RocketMQ最簡單的使用場景。RocketMQ的服務器最簡單的結構，必須包含一個NameServer和一個Broker。Producer把某個主題的消息發送給Broker，Consumer會去Broker中監聽指定主題的消息，一旦發現，就會拉取並消費。在這個過程當中，Producer和Consumer是經過NameServer才知道Broker部署在哪裏，若是是 Broker Cluster 的狀況，還要知道Master節點是哪些。換句話說，NameServer中保存着 Broker 的路由信息。

 

以上這些理解是對 RocketMQ 最淺顯直觀的理解。而後咱們來試想一下，若是 NameServer 和 Broker 都是單節點的，那麼一旦出現問題，首先是服務不可用了，其次，Producer和Consumer必然不知道Broker在哪裏，消息就會發不出去也監聽不到。Broker中還沒有被消費的消息必然在故障期間不可訂閱，影響消息實時性。爲了不這種狀況的發生，咱們須要搭建NameServer集羣和 Broker 集羣。

 

本文主要講解【MQ集羣】和【Broker Set】的搭建方法，其中也涉及到了名詞解釋和各組件做用的簡單介紹。【MQ集羣】和【Broker Set】的搭建，主要是爲了最大程度上保證消息不丟失，從而作到 RocketMQ 的高可用。

 

1. 集羣物理部署結構

以多Master多Slave模式爲例，看一下RocketMQ集羣物理部署結構，而後咱們解釋一下基本概念：

 

=== NameServer Cluster ===

NameServer是一個幾乎無狀態節點，可集羣部署，節點之間無任何信息同步，只要保證一個實例存活就能夠正常提供Broker的路由信息。如上圖所示。

 

=== Broker Cluster ===

Broker分爲Master和Slave，一個Master能夠對應多個Slave，可是一個Slave只能對應一個Master。Master與Slave的對應關係經過指定相同的BrokerName，不一樣的BrokerId來定義，BrokerId爲0表示Master，非0表示Slave。由於這些 Master 和 Slave 具備相同的 BrokerName，所以它們組成了一個 Broker Set。

Master Broker 也能夠部署多個。每一個Broker或者 Broker Set 與NameServer集羣中的全部節點創建長鏈接，定時註冊 Topic 信息到全部 NameServer。

 

=== Producer Cluster ===

Producer與NameServer集羣中的其中一個節點（隨機選擇）創建長鏈接，按期從NameServer取Topic路由信息，並和提供Topic服務的Master創建長鏈接，且定時向Master發送心跳。Producer徹底無狀態，可集羣部署。

 

=== Consumer Cluster ===

Consumer與NameServer集羣中的其中一個節點（隨機選擇）創建長鏈接，按期從NameServer取Topic路由信息，並和提供Topic服務的Master、Slave創建長鏈接，且定時向Master、Slave發送心跳。Consumer既能夠從Master訂閱消息，也能夠從Slave訂閱消息，訂閱規則由Broker配置決定。

 

2. 消息落盤和Broker數據同步

搭建 RocketMQ 集羣的目的，是爲了在最大程度上保證消息不丟失。下面咱們來看看集羣中有哪些特性，能夠保障消息不丟失。

 

2.1 消息落盤

RocketMQ能夠將內存中的數據存儲在磁盤中，這種操做叫作磁盤刷新（Disk Flush）。

RocketMQ提供瞭如下兩種模式：

• SYNC_FLUSH（同步刷盤）：生產者發送的每一條消息，都在保存到磁盤成功後纔回調告訴生產者成功。這種方式不會存在消息丟失的問題，可是有很大的磁盤IO開銷，性能有必定影響
• ASYNC_FLUSH（異步刷盤）：生產者發送的每一條消息並非當即保存到磁盤，而是暫時緩存起來，而後就回調告訴生產者成功。隨後再異步的將緩存數據保存到磁盤

 

若是咱們選擇異步刷盤，可選的有兩種刷盤機制：

1. 按期將緩存中更新的數據進行落盤
2. 當緩存中更新的數據條數達到某一設定值後進行落盤。這種方式會存在消息丟失（在還將來得及同步到磁盤的時候宕機），可是性能很好。默認是這種模式。

 

2.2 Broker數據同步機制

Broker Replication（Broker 間數據同步/複製）：

Broker Replication 指的就是在一個Broker Set 中，Slave Broker 獲取/複製 Master Broker 數據的過程。這裏再提一下 Broker Set 的概念。

 

Broker Set 中的Broker，有兩種角色：

• 一種是master，便可以寫也能夠讀，其brokerId=0，只能有一個
• 一種是slave，只容許讀，其brokerId爲非0

一個master與多個slave經過指定相同的BrokerName被歸爲一個 broker set（broker集）。一般生產環境中，咱們至少須要2個broker set。

 

生產者發送的消息，老是先發到 Master Broker。對於消息發送成功的回調，Broker Set 有兩種數據同步機制：

• Sync Broker（同步雙寫）：生產者發送的每一條消息都至少同步複製到一個slave後，才返回告訴生產者成功，即「同步雙寫」
• Async Broker（異步複製）：生產者發送的每一條消息只要寫入master，就返回告訴生產者成功。而後再「異步複製」到slave

 

幾種Broker集羣搭建的最佳實踐：

2M + NoSlave：兩主（只有兩個master，沒有slave）

2M + 2S + Async：兩主兩從異步複製（兩個master，兩個slave，master數據經過異步複製到slave）

2M + 2S + Sync：兩主兩從同步雙寫（兩個master，兩個slave，數據同步雙寫到master和slave）

 

說明：

1. 上述「2」只是說做爲一個集羣的最低配置數量，能夠根據實際狀況擴展
2. 全部的刷盤操做所有默認爲：ASYNC_FLUSH（異步刷盤）

 

3. 三種Broker集羣方式優缺點

多Master模式（2M + NoSlave）

一個集羣無Slave，全是Master，例如2個Master或者3個Master。

Master之間有負載均衡，Producer發出的消息會平均地落在Master機器上。可是對於一條消息，只會落在一臺Master上。

優勢：配置簡單，單個Master宕機或重啓維護時，對應用無影響。當磁盤配置爲RAID10時，即便機器宕機不可恢復狀況下，因爲RAID10磁盤很是可靠，消息也不會丟（異步刷盤狀況丟失少許消息，同步刷盤狀況一條不丟）。性能最高。

缺點：單臺機器宕機期間，這臺機器上未被消費的消息在機器恢復以前不可訂閱，消息實時性會受到影響。

 

多Master多Slave模式，異步複製（2M + 2S + Async）

每一個Master配置一個Slave，有多對Master-Slave，HA採用異步複製方式，主備有短暫消息延遲，毫秒級。

優勢：即便磁盤損壞，消息丟失的很是少，且消息實時性不會受影響，由於Master宕機後，消費者仍然能夠從Slave消費，此過程對應用透明。另外，不須要人工干預。性能同多Master模式幾乎同樣。

缺點：Master宕機，磁盤損壞狀況，會丟失少許消息。

 

多Master多Slave模式，同步雙寫（2M + 2S + Sync）

每一個Master配置一個Slave，有多對Master-Slave，HA採用同步雙寫方式，主備都寫成功，嚮應用返回成功。

優勢：數據與服務都無單點，Master宕機狀況下，消息無延遲，服務可用性與數據可用性都很是高。

缺點：性能比異步複製模式略低，大約低10%左右，發送單個消息的響應時間會略久。

 

4. 雙主集羣搭建

這裏就以雙主集羣爲例，進行搭建。

本小節是實際操做的Shell腳本和配置方法，這篇筆記省略。能夠閱讀參考資料來查看。

 

5. 雙主雙從集羣搭建

前文已經搭建過雙主結構的MQ集羣，這種集羣能知足咱們平常的須要，可是有時候咱們會遇到這樣的場景，咱們會要求消息實時返回，那麼雙主結構的可否知足咱們的需求呢？

 

答案是，極端狀況下消息作不到實時。試想有一臺Master忽然宕機或者網絡很差而斷開，而恰巧，宕機的Master節點中還有消息沒有被消費，那麼這個消息將不會被消費者得到，只有等宕機的Master節點從新啓動，存在於該節點的消息纔會被消費。在這段時間內，那些消息是不可訂閱的，影響了實時性。

 

要想解決上面的問題，咱們能夠搭建雙主雙從的集羣。讓咱們回顧一下，雙主雙從的數據同步機制，通常有兩種：

• Sync Broker（同步雙寫）：當生產端生產消息後，主節點和從節點都收到消息，並把消息都同時寫入到本地後，纔會回覆消息
• Async Broker（異步複製）：當主節點將數據保存到本地後，直接返回成功的消息，不關係從節點是否寫入成功

 

咱們能夠看出，異步複製效率比較高，而同步雙寫更具備高可用性，數據也變得更加可靠。

 

下面咱們搭建雙主雙從集羣，並採用異步複製的方式。具體的搭建方式，請自行網上查找資料。再來看一下搭建完成後的結構圖：

 

搭建完成後，對集羣進行測試，仍是以上圖爲例，能夠看到下面的狀況：

• 消息發送時已經進行了負載均衡，消息比較平均地落在了兩個 Broker Set 上
• 在Broker運行時關掉 Broker Master1，Broker Master1 上尚未被消費的數據，會走 Broker Slave1被消費。消費完了再把 Broker Master1 啓動，Master1 上沒有被消費的數據不會被消費
• 在Broker運行時關掉 Broker Master1，以後的消息會被髮到 Broker Master2 上
• 當Master1被加回來，Master1會從新成爲主節點，而且與 Master2 仍是有負載均衡效果
• Slave1 在 Master1 宕機期間，不會升級成爲主節點

 

6. 參考資料

https://www.jianshu.com/p/616474a5c4a7

 

 

創做時間：2019-06-14 16:17