基于电商场景的高并发RocketMQ实战-Broker写入读取流程性能优化总结、Broker基于Pull模式的主从复制原理

【11来了】文章导读地址：点击查看文章导读！

Broker 写入读取流程性能优化总结

Broker 的物理存储结构主要是为了优化三个方面：写入、存储、读取

写入优化：

1. 将消息数据写入到 Commitlog 中默认就是写入到了操作系统的 page cache 中，通过 mapped file 机制来实现，将磁盘文件 Commitlog 映射成一块内存区域，将数据写入到内存的 page cache 中就算写入完成了，等待后台线程将内存数据 异步刷入磁盘 即可，这种情况下只有 Broker 所在的机器宕机了，才会导致几百毫秒内的内存数据丢失，这种概率是很小的
2. Broker 存储数据是主要有三个结构的：Commitlog、ConsumeQueue、IndexFile，可参考文章，数据写入到 Commitlog 中的速度是很快的，再通过 异步 将 Commitlog 中的数据建立成索引写入到 ConsumeQueue、IndexFile，这个过程是异步，对写消息流程没有性能影响，即使写入到 ConsumeQueue、IndexFile 的过程中宕机了，只要 Commitlog 文件还在，Broker 重启之后，就会继续向 ConsumeQueue、IndexFile 中写入索引

存储结构：

1. ConsumeQueue 存储结构经过了极大的优化设计的。每个消息在 ConsumeQueue 中存储的都是 定长的 20B ，每个 ConsumeQueue 文件可以存储 30w 个消息
2. Commitlog 存储结构也是精心设计，每个文件 默认 1GB ，满了之后就存下一个文件，避免了某个文件过大，并且每一条消息在所有的 Commitlog 中 记录了有偏移量 ，Commielog 的文件名就是这个文件第一条消息的总物理偏移量

读取优化：

1. 根据消息逻辑偏移量，来定位到 ConsumeQueue 的磁盘文件，在磁盘文件里就可以根据 逻辑偏移量 计算出 物理偏移量 ，可以直接定位到消息在 Commitlog 中的物理偏移量，通过两次定位就可以读取出数据
2. 通过 transiendStorePoolEnabled 机制 解决了高并发读写场景下的 Broker busy 问题，实现了读写分离

Broker 基于 Pull 模式的主从复制原理

Broker 主从复制基于 Pull 模式实现的，即生产者将数据写入到 Broker 主节点之后，等待 Slave 向 Master 发送请求，主动拉取数据

Broker 的从节点需要拉取数据时，会向主节点发送请求建立连接，当建立连接之后，在主节点会建立一个 HAConnection 的数据结构，用于将与从节点之间的连接抽象出来，而在从节点会创建两个 HAClient，一个是主从请求线程，另一个是主从响应线程，HAClient 是从节点的核心类，负责与主节点创建连接与数据交互

那么当从节点向主节点发送连接建立，建立好连接之后，Slave 会向 Master 发送一个最大偏移量 Max Offset，那么主节点根据这个 Offset 偏移量去磁盘文件中读取数据，并将数据发送到 Slave，Slave 进行数据的保存，总体流程如下图：