RocketMQ4.3.X笔记（7）：消息队列的核心机制 Broker

Broker 是RocketMQ 的核心，大部分重量级工作都是由Broker 完成的，包括接收Producer 发过来的消息、处理Consumer 的消费消息请求、消息的持久化存储、消息的HA 机制以及服务端过滤功能等。

信息存储与发送

顺序写

1. 高性能磁盘，顺序写速度可以达到 600MB/s，随机写的速度只有大概 100KB/s
2. 尽可能顺序写特性，提升速度。

mmap “零拷贝”

1. Linux 操作系统分为用户态和内核态，文件操作、网络操作需要涉及这两种形态的切换，免不了进行数据复制，一台服务器把本机磁盘文件的内容发送到客户端一般分为两个步骤：

• read(file, tmp_buf, len) 读取本地文件内容；
• write(socket, tmp_buf, len) 将读取的内容通过网络发送出去。

2. tmp_buf 是预先申请的内存，这两个看似简单的操作，实际进行了4 次数据复制，分别是：

• 从磁盘复制数据到内核态内存，
• 从内核态内存复制到用户态内存(read(file, tmp_buf, len))
• 然后从用户态内存复制到网络驱动的内核态内存
• 最后是从网络驱动的内核态内存复制到网卡中进行传输(write(socket, tmp_buf, len))

3. 通过使用 mmap 的方式，可以省去向用户态的内存复制，提高速度。

消息存储结构

RocketMQ 消息的存储是由 ConsumeQueue 和CommitLog 配合完成的，消息真正的物理存储文件是CommitLog, ConsumeQueue 是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。

ConsumeQueue

1. 每个Topic 下 的每个MessageQueue 都有一个对应的ConsumeQueue 文件。
2. 文件地址在 ${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

3. ConsumeQueue 存储格式
   

CommitLog

概述

1. CommitLog 以物理文件的方式存放，每台 Broker 上的 CommitLog 被本机器所有 ConsumeQueue 共享。
2. 文件地址：$ {user.home}/store/commitlog/${fileName}

/home/hadoop/store/commitlog/00000000000000000000
/home/hadoop/store/commitlog/00000000001073741824

设计机制

1. 在CommitLog 中，一个消息的存储长度是不固定的， RocketMQ采取一些机制，尽量向CommitLog 中顺序写，但是随机读。ConsumeQueue 的内容也会被写到磁盘里作持久存储。
2. 这种机制的好处：

• CommitLog 顺序写，可以大大提高写人效率。
• 虽然是随机读，但是利用操作系统的pagecache 机制，可以批量地从磁盘读取，作为cache 存到内存中，加速后续的读取速度。
• 为了保证完全的顺序写，需要ConsumeQueue 这个中间结构，因为ConsumeQueue 里只存偏移量信息，所以尺寸是有限的，在实际情况中，大部分的ConsumeQueue 能够被全部读人内存，所以这个中间结构的操作速度很快，可以认为是内存读取的速度。
• 为了保证CommitLog 和ConsumeQueue 的一致性， CommitLog 里存储了ConsumeQueues 、Message key、Tag 等所有信息，即使ConsumeQueue 丢失，也可以通过commitLog 完全恢复出来

3. 一个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                  

高可用性机制

1. RocketMQ 分布式集群是通过Master 和Slave 的配合达到高可用性的
2. Mastrt 与 Slave 角色

• 在Broker 的配置文件中，参数brokerId的值为0 表明这个Broker 是Master；大于0 表明这个Broker 是Slave
• Master 角色的Broker 支持读和写，Slave 角色的Broker 仅支持读

3. 自动切换读与消费端的高可用性

• 当Master 不可用或者繁忙的时候，Consumer 会被自动切换到从Slave 读
• 当一个Master 角色的机器出现故障后，Consumer 仍然可以从Slave读取消息，不影响Consumer 程序。这就达到了消费端的高可用性。

4. 发送端的高可用性

• 在创建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

同步刷盘和异步刷盘

概述

1. RocketMQ 的持久化消息机制，既保证消息断电后恢复，又可以让存储的消息量超出内存的限制。
2. RocketMQ 为了提高性能，会尽可能地保证磁盘的顺序写。而Producer 写人RocketMQ 的时候，有两种写磁盘方式：同步刷盘和异步刷盘。

详解

1. 异步刷盘：

• 在返回写成功状态时，消息可能只是被写人了内存的 PAGECACHE，写操作的返回快，吞吐量大；
• 当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写人。(类似于HBase)

2. 同步刷盘: 在返回写成功状态时，消息已经被写人磁盘。具体流程是：

• 消息写入内存的 PAGECACHE 后，立刻通知刷盘线程刷盘，然后等待刷盘完成
• 刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态

3. 同步刷盘还是异步刷盘，是通过Broker 配置文件里的flushDiskType 参数设置的，这个参数被配置成SYNC_FLUSH 、ASYNC_FLUSH 中的一个。

同步复制和异步复制

1. 如果一个Broker 组有Master 和Slave, 消息需要从Master 复制到Slav巳上，有同步和异步两种复制方式。

• 同步复制方式是 等Master 和Slave 均写成功后才反馈给客户端写成功状态；
• 异步复制方式是 只要Master 写成功即可反馈给客户端写成功状态

2. 这两种复制方式各有优劣：

• 在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master 出了故障，有些数据因为没有被写人Slave ，有可能会丢失
• 在同步复制方式下，如果Master 出故障， Slave 上有全部的备份数据，容易恢复，但是同步复制会增大数据写人延迟，降低系统吞吐量

3. 同步复制和异步复制是通过Broker 配置文件里的brokerRole 参数进行设置的，这个参数可以被设置成ASYNC_MASTER、SYNC_MASTER、SLAVE 三个中的一个。

总结

1. 实际应用中要结合业务场景，合理设置刷盘方式和主从复制方式，尤其是SYNC_FLUSH 方式，由于频繁地触发磁盘写动作，会明显降低性能。
2. 通常情况下，应该把Master 和Save 配置成异步刷盘方式（ASYNC_FLUSH），主从之间配置成同步复制方式（SYNC_MASTER），这样即使有一台机器出故障， 仍然能保证数据不丢，是个不错的选择

参考

1. Apache RocketMQ 官网
2. Best Practice For Broker