【中间件】学习记录·RocketMQ(一)
一、简介
官网文档地址:https://rocketmq.apache.org/zh/docs/
RocketMQ是由阿里捐赠给Apache的一款低延迟、高并发、高可用、高可靠的分布式消息中间件。经历了淘宝双十一的洗礼。RocketMQ既可为分布式应用系统提供异步解耦和削峰填谷的能力,同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。
MQ(Message Queue)消息队列,是基础数据结构中“先进先出”的一种数据结构。一般用来解决应用解耦,异步消息,流量削峰等问题,实现高性能,高可用,可伸缩和最终一致性架构。
二、MQ用途
1. 异步
提升用户体验和系统吞吐量,把一部分同步的动作异步化,提高接口响应率(RT)。例如:现在门店用户注册,后台的逻辑中会涉及到发放优惠券,推送环保局,推送云门店,所有业务都是同步执行,接口的响应大概需要2.1秒,随着业务复杂度提高,时间会越来越长。引入MQ之后,注册操作注册成功后,发送消息到MQ。相关的业务自行订阅,各自处理,能够大量降低RT。

2. 解耦
一个业务需要多个模块共同实现,或者一条消息有多个系统需要对应处理,只需要主业务完成以后,发送一条MQ,其余模块消费MQ消息,即可实现业务,降低模块之间的耦合
3. 削峰
高并发情况下,业务异步处理,提供高峰期业务能力,避免系统瘫痪
4. 数据采集
分布式系统会产生大量的数据流,比如业务日志,用户行为等。针对数据流进行批量的采集,汇总可以通过MQ进行。
5. 大规模机器的缓存同步
双十一大促时,各个分会场会有玲琅满目的商品,每件商品的价格都会实时变化。使用缓存技术也无法满足对商品价格的访问需求,缓存服务器网卡满载。访问较多次商品价格查询影响会场页面的打开速度。
此时需要提供一种广播机制,一条消息本来只可以被集群的一台机器消费,如果使用消息队列RocketMQ的广播消费模式,那么这条消息会被所有节点消费一次,相当于把价格信息同步到需要的每台机器上,取代缓存的作用。
三、MQ缺点
- 系统可用性降低:系统引入的外部依赖越多,系统稳定性越差。一旦MQ宕机,就会对业务造成影响
- 系统的复杂度提高:MQ的加入大大增加了系统的
复杂度,以前系统间是同步的远程调用,现在是通过MQ进行异步调用。 - 消息一致性问题:A系统处理完业务,通过MQ给B、C、D三个系统发消息数据,如果B系统、C系统处理成功,D系统处理失败
四、MQ对比
五、RocketMQ基本概念

1. 消息(Message)
消息是 Apache RocketMQ 中的最小数据传输单元。生产者将业务数据的负载和拓展属性包装成消息发送到Apache RocketMQ服务端,服务端按照相关语义将消息投递到消费端进行消费。消息具备不可变性,在初始化发送和完成存储后即不可变
2. 主题(Topic)
主题是 Apache RocketMQ 中消息传输和存储的顶层容器,用于标识同一类业务逻辑的消息。
主题的主要作用:定义数据的分类隔离,定义数据的身份和权限。主题是一个逻辑概念,并不是实际消息容器,Queue才是消息的实际容器。
3. 队列(Queue)
队列是Apache RocketMQ中消息存储和传输的实际容器,也是Apache RocketMQ消息的最小存储单元。Apache RocketMQ的所有主题都是由多个队列组成,以此实现队列数量的水平拆分和队列内部的流式存储。
4. 生产者(Producer)
生产者是Apache RocketMQ系统中用来构建并传输消息到服务端的运行实体。生产者通常被集成在业务系统中,将业务消息按照要求封装成消息并发送至服务端。
5. 消费者(Consumer)
消费者是Apache RocketMQ中用来接收并处理消息的运行实体。消费者通常被集成在业务系统中,从Apache RocketMQ服务端获取消息,并将消息转化成业务可理解的信息,供业务逻辑处理。消费者必须被指定到某一个消费组中。
6. 消费者分组(ConsumerGroup)
消费者分组是Apache RocketMQ系统中承载多个消费行为一致的消费者的负载均衡分组。
和消费者不同,消费者分组并不是运行实体,而是一个逻辑资源。在Apache RocketMQ中,通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。
六、RocketMQ系统架构

1. NameServer
NameServer是一个Broker和Topic路由的注册中心,支持Broker的动态注册和发现。
主要功能:
- Broker管理:接收
Broker集群的注册信息并且保存,提供心跳检测机制。 - 路由信息管理:每个
NameServer都保存着Broker集群的路由信息,和客户端查询的队列信息。Producer和Consumer可以从NameServer中获取到Broker的路由信息,完成消息的投递和消费。
路由注册
NameServer是无状态的,各节点间不相互通讯。Broker启动时,会轮询NameServer列表,与每个NameServer建立长连接,发起注册请求,NameServer存储每个Broker信息。
Broker每隔30s会发送一次心跳包,证明自己还存活着。
路由剔除
NameServer定时任务,每隔10s会轮询遍历一遍Borker最近一次的心跳时间和当前时间是否超过120s。超过就会剔除。
路由发现
NameServer采用的是pull模型,当Topic发生变化时,NameServer不会主动推送给客户端,而是客户端定时拉取。每隔30s,客户端会拉取一次。
pull模型:拉取模型,实时性差。
push模型:服务端压力大
long polling: 长轮询,定时建立一个长连接,然后连接保持一段时间后断开。整合了pull和push的优势。
客户端NameServer的选择策略
首先采用随机策略,连接失败后,采用轮询策略。
随机策略:客户端产生一个随机数,对集群NameServer个数取模,得到NameServer索引,进行连接。
2. Broker
消息中转角色,负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据,包括消费者组、消费进度偏移和主题和队列消息等。
