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不能自动切换为主机，后续会支持自动切换功能。