RocketMQ集群架构分析与主从模式搭建

1. RocketMQ集群模式架构分析

1.1 单节点

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

1.2 主从(异步、同步消息)

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

1.3 双主

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

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

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

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

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

推荐方案2,4,5

2. 消息可靠性之同步、异步刷盘

同步刷盘：消息进来之后，broker获取到消息，内存中消息一有更新，马上会往磁盘里头写入数据
异步刷盘：异步刷盘数据可能丢失，但是性能会更高，因为同步刷盘是消息进入内存之后，不会马上返回，等把数据存入磁盘之后才会返回成功，异步刷盘是把消息存入内存之后就会马上返回，异步将数据存入磁盘中，所以异步刷盘性能会比同步刷盘性能更高

两个方式各有优缺点，要么保证性能，要么保证消息的可靠性，选择策略时看业务需求

3. 消息可靠性之同步、异步复制

同步复制：消息进入master节点之后，master会把数据复制到slave节点，复制成功之后再会给客户端返回成功消息，效率较低，但是数据安全性高（数据安全性高，性能低一点）
异步复制：消息发送到master节点之后，master将给客户端返还成功消息，并异步的将消息复制到slave节点，效率较高，但是由于是异步复制，不能百分百保证数据复制成功（数据可能丢失，性能高）

最终推荐：同步双写(即Master-Slave同步复制)，异步刷盘

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

4.1 环境准备

机器列表

server1 ssh root@192.168.1.121
server1 ssh root@192.168.1.122

软件环境
RocketMQ+JDK8+Maven+CentOS7

4.2 安装

在各个节点安装RocketMQ环境，在上一篇博客中已经讲解安装教程，在这里不再重复安装

4.3 配置

1. 修改RocketMQ(启动内存配置，两个机器都要修改)

vim runserver.sh
JAVA_OPT="${JAVA_OPT} -server -Xms528m -Xmx528m -Xmn256m -
XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"
vim runbroker.sh
JAVA_OPT="${JAVA_OPT} -server -Xms528m -Xmx528m -Xmn256m"
启动两个机器的 nameserver
nohup sh bin/mqnamesrv &
全路径
/usr/local/software/rocketmq/distribution/target/apache-rocketmq

2. 编辑并启动rocketmq命令

修改 bin/mqbroker -c conf/2m-2s-async/broker-a.properties文件
namesrvAddr=192.168.1.121:9876;192.168.1.122:9876  # 启动服务的地址
brokerClusterName=XdclassCluster  # 集群名称
brokerName=broker-a    # 名称
brokerId=0  # brokerid 0代表是主节点 大于0是子节点
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER   # broker的角色 ASYNC_MASTER：主角色
flushDiskType=ASYNC_FLUSH  # 刷盘策略ASYNC_FLUSH ：异步刷盘

主节点启动broker指定配置文件
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties &

修改bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties文件
namesrvAddr=192.168.1.121:9876;192.168.1.122:9876
brokerClusterName=XdclassCluster
brokerName=broker-a
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH

从节点启动broker指定配置文件
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties &

3. 使用控制台

修改
pom.xml 里面的rocketmq版本号
application.properties里面的nameserver

增加rocketmq.config.namesrvAddr=192.168.1.121:9876;192.168.1.122:9876

mvn install -Dmaven.test.skip=true
java -jar rocketmq-console-ng-1.0.0.jar

5. 故障演练之主节点Broker退出保证消息可用

步骤

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

6. 主从同步必备知识点

• Broker分为Master与Slave，一个Master可以对应多个Slave，但一个slave只能对应一个master，master与slave通过相同的Broker Name来匹配，不同的BrokerID来定义master还是slave
  1. Broker向所有的NameServer节点建立长连接，定时注册topic和发送元数据信息
  2. NamseServer定时扫描(默认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恢复，未同步过去的消息会被最终消费掉。

• 如果consumer实例数量比message queue的总数量还多的话，多出来的consumer实例将无法分到queue，也就无法消费到消息，也就无法起到分摊负载的作用，所以需要控制让queue的总数量大于等于consumer的数量