RocketMQ 口水话｜青训营笔记

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

本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动” 活动，如果你对我的其他文章感兴趣，可以去我的 专栏 中逛逛看有没有你想要的东西。

• 第 1 篇 - Kitex 口水话
• 第 2 篇 - Hertz 口水话
• 第 3 篇 - 微服务口水话
• 第 4 篇 - Kafka 口水话
• 第 5 篇 - BMQ 口水话
• 第 6 篇 - RecketMQ 口水话
• 第 7 篇 - 数据库口水话
• 第 8 篇 - RDBMS 口水话
• 第 9 篇 - TOS 口水话
• 第 10 篇 - tinyTikTok 环境配置
• 第 11 篇 - tinyTikTok 规范设计
• 第 12 篇 - tinyTikTok 项目管理
• 第 13 篇 - tinyTikTok 认证授权
• 第 14 篇 - tinyTikTok 服务功能
• 第 15 篇 - tinyTikTok 测试分析
• 第 16 篇 - tinyTikTok 项目总结

RocketMQ 的模型

对比一下，可以发现 Producer，Consumer, Broker 这三个部分，Kafka 和 RocketMQ 是一样的， 而 Kafka 中的 Partition 概念 在 RocketMQ 叫做 ConsumerQueue。当然，如果想了解更多内容，指路 官方文档：

Broker 节点还有有 Master 和 Slave 两种状态，用于保障可用性；NameServer 为集群提供轻量级服务发现和路由。老规矩，指路 Master-Slave Automatic Failover Mode：

接着，再来看一下 RocketMQ 的存储模型，先指路 Message Storage and Cleanup：

对于 Broker 来说：

1. 所有的消息的会 append 到一个 CommitLog 上
2. 按照不同的 Queue，重新 Dispatch 到不同的 Consumer 中
3. Consumer 就可以按照 Queue 进行拉取消费。

但需要注意的是，这里的 ConsumerQueue 所存储的并不是真实的数据，真实的数据其实只存在CommitLog 中，ConsumerQueue 存的仅仅是这个 Queue 所有消息在 CommitLog 上面的位置，相当于这个 Queue 的一个密集索引。

RocketMQ 高级特性

事物消息，重试和死信队列，延时队列（晚点补一下

放到最后的话

到这里，便大致介绍完了 3 种 MQ，尽管都是些口水话哈哈哈哈哈，但还是希望你能有所收获。