这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
使用场景
例如,针对电商业务线,其业务涉及广泛,如注册、订单、库存、物流等;同时,也会涉及许多业务峰值时刻,如秒杀活动、周年庆、定期特惠等
基本概念
名称 | Kafka | RocketMQ |
---|---|---|
逻辑队列 | Topic | Topic |
消息体 | Message | Message |
标签 | 无 | Tag |
分区 | Partition | ConsumerQueue |
生产者 | Producer | Producer |
生产者集群 | 无 | Producer Group |
消费者 | Consumer | Consumer |
消费者集群 | Consumer Group | Consumer Group |
集群控制器 | Controller | Namesever |
Kafka中的Partition概念在RocketMQ叫做ConsumerQueue
RocketMQ架构
数据流通过Producer发送给Broker集群,再由Consumer进行消费
Broker节点有Master和Slave的概念
NameServer为集群提供轻量级服务发现和路由
存储模型
RocketMQ消息的存储模型,对于一个Broker来说所有的消息会append到一个CommitLog上面,然后按照不同的Queue,重新Dispatch到不同的Consumer中,这样Consumer就可以按照Queue进行拉取消费,但需要注意的是,这里的ConsumerQueue所存储的并不是真实的数据,真实的数据只存在CommitLog中,这里存的仅仅是这个Queue所有消息在CommitLog上面的位置,相当于是这个Queue的一个密集索引。
高级特性-事务场景
在此场景中,正常情况下,这个下单的流程应该是,首先要保证库存足够顺利-1,这个时候再消息队列让其他系统来处理,比如订单系统和商家系统,但是有一点比较重要,库存服务和消息队列必须在同一个事务内,也就是保证事务的基本特性ACID。这里库存记录和往消息队列里发消息是两个事情,需要事务保证的,这样不至于发生,库存已经-1了,但是订单没有增加,或者商家没有收到通知要发货。因此RocketMQ提供事务消息来保证此类场景