RocketMq使用经验总结

  • Post author:
  • Post category:其他

RocketMq简介

基本概念

Produce

消息生产者,负责产生消息,一般由业务系统负责产生消息。

Consumer

消息消费者,负责消费消息,一般是后台系统负责异步消费。

Push Consumer

Consumer的一种,应用通常向Consumer对象注册一个Listener接口,一旦收到消息,Consumer对象立刻回调Listener接口方法。

Pull Consumer

Consumer的一种,应用通常主动调用Consumer的拉消息方法从Broker拉消息,主动权由应用控制。

ProducerGroup

一类Producer的集合名称,这类Producer通常发送一类消息,且发送逻辑一致。

Consumer Group

一类Consumer的集合名称,这类Consumer通常消费一类消息,且消费逻辑一致。

Broker

消息中转角色,负责存储消息,转发消息,一般也称为Server

NameService

负责路由,管理。

广播消费

一条消息被多个Consumer消费,即使这些Consumer属于同一个Consumer Group,消息也会被Consumer Group中的每个Consumer都消费一次,广播消费中的Consumer Group概念可以认为在消息划分方面无意义。

集群消费

一个Consumer Group中的Consumer实例平均分摊消费消息。例如某个Topic有9条消息,其中一个Consumer Group有3个实例(可能是3个进程,或者3台机器),那么每个实例只消费其中的3条消息。

消费方式如图:
在这里插入图片描述

部署架构设计如图:
在这里插入图片描述

  1. Name Server是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。

  2. Broker部署相对复杂,Broker分为Master与Slave,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master,Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接,定时注册Topic信息到所有Name Server。

  3. Producer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master建立长连接,且定时向Master发送心跳。Producer完全无状态,可集群部署。

  4. Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master、Slave建立长连接,且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。

Producer、Consumer、topic关系如图:
在这里插入图片描述

图中红字出现的原因:

在不同的 JVM 中启动了多个 Consumer,并且给相同的 Consumer ID 配置了不同的 Topic,
或者是相同的 Topic 但 Tag 不同,最终导致订阅关系不一致,消息不符合预期

生产问题总结

  1. 不同jvm同一topic下,tag的订阅不一致,导致消息状态不一致,产生消费堵塞;
  2. 同一个consumer分组下面的consumer的topic订阅不一致,导致消息状态不一致,产生消费堵塞;
  3. 某一个consumer下线之后,下线状态没有同步整个集群;
  4. 某个broker下没有消费者注册;
  5. 网络不稳定或是消费者consumer重启,消息重复消费

生产经验总结

生产中出现的问题最多的就是:消息状态不一致,导致消息挤压,比如前面提到的a、b两个问题。解决方案:“在不同的 JVM 中启动了多个 Consumer,并且给相同的 Consumer ID 配置了不同的 Topic,或者是相同的 Topic 但 Tag 不同,最终导致订阅关系不一致,消息不符合预期”;

问题3、4其实从解决方案上来说都是属于同一类问题。解决方案:查看相应消息对应的consumer分组下面的topic上是否有注册上应该注册的消费者。

如图:
在这里插入图片描述

如果有问题只能选择性的重启某个或是全部broken或者所有的NameService。
问题5的解决方案:业务上做去重处理,可以根据业务上的唯一订单号,也可以根据rocketMq的messageId来做限制

安全与高可用

刷盘策略

RocketMQ的所有消息都是持久化的,先写入系统PAGECACHE,然后刷盘,可以保证内存与磁盘都有一份数据,访问时,直接从内存读取。可分类为同步刷盘、异步刷盘,如图:
在这里插入图片描述
在这里插入图片描述

同步双写/异步复制

异步复制的实现思路非常简单,Slave启动一个线程,不断从Master拉取Commit Log中的数据,然后在异步build出Consume Queue数据结构。
同步双写主备都写成功的时候才向应用返回成功。整个实现过程基本同Mysql主从同步类似。

NameService

nameservice主要是起到路由功能,注册和发现服务。NameService是无状态的,可以部署多套,可保证高可用

Broker部署结构

###单个Master
这种方式风险较大,一旦Broker重启或者宕机时,会导致整个服务不可用,不建议线上环境使用

多Master模式

一个集群无Slave,全是Master,例如2个Master或者3个Master。

优点:配置简单,单个Master宕机或重启维护对应用无影响,在磁盘配置为RAID10时,即使机器宕机不可恢复情况下,由于RAID10磁盘非常可靠,消息也不会丢(异步刷盘丢失少量消息,同步刷盘一条不丢),性能最高。

缺点:单台机器宕机期间,这台机器上未被消费的消息在机器恢复之前不可订阅,消息实时性会受到受到影响。

多Master多Slave模式,异步复制

每个Master配置一个Slave,有多对Master-Slave,HA采用异步复制方式,主备有短暂消息延迟,毫秒级。

优点:即使磁盘损坏,消息丢失的非常少,且消息实时性不会受影响,因为Master宕机后,消费者仍然可以从Slave消费,此过程对应用透明。不需要人工干预。性能同多Master模式几乎一样。

缺点:Master宕机,磁盘损坏情况,会丢失少量消息。

多Master多Slave模式,同步双写

每个Master配置一个Slave,有多对Master-Slave,HA采用同步双写方式,主备都写成功,向应用返回成功。

优点:数据与服务都无单点,Master宕机情况下,消息无延迟,服务可用性与数据可用性都非常高

缺点:性能比异步复制模式略低,大约低10%左右,发送单个消息的RT会略高。目前主宕机后,备机不能自动切换为主机,后续会支持自动切换功能。

Broker重启对客户端的影响

Broker重启可能会导致正在发往这台机器的的消息发送失败,RocketMQ提供了一种优雅关闭Broker的方法,通过执行以下命令会清除Broker的写权限,过40s后,所有客户端都会更新Broker路由信息,此时再关闭Broker就不会发生发送消息失败的情况,因为所有消息都发往了其他Broker。
sh mqadmin wipeWritePerm-b brokerName -n namesrvAddr

运维步骤及常见问题:

线上环境架构

一般生产环境采用多Master多Slave模式,异步复制方式,当前线上Master部署部署在一台机,Slave部署在另一台机,如图:
在这里插入图片描述

关键位置配置 –- broker-a.properties

brokerClusterName=rocketmq-sxzy  #所属集群名称
brokerName=broker-a   #broker名字,注意此处不同的配置文件填写的不一样
#nameServer地址,分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876;rocketmq-nameserver3:9876;rocketmq-nameserver4:9876 
brokerId=0 #0表示Master,>0 表示 Slave
deleteWhen=04 #删除文件时间点,默认凌晨 4点
fileReservedTime=120 #文件保留时间,默认 48 小时
defaultTopicQueueNums=4 #在发送消息时,自动创建服务器不存在的topic,默认创建的队列数
autoCreateTopicEnable=true #是否允许 Broker 自动创建Topic,建议线下开启,线上关闭
autoCreateSubscriptionGroup=true #是否允许 Broker 自动创建订阅组,建议线下开启,线上关闭
#Broker 对外服务的监听端口
listenPort=10911  
mapedFileSizeConsumeQueue=300000 #ConsumeQueue每个文件默认存30W条,根据业务情况调整
brokerRole=ASYNC_MASTER # 异步复制Master
flushDiskType=ASYNC_FLUSH #异步刷盘

重启脚本

#!/bin/sh
#kill 进程
echo "正在关闭 mq-server"
/data/cloud2/RocketMq/bin/mqshutdown namesrv
sleep 1
ps -ef |grep mqnamesrv |grep -v grep |awk '{print $2}' |xargs kill -9
echo "正在关闭 mq-broker"=
/data/cloud2/RocketMq/bin/mqshutdown broker
sleep 1
ps -ef |grep broker|grep -v grep |awk '{print $2}' |xargs kill -9
#启动进程
echo "正在启动mq-server"
nohup sh /usr/cloud2/RocketMq/bin/mqnamesrv >/usr/cloud2/RocketMq/logs/mqnamesrv.log 2>&1 &
sleep 1
echo "正在启动broker-a"
nohup  sh /usr/cloud2/RocketMq/bin/mqbroker  -c  /usr/cloud2/RocketMq/conf/2m-2s-sync/broker-a.properties  > /usr/cloud2/RocketMq/logs/broker-a.log  2>&1 &
sleep 1
echo "正在启动broker-b"
nohup sh /usr/cloud2/RocketMq/bin/mqbroker  -c  /usr/cloud2/RocketMq/conf/2m-2s-sync/broker-b.properties  > /usr/cloud2/RocketMq/logs/broker-b.log  2>&1 &
sleep 1
jps
echo "mq服务启动完毕,请检查NamesrvStartup和BrokerStartup是否存在“

MQ控制台

RocketMQDemo

  1. 使用maven编译成war包,或从网上下载别人打好的包

  2. 修改config.properties

    rocketmq.namesrv.addr=mqnameserver1:9876;mqnameserver2:9876

  3. 启动tomcat,浏览器里输入 http://ip:端口/rocketmq-console 访问

rocketmq-console-ng

  1. 使用maven编译成war包,或从网上下载别人打好的包(网上大多jar)

  2. 修改application.properties

    rocketmq.config.namesrvAddr=mqnameserver1:9876;mqnameserver2:9876

  3. 启动tomcat,浏览器里输入 http://ip:端口/rocketmq-console-ng 访问
    或使用jar启动

    java -jar rocketmq-console-ng-1.0.0.jar –server.port=12581 –rocketmq.config.namesrvAddr=mqnameserver1:9876;mqnameserver2:9876

创建生产者

创建消费者

异常问题处理:

  1. 进程不存在::使用ps –ef |grep mq 或使用jps命令查看 Mqname 和
    brokerName组进程是否存在

  2. 磁盘空间满:如果磁盘满,根据下面路径删除最不重要的文件

    #存储路径
    storePathRootDir=/data/cloud2/RocketMq/data/store_a
    #commitLog 存储路径
    storePathCommitLog=/data/cloud2/RocketMq/data/store_a/commitlog
    #消费队列存储路径存储路径
    storePathConsumeQueue=/data/cloud2/RocketMq/data/store_a/consumequeue
    #消息索引存储路径
    storePathIndex=/data/cloud2/RocketMq/data/store_a/index
    #checkpoint 文件存储路径
    storeCheckpoint=/data/cloud2/RocketMq/data/store_a/checkpoint
    #abort 文件存储路径
    abortFile=/data/cloud2/RocketMq/data/store_a/abort

  3. 消息不消费:通过控制台检查订阅关系是否一致,和查看消费者终端信息

  4. 生产者故障:检查程序topic配置,实在检查不出问题直接执行上面重启脚本

现存未解决问题

各种高可用方案没有具体验证过。


版权声明:本文为qq_25868207原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。