RocketMQ 是什么
- 它是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点
- Producer、Consumer、队列都可以分布式
- Producer 向一些队列轮流发送消息
- 队列集合称为 Topic
- Consumer 如果做广播消费
- 则一个 consumer 实例消费这个 Topic 对应的所有队列
- 如果做集群消费，则多个 Consumer 实例平均消费这个 topic 对应的队列集合
- 能够保证严格的消息顺序
- 提供丰富的消息拉叏模式
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
- 较少的依赖
部署结构
1 ) 物理部署结构
上图是 RocketMQ 网络部署特点
- Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步
- Broker 部署相对复杂
- Broker 分为 Master 与 Slave，一个 Master 可以对应多个 Slave
- 但是一个 Slave 只能对应一个 Master
- Master 与 Slave 的对应关系通过指定相同的 BrokerName
- 不同的 BrokerId 来定义 BrokerId 为 0 表示 Master，非 0 表示 Slave
- Master 也可以部署多个，每个 Broker 与 Name Server 集群中的所有节点建立长连接
- 定时注册 Topic 信息到所有 Name Server
- Producer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接
- 定期从 Name Server 取 Topic 路由信息
- 并向提供 Topic 服务的 Master 建立长连接
- 且定时向 Master 发送心跳，Producer 完全无状态，可集群部署
- Consumer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接
- 定期从 Name Server 取 Topic 路由信息
- 并向提供 Topic 服务的 Master、Slave 建立长连接
- 且定时向 Master、Slave 发送心跳
- Consumer 既可以从 Master 订阅消息
- 也可以从 Slave 订阅消息，订阅规则由 Broker 配置决定
2 ) 逻辑部署结构
- Producer Group
- 用来表示一个发送消息应用，一个 Producer Group 下包含多个 Producer 实例
- 可以是多台机器，也可以是一台机器的多个进程，或者一个进程的多个 Producer 对象
- 一个 Producer Group 可以发送多个 Topic消息，Producer Group 作用如下：
- 1.标识一类 Producer
- 2.可以通过运维工具查询这个发送消息应用下有多个 Producer 实例
- 3.发送分布式事务消息时，如果 Producer 中途意外宕机
- Broker 会主动回调 Producer Group 内的任意
- 一台机器来确认事务状态
- Consumer Group
- 用来表示一个消费消息应用，一个 Consumer Group 下包含多个 Consumer 实例
- 可以是多台机器，也可以是多个进程，或者是一个进程的多个 Consumer 对象
- 一个 Consumer Group 下的多个 Consumer 以均摊方式消费消息
- 如果设置为广播方式，这个 Consumer Group 下的每个实例都消费全量数据
RocketMQ 存储特点
1 ）零拷贝原理
Consumer 消费消息过程，使用了零拷贝，零拷贝包含以下两种方式
1. 使用 mmap + write 方式
- 优点：即使频繁调用，使用小块文件传输，效率也很高
- 缺点：不能很好的利用 DMA 方式，会比 sendfile 多消耗 CPU，内存安全性控制复杂，需要避免 JVM Crash 问题
2. 使用 sendfile 方式
- 优点：可以利用 DMA 方式，消耗 CPU 较少，大块文件传输效率高，无内存安全新问题
- 缺点：小块文件效率低于 mmap 方式，只能是 BIO 方式传输，不能使用 NIO
RocketMQ 选择了第一种方式，mmap+write 方式，因为有小块数据传输的需求，效果会比 sendfile 更好
关于 Zero Copy 的更详细介绍，参考：https://www.linuxjournal.com/article/6345
2 ）文件系统
- RocketMQ 选择 Linux Ext4 文件系统，原因如下：Ext4 文件系统删除 1G 大小的文件通常耗时小于 50ms，而 Ext3 文件系统耗时约 1s 左史，且删除文件时，磁盘IO 压力极大，会导致 IO 写入超时
- 文件系统局面需要做以下调优措施
- 文件系统 IO 调度算法需要调整为 deadline，因为 deadline 算法在随机读情况下，可以合并读请求为顺序跳跃方式，从而提高读 IO 吞吐量
- Ext4 文件系统有以下 Bug，请注意
3 ）数据存储结构
4 ） 存储目录结构
|-- abort
|-- checkpoint
|-- config
| |-- consumerOffset.json
| |-- consumerOffset.json.bak
| |-- delayOffset.json
| |-- delayOffset.json.bak
| |-- subscriptionGroup.json
| |-- subscriptionGroup.json.bak
| |-- topics.json
| `-- topics.json.bak
|-- commitlog
| |-- 00000003384434229248
| |-- 00000003385507971072
| `-- 00000003386581712896
`-- consumequeue|-- %DLQ%ConsumerGroupA| `-- 0| `-- 00000000000006000000|-- %RETRY%ConsumerGroupA| `-- 0| `-- 00000000000000000000|-- %RETRY%ConsumerGroupB| `-- 0| `-- 00000000000000000000|-- SCHEDULE_TOPIC_XXXX| |-- 2| | `-- 00000000000006000000| |-- 3| | `-- 00000000000006000000|-- TopicA| |-- 0| | |-- 00000000002604000000| | |-- 00000000002610000000| | `-- 00000000002616000000| |-- 1| | |-- 00000000002610000000| | `-- 00000000002616000000|-- TopicB| |-- 0| | `-- 00000000000732000000| |-- 1| | `-- 00000000000732000000| |-- 2| | `-- 00000000000732000000
