这是我参与「第五届青训营 」伴学笔记创作活动的第 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提供事务消息来保证此类场景
