文章目录
- 信息存储与发送
- 顺序写
- mmap "零拷贝"
- 消息存储结构
- ConsumeQueue
- CommitLog
- 概述
- 设计机制
- 高可用性机制
- 同步刷盘和异步刷盘
- 概述
- 详解
- 同步复制和异步复制
- 总结
- 参考
Broker 是RocketMQ 的核心,大部分重量级工作都是由Broker 完成的,包括接收Producer 发过来的消息、处理Consumer 的消费消息请求、消息的持久化存储、消息的HA 机制以及服务端过滤功能等。
信息存储与发送
顺序写
- 高性能磁盘,顺序写速度可以达到
600MB/s
,随机写的速度只有大概100KB/s
- 尽可能顺序写特性,提升速度。
mmap “零拷贝”
- Linux 操作系统分为用户态和内核态,文件操作、网络操作需要涉及这两种形态的切换,免不了进行数据复制,一台服务器把本机磁盘文件的内容发送到客户端一般分为两个步骤:
- read(file, tmp_buf, len) 读取本地文件内容;
- write(socket, tmp_buf, len) 将读取的内容通过网络发送出去。
- tmp_buf 是预先申请的内存,这两个看似简单的操作,实际进行了4 次数据复制,分别是:
- 从磁盘复制数据到内核态内存,
- 从内核态内存复制到用户态内存(read(file, tmp_buf, len))
- 然后从用户态内存复制到网络驱动的内核态内存
- 最后是从网络驱动的内核态内存复制到网卡中进行传输(write(socket, tmp_buf, len))
- 通过使用 mmap 的方式,可以省去向用户态的内存复制,提高速度。
消息存储结构
RocketMQ 消息的存储是由 ConsumeQueue
和CommitLog
配合完成的,消息真正的物理存储文件是CommitLog
, ConsumeQueue
是消息的逻辑队列,类似数据库的索引文件,存储的是指向物理存储的地址。
ConsumeQueue
- 每个Topic 下 的每个MessageQueue 都有一个对应的ConsumeQueue 文件。
- 文件地址在
${storeRoot}/consumequeue/${topicName}/${queueld}/${fileName}
# 配置了 storePathRootDir=/data/soft/install/rocketmq-all-4.3.2/data/store-a (store-b 为另一个主节点的存储路径)
# topic = base_topic
# 4个 queue
/data/soft/install/rocketmq-all-4.3.2/data/store-a/consumequeue/base_topic/0/00000000000000000000
/data/soft/install/rocketmq-all-4.3.2/data/store-b/consumequeue/base_topic/1/00000000000000000000
- ConsumeQueue 存储格式
CommitLog
概述
-
CommitLog
以物理文件的方式存放,每台Broker
上的CommitLog
被本机器所有ConsumeQueue
共享。 - 文件地址:
$ {user.home}/store/commitlog/${fileName}
/home/hadoop/store/commitlog/00000000000000000000
/home/hadoop/store/commitlog/00000000001073741824
设计机制
- 在CommitLog 中,一个消息的存储长度是不固定的, RocketMQ采取一些机制,尽量向CommitLog 中顺序写,但是随机读。ConsumeQueue 的内容也会被写到磁盘里作持久存储。
- 这种机制的好处:
- CommitLog 顺序写,可以大大提高写人效率。
- 虽然是随机读,但是利用操作系统的pagecache 机制,可以批量地从磁盘读取,作为cache 存到内存中,加速后续的读取速度。
- 为了保证完全的顺序写,需要ConsumeQueue 这个中间结构,因为ConsumeQueue 里只存偏移量信息,所以尺寸是有限的,在实际情况中,大部分的ConsumeQueue 能够被全部读人内存,所以这个中间结构的操作速度很快,可以认为是内存读取的速度。
- 为了保证CommitLog 和ConsumeQueue 的一致性, CommitLog 里存储了ConsumeQueues 、Message key、Tag 等所有信息,即使ConsumeQueue 丢失,也可以通过commitLog 完全恢复出来
- 一个Broker 在文件系统中存储的各个文件的列表(配置了
storePathRootDir=/data/soft/install/rocketmq-all-4.3.2/data/store-a
)
|-user.home
| |-logs # 日志
| |-rocketmqlogs
| |-namesrv.log
| |-broker.log
| |-rocketmq_client.log
| |-consolelogs
| |-store # 存储 commitlog
| |-commitlog
|
|-storeRoot
| |-abort
| |-checkpoint
| |-config
| |-topics.json
| |-topics.json.bak
| |-subscriptionGroup.json
| |-consumerOffset.json
| |-consumequeue # 存储 consumequeue
| |-topic_1
| |-0
| |-00000000000000000000
| |-1
| |-topic_2
| |-index
| |-20181226142351721 # index 存的是索引文件,这个文件用来加快消息查询的速度
| |-lock
高可用性机制
- RocketMQ 分布式集群是通过Master 和Slave 的配合达到高可用性的
- Mastrt 与 Slave 角色
- 在Broker 的配置文件中,参数brokerId的值为0 表明这个Broker 是Master;大于0 表明这个Broker 是Slave
- Master 角色的Broker 支持读和写,Slave 角色的Broker 仅支持读
- 自动切换读与消费端的高可用性
- 当Master 不可用或者繁忙的时候,Consumer 会被自动切换到从Slave 读
- 当一个Master 角色的机器出现故障后,Consumer 仍然可以从Slave读取消息,不影响Consumer 程序。这就达到了消费端的高可用性。
- 发送端的高可用性
- 在创建Topic 的时候,把Topic 的多个Message Queue 创建在多个Broker 组上(相同Broker 名称,不同broker Id 的机器组成一个Broker 组,如
brokerName=broker-a、brokerId=0、、brokerId=0
,一组主从) - 这样当一个Broker 组的Master 不可用后,其他组的Master 仍然可用, Producer 仍然可以发送消息
- RocketMQ 目前还不支持把Slave 自动转成Master ,如果机器资源不足,需要把Slave 转成Master ,则要手动停止Slave 角色的Broker ,更改配置文件,用新的配置文件启动Broker
同步刷盘和异步刷盘
概述
- RocketMQ 的持久化消息机制,既保证消息断电后恢复,又可以让存储的消息量超出内存的限制。
- RocketMQ 为了提高性能,会尽可能地保证磁盘的顺序写。而Producer 写人RocketMQ 的时候,有两种写磁盘方式:同步刷盘和异步刷盘。
详解
- 异步刷盘:
- 在返回写成功状态时,消息可能只是被写人了内存的
PAGECACHE
,写操作的返回快,吞吐量大; - 当内存里的消息量积累到一定程度时,统一触发写磁盘动作,快速写人。(类似于HBase)
- 同步刷盘: 在返回写成功状态时,消息已经被写人磁盘。具体流程是:
- 消息写入内存的
PAGECACHE
后,立刻通知刷盘线程刷盘,然后等待刷盘完成 - 刷盘线程执行完成后唤醒等待的线程,返回消息写成功的状态
- 同步刷盘还是异步刷盘,是通过Broker 配置文件里的
flushDiskType
参数设置的,这个参数被配置成SYNC_FLUSH 、ASYNC_FLUSH
中的一个。
同步复制和异步复制
- 如果一个Broker 组有Master 和Slave, 消息需要从Master 复制到Slav巳上,有同步和异步两种复制方式。
- 同步复制方式是 等Master 和Slave 均写成功后才反馈给客户端写成功状态;
- 异步复制方式是 只要Master 写成功即可反馈给客户端写成功状态
- 这两种复制方式各有优劣:
- 在异步复制方式下,系统拥有较低的延迟和较高的吞吐量,但是如果Master 出了故障,有些数据因为没有被写人Slave ,有可能会丢失
- 在同步复制方式下,如果Master 出故障, Slave 上有全部的备份数据,容易恢复,但是同步复制会增大数据写人延迟,降低系统吞吐量
- 同步复制和异步复制是通过Broker 配置文件里的
brokerRole
参数进行设置的,这个参数可以被设置成ASYNC_MASTER、SYNC_MASTER、SLAVE
三个中的一个。
总结
- 实际应用中要结合业务场景,合理设置刷盘方式和主从复制方式,尤其是
SYNC_FLUSH
方式,由于频繁地触发磁盘写动作,会明显降低性能。 - 通常情况下,应该把Master 和Save 配置成异步刷盘方式(
ASYNC_FLUSH
),主从之间配置成同步复制方式(SYNC_MASTER
),这样即使有一台机器出故障, 仍然能保证数据不丢,是个不错的选择
参考