RocketMQ的高可用集群部署
標簽（空格分隔）： 消息隊列 部署
1. RocketMQ 集群物理部署結構
Rocket物理部署結構
Name Server: 單點,供Producer和Consumer獲取Broker地址, 類似於注冊中心.
Producer: 產生並發送消息.
Consumer: 接收並消費消息.
Broker: 消息暫存,消息轉發.
1.1 Name Server
Name Server做的是Rocket的尋址服務, 用於將Broker的路由信息做聚合. 客戶端依靠Name Server決定去獲取對應topic的路由信息,從而決定對那些Broker做鏈接.
Name Server是一個幾乎無狀態的節點,Name Server之間采用Share-Nothing的設計, 互不通信.
對於一個
Name Server集群列表, 客戶端鏈接Name Server的時候會隨機選擇一個節點, 以做到負載均衡.
Name Server所有狀態都從Broker上報上來, 本身不存儲任何狀態, 所有數據均在內存.
如果中途所有的Name Server都掛了, 只會影響到路由信息的更新, 並不會影響到和
Broker的通信.(Eureka 的本地緩存服務注冊信息 )
1.2 Broker
Broker是做消息存儲,轉發的服務器.
Broker以group分開,每個group只允許一個master,若干個slave.
一個master可以有多個slave,但是一個slave只能有一個master.
只有master才可以進行寫入操作,slave不允許.
slave從master中同步數據. 同步策略取決於master的配置, 可以采用同步雙寫,異步復制兩種.
客戶端消費可以從master和slave中消費. 在默認的情況下,消費者都從master消費, 在master掛掉之后, 客戶端由於從Name Server中感知到Broker掛機,就會從slave消費. (盡量從master消費, 這樣消息會比較及時, 不用牽扯到消息復制的延遲問題.)
2. RocketMQ集群物理部署結構
RocketMQ的部署結構有一下特點:
Name Server是一個無狀態節點, 可以集群部署, 節點之間沒有信息同步.Broker部署分為Master和Slave. 一個master對應多個slave,但是一個slave只可以有一個master, 他們之間的對應關系通過制定相同的BrokerName, 不同的BrokerId來定義,BrokerId為0表示master,非0表示Slave,Master也可以部署多個. 每個Broker與Name Server集群中的所有節點建立長連接, 定時注冊Topic信息到所有Name Server.Producer與Name Server集群中的其中一個節點(隨機選擇)建立長連接,定期從Name Server獲取Topic信息,並且向提供服務的Topic服務的Master建立長連接, 並且定時向Master發送心跳.Consumer和Name Server集群中的其中一個節點(隨機選擇)建立長連接, 定期從Name Server取Topic路由信息, 並且向提供Topic服務的Master建立長連接, 且定時發送心跳.Consumer既可以從Master訂閱消息,也可以從Slave訂閱消息. 規則由Broker決定.
3. RocketMQ邏輯部署結構
3.1 Producer Group
用來表示一個發送消息的應用, 一個
Producer Group下包含多個Producer實例,可以使多個機器,也可以是一台機器的多個進程, 或者一個進程的多個Producer對象. 一個Producer Group可以發送多個Topic消息,Producer Group的作用如下:
- 標識一類的Producer
- 可以通過運維工具查詢這個發送消息的應用下有多少個Producer實例.
- 發送分布式事務消息的時候,如果Producer中途意外宕機,Broker會主動回調Producer Group內的任意一台機器來確認是無狀態.
3.2 Consumer Group
用來表示一個消費消息應用,默認為一個Consumer Group下的多個Consumer以均攤的方式消費信息, 如果設置為廣播方式的話,這個Consumer Group下的所有Consumer會消費全部的數據.
4. RocketMQ集群部署模式
4.1 單Master模式
也就是只有一個Master節點, 稱不上是集群, 一旦這個Master節點宕機, 那么整個服務就不可用, 也就是自己學習的時候搞一搞.
4.2 多Master模式
多個Master節點組成集群, 單個Master節點宕機或者重啟對應用沒有影響.
- 優點: 所有模式中性能最高.
- 缺點: 單個Master節點宕機期間, 未被消費的消息在節點恢復之前不可用, 消息的實時性就收到影響.
- 注意: 使用同步技術可以保證消息不丟失, 同時Topic相對應的Queue應該分布在急群眾的各個節點,而不是某個節點上,否則,該節點的宕機會導致對訂閱該topic的應用造成影響.
4.3 多Master多Slave異步復制模式
在多Master的基礎上, 每個節點都有至少一個的Slave, Master節點可讀可寫, 但是Slave節點只讀不寫, 類似於MySQL的主備模式.
- 優點: 在Master宕機的時候, 消費者可以從Slave讀取消息, 消息的實時性不會受到影響, 性能幾乎和多Master一樣.
- 缺點: 異步復制的同步方式和能導致消息丟失.
4.4 多Master多Slave同步雙寫模式
同多Master多Slave異步復制模式類似, 區別在於Master和Slave之間的數據同步方式.
- 優點: 同步雙寫的同步模式能保證數據不丟失.
- 缺點: 發送翻個消息的RT越長, 性能相比異步復制低10%.
- 刷盤策略: 同步刷盤和異步刷盤(節點自身數據是同步還是異步存儲)
- 同步方式: 同步雙寫和異步復制(一組Master和Slave之間的數據同步)