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

曾经终败给现在 2023-07-04 12:54 17阅读 0赞

# 1. RocketMQ集群模式架构分析 #

## 1.1 单节点 ##

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

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

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

## 1.3 双主 ##

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

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

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

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

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

推荐方案2,4,5

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

同步刷盘：消息进来之后，broker获取到消息，内存中消息一有更新，马上会往磁盘里头写入数据  
异步刷盘：异步刷盘数据可能丢失，但是性能会更高，因为同步刷盘是消息进入内存之后，不会马上返回，等把数据存入磁盘之后才会返回成功，异步刷盘是把消息存入内存之后就会马上返回，异步将数据存入磁盘中，所以异步刷盘性能会比同步刷盘性能更高  
![在这里插入图片描述][20200211141847263.png]  
两个方式各有优缺点，要么保证性能，要么保证消息的可靠性，选择策略时看业务需求

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

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

最终推荐：同步双写(即Master-Slave同步复制)，异步刷盘  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70]

# 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

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的数量

[20200211141847263.png]: https://img-blog.csdnimg.cn/20200211141847263.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200211141747966.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw==,size_16,color_FFFFFF,t_70