RocketMQ分佈式集羣是通過Broker節點的Master和Slave配合達到高可用性的。
Master和Slave的區別：在Broker的配置文件中，參數 brokerId的值爲0表明這個Broker是Master，大於0表明這個Broker是 Slave，同時brokerRole參數也會說明這個Broker是Master還是Slave。
Master角色的Broker支持讀和寫，Slave角色的Broker僅支持讀，也就是Producer只能和Master角色的Broker連接寫入消息；Consumer可以連接 Master角色的Broker，也可以連接Slave角色的Broker來讀取消息。
PS：Master和Slave的職責沒什麼好說的，實際上所有的產品，Master一般都支持讀和寫，而Slave只支持讀。比如我們在《Redis：主從複製》和《Redis：集羣》中提到的Redis主節點和Redis從節點其實也是這樣的職責劃分。
1. 消息消費高可用
在Consumer的配置文件中，並不需要設置是從Master讀還是從Slave 讀，當Master不可用或者繁忙的時候，Consumer會被自動切換到從Slave 讀。有了自動切換Consumer這種機制，當一個Master角色的機器出現故障後，Consumer仍然可以從Slave讀取消息，不影響Consumer程序。這就達到了消費端的高可用性。
2. 消息發送高可用
在創建Topic的時候，把Topic的多個Message Queue創建在多個Broker組上（相同Broker名稱，不同 brokerId的機器組成一個Broker組），這樣當一個Broker組的Master不可用後，其他組的Master仍然可用，Producer仍然可以發送消息。 RocketMQ目前還不支持把Slave自動轉成Master，如果機器資源不足， 需要把Slave轉成Master，則要手動停止Slave角色的Broker，更改配置文 件，用新的配置文件啓動Broker。
3. 消息主從複製
如果一個Broker組有Master和Slave，消息需要從Master複製到Slave上，有同步和異步兩種複製方式。
3.1 同步複製
同步複製方式是等Master和Slave均寫成功後才反饋給客戶端寫成功狀態。
在同步複製方式下，如果Master出故障， Slave上有全部的備份數據，容易恢復，但是同步複製會增大數據寫入 延遲，降低系統吞吐量。
3.2 異步複製
異步複製方式是隻要Master寫成功即可反饋給客戶端寫成功狀態。
在異步複製方式下，系統擁有較低的延遲和較高的吞吐量，但是如果Master出了故障，有些數據因爲沒有被寫 入Slave，有可能會丟失。
3.3 配置
同步複製和異步複製是通過Broker配置文件裏的brokerRole參數進行設置的，這個參數可以被設置成ASYNC_MASTER、 SYNC_MASTER、SLAVE三個值中的一個。
3.4 刷盤和複製
實際應用中要結合業務場景，合理設置刷盤方式和主從複製方式， 尤其是SYNC_FLUSH方式，由於頻繁地觸發磁盤寫動作，會明顯降低性能。通常情況下，應該把Master和Slave配置成ASYNC_FLUSH的刷盤方式，主從之間配置成SYNC_MASTER的複製方式，這樣即使有一臺機器出故障，仍然能保證數據不丟。
PS：還記得Redis的主從複製嗎？如果不記得可以參考《Redis：主從複製》哦。
