1.RocketMQ简介和搭建

最新推荐文章于 2023-08-16 16:57:49 发布

夹毛局的程序员

最新推荐文章于 2023-08-16 16:57:49 发布

阅读量365

点赞数

分类专栏： RocketMQ

本文链接：https://blog.csdn.net/woshiwjma956/article/details/113526246

版权

RocketMQ 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

简介

RocketMQ是一个整套轻量级的消息引擎和数据处理平台.

主要应用场景包括

应用解耦

符合现在微服务架构的理念,各业务系统进行微服务拆分解耦,使用消息中间件,连接通信各个微服务系统,使得应用整理耦合性降低,容错性提高.上游业务系统完成本职工作之后直接返回结果,发送消息到下游业务系统,使得用户体验更好.如下游物流系统发生故障,而上游订单系统正常继续执行,将产生的订单发送到消息队列中,等待下游物流系统修复之后继续消费处理信息,用户无感知下游系统的影响.
流量削峰

在应用系统在某一个时间点涌入大量请求,如秒杀,抢购等情况.一瞬间的流量可能将后端的数据库和业务系统压垮,有了消息队列可以将大量的请求缓存起来,分散到更大的时间段,可以提高系统的稳定性和用户体验.当负载超过某一个阈值则阻止用户请求,返回一个秒杀结束的页面可以提高用户的体验.也可以在大量涌入压垮业务系统之前,先缓存到消息队列中,当业务系统不那么繁忙的之后再逐步处理队列中的请求
数据分发

在微服务系统中提到很好的体现,数据产生方不关心下游谁来使用这个数据,只需将数据发送给消息队列,下游业务也不用关心谁生产的数据,直接订阅自己关心的数据,拿到数据之后进行自己系统的业务操作即可

MQ优点和缺点

系统可用性降低: 引入外部依赖,系统的稳定性降低,如果MQ宕机就会系统产生巨大影响
系统复杂度提高: 比起以前系统之间的同步调用,MQ的异步调用模式增加了开发的成本,需要考虑消息的重复消费,消息的丢失情况,消息传递顺序
一致性问题 A完成业务发送消息给BCD,BC成功处理,D失败,需要一个机制来保证数据的一致性

各种MQ的比较

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1jwPn9tV-1612174384613)(img\MQ比较.png)]

安装RocketMQ

官网下载最新的二进制包http://rocketmq.apache.org/dowloading/releases/
解压缩
修改conf目录下的broker配置文件
使用bin目录下的启动脚本 Linux使用 xx.sh windows使用xxx.cmd

4.8.0 release 采坑 Windows的broker.cmd有一个坑 40行因为他少一个引号需要改成

set “JAVA_OPT=%JAVA_OPT% -cp “%CLASSPATH%”” 才能正常启动

启动流程

启动Name Server

nohup sh bin/mqnamesrv &

tail -f ~/logs/rocketmqlogs/namesrv.log查看日志发现The Name Server boot success…说明启动成功
启动Broker

nohup sh bin/mqbroker -n localhost:9876 &

tail -f ~/logs/rocketmqlogs/broker.log 查看 The broker[%s, 172.30.30.233:10911] boot success…说明启动

测试发送消息

> export NAMESRV_ADDR=localhost:9876
> sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
 SendResult [sendStatus=SEND_OK, msgId= ...

> sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
 ConsumeMessageThread_%d Receive New Messages: [MessageExt...

详细参考官方文档http://rocketmq.apache.org/docs/quick-start/

RocketMQ各角色

NameSever 管理broker,负责接受broker上报的节点信息类似邮局管理机构
Broker 用于存储和发送消息类似邮局
Producer 消息生产者类似发信人
Consumer 消息消费者类似收信人
Topic 消息话题一个Producer可以发布给多个topic 一个Consumer也可以订阅多个topic 类似发给哪个地区
Message Queue Topic下的多个消息并行分发和接受消息队列

RocketMQ的集群搭建

NameServer是几乎无状态的节点,天然支持集群部署,NameServer节点之间不存在数据同步问题
Broker部署相对复杂,存在Master和Slave的角色,一个Master对应多个Slave,是1:N的关系,Master负责与Producer之间的消息接受和Consumer的消息消费,Slave只负责跟Consumer对接消费.当Master负载过高的之后,Slave主要承担消息的消费工作. BrokerId为0的表示Master,非0表示Slave.Master也可以部署多个,每个Master之间需要数据同步.Broker与NameServer之间建立长连接定期发布节点信息给NS
Produer与NameServer集群随机一个节点建立长连接,定期从NameServer获取各个topic的路由信息,并像提供的Topic符合的Broker的Master建立长连接,定期发送心跳.Produer无状态,天然支持集群部署
Consumer与NameServer集群随机一个节点建立长连接.定期从NameServer获取topic路由,并与提供Topic服务的Broker(Master和Slave)建立长连接,发送心跳.Consumer可以从Master和可以从Slave订阅消息.订阅规则右Broker的配置决定,Consumer无状态,天然支持集群部署

,常见的几种集群搭建模式

单Master

部署简单,单风险较大,一旦Broker宕机导致整个MQ不可用,可用于测试环境
多Master模式

集群中没有Slave,全是Master,如3个Master. 优点在于配置简单,单Master宕机对集群无影响,但建议配合磁盘阵列RAID10来进行使用,由于RAID10磁盘可靠性高,如果采用同步刷盘的情况下不会出现消息的丢失,性能高. 缺点在于单台的宕机使得这台机器上未被消费的信息在机器恢复之前不可订阅,消息的实时性会受到影响
多Master 多Slave的异步刷盘模式

优点: 磁盘损坏,消息丢失量少,消息的实时性不受影响,同时Master宕机后,消费者仍可以从Slave进行消费,性能高

缺点: Master宕机,磁盘损坏的情况下会丢失少量消息
多Master 多Slave 同步刷盘模式

优点: 数据与服务没有单点故障,节点宕机的情况下,消息无延迟,服务可用性高

缺点: 性能比异步刷盘模式略低10%,发送单个消息的RT会略高,目前版本再主节点宕机之后,备节点不能自动切换为主节点

搭建建议使用2M-2S 双主双从 + 异步刷盘 + 多NameServer的方式进行部署

这种即保证了MQ的可用性也保证了性能,只是存在少量丢失的风险.如果在对消息敏感的业务可以采用同步刷盘

配置参考解压之后的2m-2s-async 或者2m-2s-sync 需要注意的是一台机器配置的master和slave不同组

如节点A 配置broker-a-0 和broker-b-1 节点B 配置broker-b-0 broker-a-1

如果自己测试建议将项目的JVM启动堆参数调小

runserver.sh

JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"

Broker的配置文件解析

#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字，注意此处不同的配置文件填写的不一样
brokerName=broker-a
#0 表示 Master，>0 表示 Slave
brokerId=0
#nameServer地址，分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=10911
#删除文件时间点，默认凌晨 4点
deleteWhen=04
#文件保留时间，默认 48 小时
fileReservedTime=120
#commitLog每个文件的大小默认1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每个文件默认存30W条，根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/usr/local/rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

RocketMQ的集群管理

RocketMQ提供了CLI命令的管理工具mqadmin,支持的命令参考官方文档http://rocketmq.apache.org/docs/cli-admin-tool/,里面包括了创建topic 查看topic 查看集群信息等等

RocketMQ也提供了一个可视化的UI管理界面RocketMQ-console.需要自己去github上下载使用maven构建https://github.com/apache/rocketmq-externals/tree/master/rocketmq-console,中文文档https://rocketmq-1.gitbook.io/rocketmq-connector/rocketmq-connect/rocketmq-console/an-zhuang-shi-yong

安装完console之后默认8080端口访问

console