常见集群模式

 推荐方案 2、4、5

单节点

优点：本地开发测试，配置简单，如果采用同步刷盘，消息一条都不会丢。
    缺点：不可靠，如果宕机，会导致服务不可用

主从(异步、同步双写)

优点：同步双写消息不丢失, 异步复制存在少量丢失 ，主节点宕机，从节点可以对外提供消息的消费，但是不支持写入。
    缺点：主备有短暂消息延迟，毫秒级，目前不支持自动切换，需要脚本或者其他程序进行检测然后进行停止broker,重启让从节点成为主节点

双主

优点：配置简单, 可以靠配置RAID磁盘阵列保证消息可靠，异步刷盘丢失少量消息
    缺点: master机器宕机期间，未被消费的消息在机器恢复之前不可消费，实时性会受到影响

双主双从，多主多从模式（异步复制）

优点：磁盘损坏，消息丢失的非常少，消息实时性不会受影响，Master 宕机后，消费者仍然可以从Slave消费
    缺点：主备有短暂消息延迟，毫秒级，如果Master宕机，磁盘损坏情况，会丢失少量消息

双主双从，多主多从模式（同步双写）

优点：同步双写方式，主备都写成功，向应用才返回成功，服务可用性与数据可用性都非常高
    缺点：性能比异步复制模式略低，主宕机后，备机不能自动切换为主机

消息可靠性之同步 | 异步刷盘

 刷盘是指内存中的数据同步到磁盘中。简单的说就是三个字“持久化”。

• 同步刷盘：等待内存数据同步到磁盘完毕才会返回调用者，数据安全性高。
• 异步刷盘：数据写入到内存完毕就立刻返回调用者，之后自己负责将数据从内存中同步到磁盘中，数据存在丢失的风险，性能高。

消息可靠性之同步 | 异步复制

 复制是指 Master 节点复制到 Slave 的过程。

• 同步复制：数据在 Master 端写入成功仍需将数据同步到 Slave 端之后才会返回调用者。数据安全性高。
• 异步复制：数据在 Master 端写入成功则立刻返回调用者，之后会有相应线程将数据从 Master 同步到 Slave 中。数据可能丢失，性能高。

同步双写（复制），异步刷盘

 推荐使用同步复制配合异步刷盘。

集群高可用之主从模式搭建

机器列表

server1 ssh root@192.168.159.129	NameServer
server2 ssh root@192.168.159.130	NameServer

启动两个机器的 nameserver
nohup sh bin/mqnamesrv &

主节点

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties &

vim /test/rocketmq/distribution/target/apache-rocketmq/conf/2m-2s-sync/broker-a.properties  

namesrvAddr=192.168.159.129:9876;192.168.159.130:9876
brokerClusterName=SoulboyCluster
brokerName=broker-a
brokerId=0
 #表示master节点
deleteWhen=04
fileReservedTime=48
brokerRole=SYNC_MASTER #角色master  同步双写
flushDiskType=ASYNC_FLUSH #异步刷盘

从节点

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties &
vim /test/rocketmq/distribution/target/apache-rocketmq/conf/2m-2s-sync/broker-a-s.properties 

namesrvAddr=192.168.159.129:9876;192.168.159.130:9876
brokerClusterName=SoulboyCluster
brokerName=broker-a
brokerId=1 #大于0表示slave节点
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE #角色slave
flushDiskType=ASYNC_FLUSH #异步刷盘

可视化管控台

# 修改pom文件
vim /test/rocketmq-externals-master/rocketmq-console/pom.xml <rocketmq.version>4.4.0</rocketmq.version> #去掉 -SNAPSHOT

# 修改配置文件
vim /test/rocketmq-externals-master/rocketmq-console/src/main/resources/application.properties
rocketmq.config.namesrvAddr=192.168.159.129:9876;192.168.159.130:9876
   

#重新构建
cd /test/rocketmq-externals-master/rocketmq-console mvn clean package -Dmaven.test.skip=true  cd target/

# 以守护进程的方式启动RocketMQ-Console 
nohup java -jar /test/rocketmq-externals-master/rocketmq-console/target/rocketmq-console-ng-1.0.0.jar &

故障演练之主节点

• 发送一条消息，关闭主节点，关闭主节点之后不能写入。
• 从节点提供数据供外面消费，但不能接受写入请求。
• 主节点上线后同步从节点已经被消费的数据(offset 同步)

主从架构总结

 Broker 分为 master 与 slave。

• 一个 master 可以对应多个 Slave，但一个 slave 只能对应一个 master，
• master 与 slave 通过相同的 BrokerName 来匹配。
• 不同的 broker Id 来定义是 master 还是 slave。
• Broker 向所有的 NameServer 结点建立长连接，定时注册 Topic 和发送元数据信息。
• NameServer 定时扫描(默认 2 分钟)所有存活 broker 的连接, 如果超过时间没响应则断开连接(心跳检测)，但是 consumer 客户端不能感知，consumer 定时(30s)从 NameServer 获取 topic 的最新信息，所以 broker 不可用时，consumer 最多最需要 30s 才能发现。（Producer 的机制一样，在未发现 broker 宕机前发送的消息会失败）
• 只有 master 才能进行写入操作，slave 不允许写入只能同步，同步策略取决于 master 的配置。
• 客户端消费可以从 master 和 slave 消费，默认消费者都从 master 消费，如果在 master 挂后，客户端从 NameServer 中感知到 Broker 宕机，就会从 slave 消费， 感知非实时，存在一定的滞后性，slave 不能保证 master 的消息 100% 都同步过来了，会有少量的消息丢失。但一旦 master 恢复，未同步过去的消息会在 Master 端被最终消费掉。（如果是采用同步双写，就不会存在以上这样的问题）。
• 如果 consumer 实例的数量比 message queue 的总数量还多的话，多出来的 consumer 实例将无法分到 queue，也就无法消费到消息，也就无法起到分摊负载的作用，所以需要控制让 queue 的总数量大于等于 consumer 的数量（queue 的数量是 Consumer 的倍数或者相等或者大于）。