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

1. RocketMQ集群模式架构分析

1.1 单节点

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

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

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

1.3 双主

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

1.4 双主双从,多主多从模式(异步复制)

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

1.5 双主双从,多主多从模式(同步双写)

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

推荐方案2,4,5

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

同步刷盘:消息进来之后,broker获取到消息,内存中消息一有更新,马上会往磁盘里头写入数据
异步刷盘:异步刷盘数据可能丢失,但是性能会更高,因为同步刷盘是消息进入内存之后,不会马上返回,等把数据存入磁盘之后才会返回成功,异步刷盘是把消息存入内存之后就会马上返回,异步将数据存入磁盘中,所以异步刷盘性能会比同步刷盘性能更高
RocketMQ集群架构分析与主从模式搭建_第1张图片
两个方式各有优缺点,要么保证性能,要么保证消息的可靠性,选择策略时看业务需求

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

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

最终推荐:同步双写(即Master-Slave同步复制),异步刷盘
RocketMQ集群架构分析与主从模式搭建_第2张图片

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

4.1 环境准备

机器列表

server1 ssh [email protected]
server1 ssh [email protected]

软件环境
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
  1. 编辑并启动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 &
  1. 使用控制台
修改
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的数量

你可能感兴趣的:(RocketMQ)