1、RocketMQ 集群物理部署結構
RocketMQ 物理部署結構
RocketMQ的部署結構有以下特點：
Name Server是一個幾乎無狀態節點，可集群部署，節點之間無任何信息同步。
Broker部署相對復雜，Broker分為Master與Slave，一個Master可以對應多個Slave，但是一個Slave只能對應一個Master，Master與Slave的對應關系通過指定相同的BrokerName，不同的BrokerId來定義，BrokerId為0表示Master，非0表示Slave。Master也可以部署多個。每個Broker與Name Server集群中的所有節點建立長連接，定時注冊Topic信息到所有Name Server。
Producer與Name Server集群中的其中一個節點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master建立長連接，且定時向Master發送心跳。Producer完全無狀態，可集群部署。
Consumer與Name Server集群中的其中一個節點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master、Slave建立長連接，且定時向Master、Slave發送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規則由Broker配置決定。
2、RocketMQ 邏輯部署結構
Producer Group
用來表示一個發送消息應用，一個Producer Group下包含多個Producer實例，可以是多臺機器，也可以是一臺機器的多個進程，或者一個進程的多個Producer對象。一個Producer Group可以發送多個Topic消息，Producer Group作用如下：
- 標識一類Producer
- 可以通過運維工具查詢這個發送消息應用下有多個Producer實例
- 發送分布式事務消息時，如果Producer中途意外宕機，Broker會主動回調Producer Group內的任意一臺機器來確認事務狀態。
Consumer Group
用來表示一個消費消息應用，一個Consumer Group下包含多個Consumer實例，可以是多臺機器，也可以是多個進程，或者是一個進程的多個Consumer對象。一個Consumer Group下的多個Consumer以均攤方式消費消息，如果設置為廣播方式，那么這個Consumer Group下的每個實例都消費全量數據。
3、RocketMQ 集群部署模式
1> 單 master 模式
也就是只有一個 master 節點，稱不上是集群，一旦這個 master 節點宕機，那么整個服務就不可用，適合個人學習使用。
2> 多 master 模式
多個 master 節點組成集群，單個 master 節點宕機或者重啟對應用沒有影響。
優點：所有模式中性能最高
缺點：單個 master 節點宕機期間，未被消費的消息在節點恢復之前不可用，消息的實時性就受到影響。
注意：使用同步刷盤可以保證消息不丟失，同時 Topic 相對應的 queue 應該分布在集群中各個節點，而不是只在某各節點上，否則，該節點宕機會對訂閱該 topic 的應用造成影響。
3> 多 master 多 slave 異步復制模式
在多 master 模式的基礎上，每個 master 節點都有至少一個對應的 slave。master
節點可讀可寫，但是 slave 只能讀不能寫，類似于 mysql 的主備模式。
優點： 在 master 宕機時，消費者可以從 slave 讀取消息，消息的實時性不會受影響，性能幾乎和多 master 一樣。
缺點：使用異步復制的同步方式有可能會有消息丟失的問題。
4> 多 master 多 slave 同步雙寫模式
同多 master 多 slave 異步復制模式類似，區別在于 master 和 slave 之間的數據同步方式。
優點：同步雙寫的同步模式能保證數據不丟失。
缺點：發送單個消息 RT 會略長，性能相比異步復制低10%左右。
刷盤策略：同步刷盤和異步刷盤（指的是節點自身數據是同步還是異步存儲）
同步方式：同步雙寫和異步復制（指的一組 master 和 slave 之間數據的同步）
注意：要保證數據可靠，需采用同步刷盤和同步雙寫的方式，但性能會較其他方式低。
5> summary
單Master無Slave（脆弱）
單Master多Slave（單點故障就癱，開源版無主備切換功能）
多Master無Slave（無單點故障，線上生產常用模式）
多Master多Slave（無單點故障）
