这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
RocketMQ基本概念
相较于Kafka，RocketMQ新增了 Tag 和 Produce Group
- 队列（queue） ：一个 topic 可以有很多队列，默认是一个 topic 在同一个 Broker 组中是4个。如果一个 topic 现在在2个 Broker 组中，那么就有可能有8个队列。
RocketMQ的工作流程
数据流也是通过Producer发送给Broker集群，再由Consumeri进行消费。Broker节点中存在Master和Slave的概念。NameServer为集群提供轻量级服务发现和路由。
消息发送
- 生产者产生消息
- 生产者在发送消息之前会拉取 topic 的路由信息
- 根据队列选择算法，从 topic 众多的队列中选择一个队列
- 跟队列所在的 Broker 机器建立网络连接，将消息发送到 Broker 上
消息存储
- Broker接收到生产者的消息将消息存到CommitLog中
- 在CosumeQueue中存储这条消息在CommitLog中的位置
通过零拷贝技术实现高性能读写
消息消费
- 消费者会拉取订阅的 Topic 的路由信息
- 与队列所在的机器建立连接，向 Broker 发送拉取消息的请求
- Broker在接收到请求，找到队列对应的 ConsumeQueue，然后计算出拉取消息的位置，再解析出消息在 CommitLog 中的位置
- 从 CommitLog 中读出消息的内容返回给消费者
RocketMQ的存储模型
RocketMQ消息的存储模型，对于Broker来说所有的消息的会发送到一个 CommitLog 上面，然后按照不同的 Queue,重新发送到到不同 Consumer 中，这样 Consumer 就可以按照 Queue 进行拉取消费。
但需要注意的是，这里的 ConsumerQueue 所存储的并不是真实的数据，真实的数据其实只存在CommitLog 中，这里存的仅仅是这个 Queue 所有消息在 CommitLog 上面的位置，相当于是这个 Queue 的一个 密集索引
