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条消息。
消费方式如图:
部署架构设计如图:
-
Name Server是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。
-
Broker部署相对复杂,Broker分为Master与Slave,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master,Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接,定时注册Topic信息到所有Name Server。
-
Producer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master建立长连接,且定时向Master发送心跳。Producer完全无状态,可集群部署。
-
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 不同,最终导致订阅关系不一致,消息不符合预期
生产问题总结
- 不同jvm同一topic下,tag的订阅不一致,导致消息状态不一致,产生消费堵塞;
- 同一个consumer分组下面的consumer的topic订阅不一致,导致消息状态不一致,产生消费堵塞;
- 某一个consumer下线之后,下线状态没有同步整个集群;
- 某个broker下没有消费者注册;
- 网络不稳定或是消费者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
-
使用maven编译成war包,或从网上下载别人打好的包
-
修改config.properties
rocketmq.namesrv.addr=mqnameserver1:9876;mqnameserver2:9876
-
启动tomcat,浏览器里输入 http://ip:端口/rocketmq-console 访问
rocketmq-console-ng
-
使用maven编译成war包,或从网上下载别人打好的包(网上大多jar)
-
修改application.properties
rocketmq.config.namesrvAddr=mqnameserver1:9876;mqnameserver2:9876
-
启动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
创建生产者
创建消费者
异常问题处理:
-
进程不存在::使用ps –ef |grep mq 或使用jps命令查看 Mqname 和
brokerName组进程是否存在 -
磁盘空间满:如果磁盘满,根据下面路径删除最不重要的文件
#存储路径
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 -
消息不消费:通过控制台检查订阅关系是否一致,和查看消费者终端信息
-
生产者故障:检查程序topic配置,实在检查不出问题直接执行上面重启脚本
现存未解决问题
各种高可用方案没有具体验证过。