1、重要概念及说明
Disk Flush（磁盘刷新/同步操作）：就是将内存的数据落地，存储在磁盘中。RocketMQ提供了以下两种模式：
SYNC_FLUSH（同步刷盘）：生产者发送的每一条消息都在保存到磁盘成功后才返回告诉生产者成功。这种方式不会存在消息丢失的问题，但是有很大的磁盘IO开销，性能有一定影响。
ASYNC_FLUSH（异步刷盘）：生产者发送的每一条消息并不是立即保存到磁盘，而是暂时缓存起来，然后就返回生产者成功。随后再异步的将缓存数据保存到磁盘，有两种情况：1是定期将缓存中更新的数据进行刷盘，2是当缓存中更新的数据条数达到某一设定值后进行刷盘。这种方式会存在消息丢失（在还未来得及同步到磁盘的时候宕机），但是性能很好。默认是这种模式。
Broker Replication（Broker间数据同步/复制）：集群环境下需要部署多个Broker，Broker分为两种角色：一种是master，即可以写也可以读，其brokerId=0，只能有一个；另外一种是slave，只允许读，其brokerId为非0。一个master与多个slave通过指定相同的brokerName被归为一个broker set（broker集）。通常生产环境中，我们至少需要2个broker set。Broker Replication只的就是slave获取或者是复制master的数据。
Sync Broker：生产者发送的每一条消息都至少同步复制到一个slave后才返回告诉生产者成功，即“同步双写”。
Async Broker：生产者发送的每一条消息只要写入master就返回告诉生产者成功。然后再“异步复制”到slave。
推荐的几种Broker集群方式：（官网提供了下面几种集群方式的配置文件供参考，在$ROCKETMQ_HOME/target/apache-rocketmq-all/conf目录下）
2m-2s-sync：两主两从同步双写（两个master，两个slave，数据同步双写到master和slave）
2m-2s-async：两主两从异步复制（两个master，两个slave，master数据通过异步复制到slave）
2m-noslave：两主（只有两个master，没有slave）
1、上述“2”只是说作为一个集群的最低配置数量，可以根据实际情况扩展。
2、所有的刷盘（Dish Flush）操作全部默认为：ASYNC_FLUSH（异步刷盘）。
Name Server集群：Name Server集群比较简单，只要部署多个实例就行了，多个实例间不需要进行数据共享，只要保证一个实例存活就可以正常运转。
2、三种Broker集群方式优缺点
上面三种集群方式的优缺点（主要区别在于主从复制方式）：
多Master模式（2m-noslave）
一个集群无Slave，全是Master，例如2个Master或者3个Master 优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢）。性能最高。 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到受到影响。
多Master多Slave模式，异步复制（2m-2s-async）
每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟，毫秒级。 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为Master宕机后，消费者仍然可以从Slave消费，此过程对应用透明。不需要人工干预。性能同多Master模式几乎一样。 缺点：Master宕机，磁盘损坏情况，会丢失少量消息。
多Master多Slave模式，同步双写（2m-noslave）
每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，主备都写成功，向应用返回成功。 优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高 缺点：性能比异步复制模式略低，大约低10%左右，发送单个消息的RT会略高。目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。
3物理部署结构
以多Master多Slave模式为例，看一下RocketMQ物理部署结构：
NameServer NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
Broker Broker 部署相对复杂，Broker分为Master和Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
Producer Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
Consumer Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
4双主集群部署
这里就以双主集群为例，进行搭建。（双主集群会部署搭建，多主或多主多从也自然没啥问题了）
1. 服务器环境 如果条件允许，NameServer和broker分别在单独的机器上部署，我是用自己的电脑建的虚拟机，在虚拟机中部署的，限于自己电脑的配置，NameServer和broker就放在一台机器上了。 192.168.113.132和192.168.113.135
1)启动nameserver，分别启动两台服务器的nameserver
2)启动192.168.113.132\192.168.113.132 broker
nohup sh mqbroker -n '127.0.0.1:9876;192.168.113.135:9876' -c ../conf/2m-2s-async/broker-a.properties &
tail -f ~/logs/rocketmqlogs/broker.log 查看日志
注意：如果日志中输出的启动的broker的ip不正确，是因为机器多网卡的原因，造成了自动获取了另外网卡的Ip地址，这种情况下，就需要手动指定ip：
sudo vi ../conf/2m-2s-async/broker-a.properties
如果不手动指定IP的话，后面slave获取到此master的地址就是默认地址，导致连接不上master。
查看集群情况 ./mqadmin clusterList -n 127.0.0.1:9876
这里把常用的参数配置基本都列了出来，具体意思在注释里：
PS：
如果要搭主从，再次重申一遍Master与Slave在配置中的区别
Broker与Slave配对是通过指定相同的brokerName参数来配对，Master的BrokerId 必须是0，Slave的BrokerId必须是大于0的数。另外一个Master下面可以挂载多个Slave，同一Master下的多个Slave 通过指定不同的BrokerId来区分。
Broker 重启对客户端的影响
Broker 重启可能会导致正在发往这台机器的的消息发送失败，RocketMQ提供了一种优雅关闭Broker的方法，通过执行以下命令会清除Broker的写权限，过40s后，所有客户端都会更新Broker路由信息，此时再关闭Broker就不会发生发送消息失败的情况，因为所有消息都发往了其他 Broker。
# sh mqadmin wipeWritePerm -b brokerName -n namesrvAddr
Master 与Slave的关系
RocketMQ的开源版本，Master宕机，Slave不能切换为Master，这里的Slave不可写，但可读，类似于 Mysql 主备方式。
https://blog.csdn.net/zhanglianhai555/article/details/76554077
