RocketMQ的Broker集群搭建
Master和slaver类似Redis和MySql的主从，Slaver只有读的权限，没有写的权限。
RocketMQ提供了多种的集群搭建，具体如下：
1.单个 Master
这种方式风险较大，一旦 Broker 重启或者宕机时，会导致整个服务不可用，不建议线上环境使用
2. 多 Master 模式
一个集群无 Slave，全是 Master，例如 2 个 Master 或者 3 个 Master
优点：配置简单，单个 Master 宕机或重启维护对应用无影响，在磁盘配置为 RAID10 时，即使机器宕机不可恢复情况下，由于 RAID10 磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢）。性能最高。
缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
类似关系图如下：
因为MQ会进行本地IO刷盘的操作，所以一台MQ如果是进行同步刷盘将不会丢失消息，异步刷盘可能丢失少量数据。
且因为宕机的原因，在Master未启动时，该MQ存储的消息都无法被消费，实时性受到影响。
3. 多 Master 多 Slave 模式，异步复制
每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采用异步复制方式，主备有短暂消息延迟，毫秒级。
优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为 Master 宕机后，消费者仍然可以从 Slave 消费，此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。
缺点：Master 宕机，磁盘损坏情况，会丢失少量消息。
4. 多 Master 多 Slave 模式，同步双写
每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采用同步双写方式，主备都写成功，向应用返回成功。
优点：数据不服务都无单点，Master 宕机情况下，消息无延迟，服务可用性不数据可用性都非常高
缺点：性能比异步复制模式略低，大约低 10%左右，发送单个消息的 RT 会略高。目前主宕机后，备机不能自劢切换为主机，后续会支持自动切换功能。（这是3.2.6的官方文档的说明，现如今可能已经可以自动切换了，我还需要重新寻找资料进行确定）
同步双写和异步复制的区别
区别在于返回ACK确认包（CONSUME_SUCCESS）的时机。同步双写是在MQ将消息写入本地磁盘结束后，才返回给确认信息给生产者。异步复制是MQ两者进行异步操作，一边返回确认信息，一边写入磁盘。
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 配置决定。
可以从上面的出以下关键点：
1，Name Server是一个关于Topic的网络路由管理器，它存放和管理所有的Topic。所有的Broker都要定时注册Topic信息到路由中。
2.所有的Producer和Consumer都不是直接与MQ（Broker）进行交互的。它需要先根据自己的Topic到Name Server中获取该Topic对应哪台Broker。拿到路由信息，再进行交互。
3.Name Server之间不进行数据通信，与Zookeeper不同之处体现出来了