Transliteration
Roducer fā xiāoxī, huì xiān lián
目录
RocketMQ事务
RocketMQ集群
集群特征
集群工作流程
消息的存储
顺序写与零拷贝
消息的存储结构
消息刷盘机制
同步刷盘:
异步刷盘:
MQ高可用与主从复制
高可用
主从复制
负载均衡
Producer负载均衡
Consumer负载均衡
消息重试
消息重试机制分为顺序消息和无序消息
死信队列
消息重复消费
幂等
RocketMQ事务
事务消息流程:
角色:生产者,消费者,本地事务,经纪人Broker(也就是我们的MQ)
- 消息的生产者首先会发一个半消息给我们的Broker
- 然后Broker会返回一个ok状态给生产者
- 生产者这时就会去访问本地事务,本地事务会告诉生产者发送的信息是提交还是回滚
- 生产者会将从本地事务获取到的结果返回给Broker(提交还是回滚),还有一种是无反应
- 如果是无反应的,Broker会在向生产者索要结果
- 生产者就会在向本地事务索要结果
- 最后生产者在将结果返回给Broker
- 如果Broker接收到的是提交就将生产者发送的消息保存起来,供消费者消费
- 如果Broker接收到的是回滚就将生产者发送的消息删除掉,消费者就不能消费该消息了
注:5-6-7步骤称为消息的补偿过程
![RocketMQ核心知识_第1张图片](http://img.e-com-net.com/image/info8/4b2d9e1a6a154149a887c1f9fbd29d49.jpg)
RocketMQ集群
单机:
使用单个Broker提供服务,一单Broker宕机,那么服务就不可用,也会造成一个数据的丢失
集群:
- 使用多个Broker提供服务,解决单机情况下Broker一旦宕机就不可用的情况
- Broker的作用是接收消息以及推送消息,也可以理解为读写操作
- 在一个集群下,如果每个Broker都做读写操作的话,性能会比较低,所以会采用读写分离
- 也就是说在集群下设置主机(master)与从机(slave),可以是多主多从的结构,master用于消息的写入,slave用于推送消息
- 采用多主多从的结构,那么就需要考虑消息同步的问题,有两种方式
- 同步:对比与异步性能略低,消息无延迟
- 异步:对比与同步性能略高,消息有延迟
集群特征
![RocketMQ核心知识_第2张图片](http://img.e-com-net.com/image/info8/5740974623294c238fc6492652fb9fc7.jpg)
角色:producer(生产者)、consumer(消费者)、Broker(MQ)、NameServer(中控中心)
- 所有的服务都会连接到NameServer中
- 建立集群时,哪个Broker是master哪个是slave是根据Broker中的brokerId区分的。borkerId=0说明是master,否则都是slave
- 而集群中又可以存在多主多从的结构,每个master和它的slave都可以看成是一个组,那么这就需要根据Broker中brokerName区分,如果brokerName的值是一样的就在一个组中
- Broker集群中所有的Broker(maseter和slave)都会注册到NameServer中(NameServer也可以是一个集群,但是它们之间互不通信),并建立长连接。Broker和NameServer在进行数据同步的时候,Broker中有一个Topic是一个很重要的信息,需要同步到每一台NameServer中。Topic:消息的大分组,也就是生产者发送消息时分类存储的地方
- 生产者发消息时(会提供一个Topic),首先会连接NameServer,根据Topic找对应的Broker,再从Broker中找到对应的Topic(Topic可以是很多个组,可以理解成是存放消息的管道,每个Topic是一个单独的管道,group则是存放这些管道的空间),然后就可以根据这些信息发送消息了。消费者与NameServer和Broker跟生成者是一样的
集群工作流程
- 先启动NameServer,开启监听,等待broker、producer和consumer连接
- broker启动,根据配置信息,连接到所有的NameServer,并保持一个长连接
- 如果broker中有数据,那么NameServer将会保存topic和broker的关系,因为最终会根据topic找到对应的broker
- producer发消息,会先连接NameServer,并建立长连接。(注意:并不是先连接Broker)
- producer发消息,存在两个情况:topic存在:由NameServer直接分配到对应的broker;topic不存在:由NameServer创建topic与broker的关系,并分配
- producer在broker中的topic选择一个小消息队列(从列表中选择)
- producer与broker建立长连接,用于发消息
- producer最终发送消息
消息的存储
Broker中为什么需要将消息存储起来?
答:防止Borker宕机,产生消息不可用的情况
消息可以存在数据库,但是消息的发送(存储速度)快慢很大程度上就取决于数据库的速度,它快则快,它慢则慢,所以会受到它的限制;而数据库最终存储数据的地方还是文件系统中,也就是硬盘中;所以可以选择将消息直接存入到文件系统中,这样就跨过了数据库,实现了存储。
所以随之而来的问题就是,怎么跨过数据库将消息存入文件系统中呢?
解决:采用消息刷盘机制进行数据存储
顺序写与零拷贝
顺序写:
即使将消息直接存储到硬盘上,也还是会存在IO速度的问题,因为硬盘也分为机械硬盘和固态硬盘,这两者的IO速度差距是很大的,所以会采取固态硬盘进行存储
而固态硬盘存储数据也分为随机写和顺序写
- 随机写:因为硬盘中会存在磁盘碎片,所以消息的存储可能就不是连续的,而是断续的存储
- 顺序写:先占用一片空间,不允许其它业务使用,这样就能保证这一片空间是连续的,那么IO的速度将会大大提升(随机写(100KB/S);顺序写(600MB/S))
所以RocketMQ采用的就是顺序写,它首先会在我们的磁盘空间开辟一个G的空间,这样需要写数据的时候就直接写在里面,大大提高了速度
零拷贝:
数据的传输过程:![RocketMQ核心知识_第3张图片](http://img.e-com-net.com/image/info8/cf8044bb43a8419ab6f276f061c86dfc.jpg)
该过程总共经历了四次拷贝。网卡→内存数据不算拷贝
RocketMQ减少一次数据的拷贝,直接从内核态转为网络驱动内核,中间跳过了用户态;该过程就称为零拷贝技术
实现:java语言中使用MappedByteBuffer类实现了该技术
要求:预留存储空间,用户使用顺序写保存数据(1G存储空间起步)
消息的存储结构
也就是RocketMQ的结构
![RocketMQ核心知识_第4张图片](http://img.e-com-net.com/image/info8/645ca119c9084bbd8d139be2db58691d.jpg)
消息刷盘机制
将MQ的消息写入到磁盘的过程就叫刷盘,有两种方式:同步刷盘,异步刷盘
同步刷盘:
- 生产者发送消息给MQ,MQ接收到消息
- MQ就会挂起生产者发送消息的线程
- MQ将消息数据写入到内存中
- 内存数据写入磁盘中
- 数据写入磁盘完成后给MQ返回ok(SUCCESS)
- MQ接收到状态结果后,就会唤醒在挂起生产者发送消息的线程
- MQ就会将发送结果发给生产者
异步刷盘:
- 生产者发送消息给MQ,MQ接收到消息
- MQ将消息数据写入到内存中
- MQ返回发送结果给生产者
也就是说异步刷盘只有同步刷盘中的1,3,7步,因为将数据从内存写入到磁盘中是异步执行的,不在主流程中,也不需要将发送消息的线程挂起;
好处在于:生产者可以一直发消息,无需等待,当消息达到一定的量级在将数据进行一个异步的写入磁盘中
总结:
同步刷盘:安全性高,效率低,速度慢(使用于对数据安全要求较高的业务中)
异步刷盘:安全性低,效率高,速度快(用于对数据处理速度要求较高的业务中)
MQ高可用与主从复制
高可用
- nameserve: 无状态+全服务注册,也可以搭建集群
- 消息服务器(Broker):主从架构(双主双从)
- 消息生产:生产者将相同的topic绑定到多个group组中,保障master挂掉后,其他的master仍可正常消息接收
- 消息消费:RockerMQ自身会根据master承担消息读取的功能,当master繁忙时,自动切换由slave承担数据读取的工作
主从复制
也就是master数据同步到slave中的过程,分为同步复制和异步复制
同步复制:
- master接收消息后,先复制到slave中,在返回结果给生产者
- 优点:数据安全,不丢失数据,出现故障容易恢复
- 缺点:影响数据的吞吐量,整体性能降低
异步复制:
- master接收消息后,立即将操作成功的结果返回给生产者,当消息达到一定量后在异步复制到slave中
- 优点:数据吞吐量大,操作延迟低,性能高
- 缺点:数据不安全,会出现数据丢失的现象,一但master发生故障,那么从上次数据同步时间到出现故障时间之间的数据将会丢失
如何配置Broker是同步复制还是异步复制?
在下载的rocketmq文件的bin目录下有一个broker.conf配置文件,修改:
brokerRole = ASYNC_MASTER
ASYNC_MASTER:异步;前面不加A表示同步
负载均衡
Producer负载均衡
场景:producer和broker都是集群
如果producer发送多个消息在分别对应borker集群中的broker 是同一个组(group),同一个队列(topic)的话,会将所有的消息顺序的发送broker对应的topic中
Consumer负载均衡
平均分配:将多个broker中的消息平均的分给consumer,如果平均是每个服务两个消息,那么会连续发送两个消息到每个consumer中
比如:有两个broker,broker1有1、2、3三个消息,broker2有4、5、6三个消息 有三个consumer都需要消费这些消息,那么会平均分配消息给consumer
- consumer1就有消息1、2
- consumer2就有消息3、4
- consumer3就有消息5、6
产生的问题:如果提供的broker的集群中有一个broker挂了,那么很有可能有些consumer会消费不到消息
循环平均分配:当broker集群提供消息时,会一条一条的将消息发给每一个consumer就避免了上面出现的问题
![RocketMQ核心知识_第5张图片](http://img.e-com-net.com/image/info8/870bf65eec4e40989af22598f8317adc.jpg)
消息重试
什么是消息重试?
答:当broker推送消息给consumer后,consumer没有返回消费结果将会启动消息重试机制
消息重试机制分为顺序消息和无序消息
顺序消息:
当broker推送消息给consumer时,consumer如果没有返回消费结果,那么就会一直重复发送消息(1秒一次),直到consumer返回结果为止。(注意:如果consumer没有返回消息消费结果,消息是不会删除的)
这样虽然会保证我们的消息会被消费,但是会造成broke中消息的阻塞,前面的消息一直在发,后面的消息发不出去
无序消息:
- 无序消息包括普通消息、定时消息、延时消息、事务消息
- 无序消息重试仅适用于负载均衡(集群)模型下的消息消费,不适用于广播模式下的消费
- 为保障无序消息的消费,MQ设定了合理的消息重试间隔时长
重试间隔时长
![RocketMQ核心知识_第6张图片](http://img.e-com-net.com/image/info8/debc3ada77874077bcd12d90b1e66b82.jpg)
当MQ重试次数达到设置的默认最大次数后consumer还是没有返回结果,那么就会将消息放入MQ中的死信队列,那么消息就会变为死信
死信队列
死信队列特征:
- 存放死信的对列,也就是未被消费的消息;它归属于组(group),而不是topic
- 一个死信队列中可以包含同一个组下的多核Topic中的死信消息
- 死信队列在没有死信的时候是没有的,只有在出现了死信,死信队列才会被创建出来
死信队列中消息特征:
- 死信队列中的消息不会被主动消费,如果真想消费,可以根据消息id强制消费消息
- 死信队列中的消息有效期为3天,达到后会被清除
消息重复消费
也就说broker推送消息给consumer,consumer消费完成后给broker返回成功结果时,broker因为某些原因没有收到consumer返回的结果,那么broker就会在发一次,那么就造成了消息的重复消费
消息重复消费的原因
![RocketMQ核心知识_第7张图片](http://img.e-com-net.com/image/info8/e9efafca3846407f9a2d06614704984f.jpg)
使用消息幂等解决该问题
幂等
- 对同一条消息,无论消费多少次,结果保持一致,称为消息幂等性
- 解决方案
- 使用业务id作为消息的key
- 在消费消息时,客户端对key做判定,未使用过放行,使用过抛弃
- 注意:messageId有RocketMQ产生,messageId并不具有唯一性,不能作用幂等判定条件,所以需要使用业务id
- 常见的幂等方式实例:
- 新增:不幂等 每次添加的数据返回的结果可以是不一致的
- 查询:幂等 必须保证同一个消息每次查询的结果是一致的
- 删除:幂等 删除一条信息返回的结果必须是一致的
- 修改:幂等 修改一条信息的状态为1,那么无论修改多少次,该状态还是要为1
- 修改:不幂等 加钱,每次在原有的基础上加钱,那么每一次操作的结果都会不一样