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

DBC 819 0
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
温馨提示

这里看不懂的,去看RocketMQ的安装配置,有更详细的,这里只是教简单搭主从

编辑并启动rocketmq命令
主节点
主节点
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties &

namesrvAddr=192.168.159.129:9876;192.168.159.130:9876
brokerClusterName=XdclassCluster
brokerName=broker-a
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
温馨提示

这里简单解释一下,可以看到前面的参数都是一样的,直到那个Id不一样,这里的意思就是0为主节点,而大于0的都是从节点,你可以随意设置,其他的参数不知道无所谓,最下面的也就是策略相关了,注意主从节点的相应区别,别搞混了

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

namesrvAddr=192.168.159.129:9876;192.168.159.130:9876
brokerClusterName=XdclassCluster
brokerName=broker-a
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
使用管控台
修改事项
pom.xml  里面的rocketmq版本号
application.properties里面的nameserver

增加 rocketmq.config.namesrvAddr=192.168.159.129:9876;192.168.159.130:9876

mvn install -Dmaven.test.skip=true

java -jar rocketmq-console-ng-1.0.0.jar

可能遇到的问题

centos7关闭防火墙
systemctl stop firewalld

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

简介:讲解主节点Broker退出后,从节点可继续被消费者消费

步骤

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

注意修改这个位置的地址

RocketMQ4.X集群高可用之主从模式搭建插图

RocketMQ4.X主从同步必备知识点

 

  • Broker分为master与slave,一个master可以对应多个Slave,但一个slave只能对应一个master,master与slave通过相同的Broker Name来匹配,不同的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恢复,未同步过去的消息会被最终消费掉

 

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

发表评论 取消回复
表情 图片 链接 代码

分享