消息队列 RocketMQ | 青训营笔记

28 阅读2分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天

使用场景

例如,针对电商业务线,其业务涉及广泛,如注册、订单、库存、物流等;同时,也会涉及许多业务峰值时刻,如秒杀活动、周年庆、定期特惠等

基本概念

名称KafkaRocketMQ
逻辑队列TopicTopic
消息体MessageMessage
标签Tag
分区PartitionConsumerQueue
生产者ProducerProducer
生产者集群Producer Group
消费者ConsumerConsumer
消费者集群Consumer GroupConsumer Group
集群控制器ControllerNamesever

Kafka中的Partition概念在RocketMQ叫做ConsumerQueue

RocketMQ架构

2.jpg

数据流通过Producer发送给Broker集群,再由Consumer进行消费

Broker节点有Master和Slave的概念

NameServer为集群提供轻量级服务发现和路由

存储模型

3.jpg

RocketMQ消息的存储模型,对于一个Broker来说所有的消息会append到一个CommitLog上面,然后按照不同的Queue,重新Dispatch到不同的Consumer中,这样Consumer就可以按照Queue进行拉取消费,但需要注意的是,这里的ConsumerQueue所存储的并不是真实的数据,真实的数据只存在CommitLog中,这里存的仅仅是这个Queue所有消息在CommitLog上面的位置,相当于是这个Queue的一个密集索引。

高级特性-事务场景

4.jpg

在此场景中,正常情况下,这个下单的流程应该是,首先要保证库存足够顺利-1,这个时候再消息队列让其他系统来处理,比如订单系统和商家系统,但是有一点比较重要,库存服务和消息队列必须在同一个事务内,也就是保证事务的基本特性ACID。这里库存记录和往消息队列里发消息是两个事情,需要事务保证的,这样不至于发生,库存已经-1了,但是订单没有增加,或者商家没有收到通知要发货。因此RocketMQ提供事务消息来保证此类场景

高级特性-事务消息

5.jpg

高级特性-延迟消息

6.jpg

高级特性-消费重试和死信队列

7.jpg