RocketMQ存储系统概要设计和源码解读

下图为CommitLog结构：MappedFile（真实的映射文件）组成MappedQueue构成

存储消息CommitLog.putMessage()

获取最近一个CommitLog的内存映射文件（零拷贝）
- MappedFileQueue.getLastMappedFile()：从其维护的列表中获取最后一个，因为之前的都已经写满了
- MappedFileQueue.load()：构建一个MappedFile，加入到列表中
如果最近的CommitLog文件写满了或者broker刚启动，mappedfile是空的，创建一个新的
- MappedFileQueue.getLastMappedFile(create:true)
- 计算要创建的CommitLog的起始偏移量(即映射文件的名)
- allocateMappedFileService.putRequestAndReturnMappedFile()创建两个映射文件，但其实只要创建好第一个就返回了；
  - 两种创建MappedFile方式（内存映射）：堆外内存池，直接创建TODO
  - 创建好后，对当前映射文件进行预热MappedFile.warmMappedFile：

1. 1. 对当前映射文件的每个内存页写入一个字节ByteBuffer，当刷盘策略为同步刷盘时，执行强制刷盘，每修改pages个分页刷一次盘；
  2. 因为对每个Mappedfile写入假字节的时候是通过循环的形式，而写入次数为MappedFile.size(1024M) / pagesize(4k)，这样占有CPU的时间太久，所以线程会主动休眠，进入就绪状态，释放CPU
  3. MappedFile.mlock()将当前映射文件全部的地址空间锁定在物理存储中，防止被交换到swap空间

把broker内部的这个message刷新到Mappedfile的内存中mappedFile.appendMessage(msg, this.appendMessageCallback)，有以下两种方式
- 直接将数据写到映射文件字节缓冲区mappedByteBuffer，后mappedByteBuffer.flush()
- 先写到内存字节缓冲区writeBuffer，再从writeBuffer提交commit到文件通道FileChannel，后FileChannel.flush()
刷盘：handleDiskFlush()
- 同步刷盘GroupCommitService：将刷盘请求放入执行线程维护的请求队列中，超时时间内等待执行
- 异步刷盘CommitRealTimeService/FlushCommitLogService：TODO
主从同步：handleHA()
- sync_master：HAService将刷盘请求放入GroupTransferService维护的写请求列表中

下图为CommitLog存储消息的流程：

是消息存储的索引文件：内存存储以topic(目录)/队列id(目录)/MappedFile.....

从CommitLog中拿到message

CommitLog写入message的时候，异步构建consumerqueue存储消息索引提供消费者消费

当topic数量增多时，kafka的单个broker的TPS降低了1个数量级，而RocketMQ在海量topic的场景下，依然保持较高的TPS？

CommitLog的”随机读”对性能的影响