RocketMQ推薦了幾種Broker集群方式，這里的Slave不可寫，但可讀，類似於Mysql主備方式
1. 單個Master
這是一種風險比較大的集群方式，因為一旦Borker重啟或宕機期間，將會導致這個服務不可用，因此是不建議線上環境去使用的。
2. 多個Master
一個集群全部都是Master，沒有Slave,它的優點和缺點如下：
優點：配置簡單，單個Master宕機或者是重啟維護對應用沒有什么影響的，在磁盤配置為RAID10時，即使機器宕機不可恢復的情況下，消息也不會丟失（異步刷盤丟失少量消息，同步刷盤則是一條都不會丟失），性能最高
缺點：當單個Broker宕機期間，這台機器上未被消費的消息在機器恢復之前不可訂閱，消息的實時性會受到影響。
3. 多Master多Slave模式-異步復制
每個Master配置一個Slave,有多對的Master-Slave，HA采用的是異步復制方式，主備有短暫的消息延遲，毫秒級別的（Master收到消息之后立刻向應用返回成功標識，同時向Slave寫入消息）。優缺點如下：
優點：即使是磁盤損壞了，消息丟失的非常少，且消息實時性不會受到影響，因為Master宕機之后，消費者仍然可以從Slave消費，此過程對應用透明，不需要人工干預，性能同多個Master模式機會一樣。
缺點：Master宕機，磁盤損壞的情況下，會丟失少量的消息。
4. 多Master多Slave模式-同步雙寫
每個Master配置一個Slave,有多對的Master-Slave，HA采用的是同步雙寫模式，主備都寫成功，才會向應用返回成功。
優點：數據與服務都無單點，Master宕機的情況下，消息無延遲，服務可用性與數據可用性都非常高
缺點：性能比異步復制模式略低，大約低10%左右，發送單個Master的RT會略高，目前主機宕機后，Slave不能自動切換為主機，后續會支持自動切換功能。