rocketmq刷盘过程
本文基于rocketmq4.0版本，结合CommitlLog的刷盘过程，对消息队列的刷盘过程源码进行分析，进而对RocketMQ的刷盘原理和过程进行了解。
rocketmq 4.0版本中刷盘类型和以前的版本一样有两种：
public enum FlushDiskType {
// 同步刷盘
SYNC_FLUSH,
// 异步刷盘
ASYNC_FLUSH
}
刷盘方式有三种：
| 线程服务 | 场景 | 写消息性能 |
| CommitRealTimeService | 异步刷盘 && 开启内存字节缓冲区 | 第一 |
| FlushRealTimeService | 异步刷盘 | 第二 |
| GroupCommitService | 同步刷盘 | 第三 |
其中CommitRealTimeService是老一些版本中没有的，它为开启内存字节缓存的刷盘服务。
介绍各个线程工作之前，先需要重点了解一下waitForRunning方法，因为在三个刷盘服务线程中都频繁使用该方法：
protected void waitForRunning(long interval) {
if (hasNotified.compareAndSet(true, false)) {
this.onWaitEnd();
return;
}
//entry to wait
waitPoint.reset();
try {
waitPoint.await(interval, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
log.error("Interrupted", e);
} finally {
hasNotified.set(false);
this.onWaitEnd();
}
}
这里要注意一下 waitPoint 这个共享变量，它是CountDownLatch2类型，，没有细看CountDownLatch2的原理，猜测它和CountDownLatch类似，根据CountDownLatch的使用原理，大致可以猜测waitPoint的作用。
回顾一下CountDownLatch相关知识：
CountDownLatch能够使一个线程等待其他线程完成各自的工作后再执行自己的任务，CountDownLatch是通过一个计数器来实现的，计数器的初始值为需要等待的线程的数量。每当一个线程完成了自己的任务后，计数器的值就会减1。当计数器值到达0时，它表示所有的线程已经完成了任务，然后在闭锁上等待的线程就可以恢复执行任务。
因此，可以猜测waitForRunning的业务逻辑大致为：
(1). 通过闭锁没执行依次waitPoint.countDown()，当计数器值到达0时，结束阻塞状态，开始执行等待线程的任务；
(2). 等待一定时间之后，结束阻塞状态，开始执行等待线程的任务。
在rocketmq4.0版本中，调用了waitPoint.countDown()的地方有三处：
shutdown（） stop（） wakeup（）
这里我们关心的是wakeup()方法，调用wakeup方法的几处如下
其中与commitLog刷盘相关的有：
service.wakeup()、flushCommitLogService.wakeup()、commitLogService.wakeup()，其中service.wakeup()的service是GroupCommitService类型。
由此引入了本文所要讲述的FlushRealTimeService、CommitRealTimeService以及GroupCommitService三个线程刷盘服务。
GroupCommitService
broker启动后，会启动许多服务线程，包括刷盘服务线程，如果刷盘服务线程类型是SYNC_FLUSH （同步刷盘类型：对写入的数据同步刷盘，只在broker==master时使用），则开启GroupCommitService服务，该服务线程启动后每隔10毫秒或该线程调用了wakeup()方法后停止阻塞，执行doCommit()方法。doCommit里面执行具体的刷盘逻辑业务。GroupCommitService服务线程体如下：
public void run() {
CommitLog.log.info(this.getServiceName() + " service started");
while (!this.isStopped()) {
try {
this.waitForRunning(10);
this.doCommit();
} catch (Exception e) {
CommitLog.log.warn(this.getServiceName() + " service has exception. ", e);
}
}
// Under normal circumstances shutdown, wait for the arrival of the
// request, and then flush
try {
Thread.sleep(10);
} catch (InterruptedException e) {
CommitLog.log.warn("GroupCommitService Exception, ", e);
}
synchronized (this) {
this.swapRequests();
}
this.doCommit();
CommitLog.log.info(this.getServiceName() + " service end");
}
当broker类型为master时，每写入一条消息成功写入mapedFile文件后，调用handleDiskFlush方法，如果该消息满足messageExt.isWaitStoreMsgOK()，则将这一条成功写入的消息生成GroupCommitRequest对象，将该对像放入GroupCommitService的requestsWrite列表中（List<GroupCommitRequest>），等待刷盘线程调用doCommit，对列表中的消息进行刷盘，doCommit中每对一个request处理完成后，会调用wakeupCustomer。等待时间5s后或者request的countDownLatch记数为0时，则将这条消息是否已经刷盘成功进行汇报，如果没有刷盘成功，则再日志中记录错误，并将putMessageResult设置为FLUSH_DISK_TIMEOUT。代码如下：
if (FlushDiskType.SYNC_FLUSH == this.defaultMessageStore.getMessageStoreConfig().getFlushDiskType()) {
final GroupCommitService service = (GroupCommitService) this.flushCommitLogService;
if (messageExt.isWaitStoreMsgOK()) {
GroupCommitRequest request = new GroupCommitRequest(result.getWroteOffset() + result.getWroteBytes());
service.putRequest(request);
boolean flushOK = request.waitForFlush(this.defaultMessageStore.getMessageStoreConfig().getSyncFlushTimeout());
if (!flushOK) {
log.error("do groupcommit, wait for flush failed, topic: " + messageExt.getTopic() + " tags: " + messageExt.getTags()
+ " client address: " + messageExt.getBornHostString());
putMessageResult.setPutMessageStatus(PutMessageStatus.FLUSH_DISK_TIMEOUT);
}
} else {
service.wakeup();
}
}
这条消息是否已经刷盘成功进行汇报的逻辑 -- waitForFlush方法：
public static class GroupCommitRequest {
private final long nextOffset;
private final CountDownLatch countDownLatch = new CountDownLatch(1);
private volatile boolean flushOK = false;
public GroupCommitRequest(long nextOffset) {
this.nextOffset = nextOffset;
}
public long getNextOffset() {
return nextOffset;
}
public void wakeupCustomer(final boolean flushOK) {
this.flushOK = flushOK;
this.countDownLatch.countDown();
}
public boolean waitForFlush(long timeout) {
try {
// 阻塞当前工作线程，等待时间5s后或者countDownLatch记数为0时，停止阻塞，执行下一条语句
this.countDownLatch.await(timeout, TimeUnit.MILLISECONDS);
return this.flushOK;
} catch (InterruptedException e) {
log.error("Interrupted", e);
return false;
}
}
}
对GroupCommitRequest类中的两个方法的说明：
在waitForFlush方法阻塞的时候，doCommit方法对写入requestsWrite列表中（List<GroupCommitRequest>）所有GroupCommitRequest对象依次进行了 wakeupCustomer方法调用，wakeupCustomer调用后，countDownLatch 闭锁记数减一，等待时间5s后或者countDownLatch记数为0时，返回调用wakeupCustomer的GroupCommitRequest对应的消息的刷盘结果。
GroupCommitService的doCommit方法：
说明一下：分析doCommit方法之前，先提及一下swapRequests这个方法，之前提过，GroupCommitService服务线程该每隔10毫秒或调用了该线程的wakeup()方法后执行doCommit()方法，具体地要涉及到waitForRunning方法，waitForRunning方法中onWaitEnd的作用在这里就可以提及一下了，它的作用就是将requestsWrite 转换为requestsRead ，这个与消息存储过程中处理dispatchRequest是类似的。
private void swapRequests() {
List<GroupCommitRequest> tmp = this.requestsWrite;
this.requestsWrite = this.requestsRead;
this.requestsRead = tmp;
}
doCommit代码：
private void doCommit() {
//
synchronized (this.requestsRead) {
if (!this.requestsRead.isEmpty()) {
for (GroupCommitRequest req : this.requestsRead) {
// There may be a message in the next file, so a maximum of
// two times the flush
boolean flushOK = false;
for (int i = 0; i < 2 && !flushOK; i++) {
flushOK = CommitLog.this.mappedFileQueue.getFlushedWhere() >= req.getNextOffset();
if (!flushOK) {
CommitLog.this.mappedFileQueue.flush(0);
}
}
req.wakeupCustomer(flushOK);
}
long storeTimestamp = CommitLog.this.mappedFileQueue.getStoreTimestamp();
if (storeTimestamp > 0) {
CommitLog.this.defaultMessageStore.getStoreCheckpoint().setPhysicMsgTimestamp(storeTimestamp);
}
this.requestsRead.clear();
} else {
// Because of individual messages is set to not sync flush, it
// will come to this process
CommitLog.this.mappedFileQueue.flush(0);
}
}
}
其中，具体的刷盘核心代码：CommitLog.this.mappedFileQueue.flush(0); 接下来看其他两个刷盘服务线程，对CommitLog.this.mappedFileQueue.flush(0)下文将具体讲解。
FlushRealTimeService
// 刷新策略(默认是实时刷盘)
flushCommitLogTimed
// 刷盘时间间隔(默认0.5s）
interval = flushIntervalCommitLog
// 每次刷盘至少需要多少个page(默认是4个)
flushPhysicQueueLeastPages
// 彻底刷盘间隔时间（默认10s）
flushPhysicQueueThoroughInterval
大致逻辑：
-- 如果 当前时间 >（最后一次刷盘时间 + 彻底刷盘间隔时间（10s）），则将最新一次刷盘时间更新为当前时间
-- 如果是实时刷盘，每隔一定时间间隔，该线程休眠500毫秒
如果不是实时刷盘，则调用waitForRunning，即每隔500毫秒或该刷盘服务线程调用了wakeup（）方法之后结束阻塞。
-- 调用 CommitLog.this.mappedFileQueue.flush(flushPhysicQueueLeastPages);
CommitRealTimeService
CommitRealTimeService 比较特殊，它会包含提交和异步刷盘逻辑，专门为开启内存字节缓冲区的刷盘服务。
// 提交到FileChannel的时间间隔，只在TransientStorePool 打开的情况下使用，默认0.2s
interva l= commitIntervalCommitLog
//每次提交到File至少需要多少个page(默认是4个)
commitDataLeastPages = commitCommitLogLeastPages
/ 提交完成间隔时间（默认0.2s）
commitDataThoroughInterval
大致逻辑：
如果 当前时间 >（最后一次提交时间 + 提交完成间隔时间），更新lastCommitTimestamp之后，执行提交的核心逻辑：
boolean result = CommitLog.this.mappedFileQueue.commit(commitDataLeastPages);
如果result == false 则意味着有新的数据 committed，此时需要wakeup刷盘线程，即：
flushCommitLogService.wakeup(); 进行异步刷盘处理。
可知道，刷盘的下一层核心逻辑：
mappedFileQueue.flush
mappedFileQueue.commit
flush
public boolean flush(final int flushLeastPages) {
boolean result = true;
MappedFile mappedFile = this.findMappedFileByOffset(this.flushedWhere, false);
if (mappedFile != null) {
long tmpTimeStamp = mappedFile.getStoreTimestamp();
int offset = mappedFile.flush(flushLeastPages);
long where = mappedFile.getFileFromOffset() + offset;
result = where == this.flushedWhere;
this.flushedWhere = where;
if (0 == flushLeastPages) {
this.storeTimestamp = tmpTimeStamp;
}
}
return result;
}
commit
public boolean commit(final int commitLeastPages) {
boolean result = true;
MappedFile mappedFile = this.findMappedFileByOffset(this.committedWhere, false);
if (mappedFile != null) {
int offset = mappedFile.commit(commitLeastPages);
long where = mappedFile.getFileFromOffset() + offset;
result = where == this.committedWhere;
this.committedWhere = where;
}
return result;
}
从上代码可以看出，刷盘过程与MappedFile有很大关系，通过findMappedFileByOffset方法找到要刷盘的MappedFile，然后MappedFile中采用数据刷盘技术将数据刷入到磁盘
MappedFile的刷盘方式有两种：
1. 写入内存字节缓冲区(writeBuffer) ----> 从内存字节缓冲区(write buffer)提交(commit)到文件通道(fileChannel) ----> 文件通道(fileChannel)flush到磁盘
2.写入映射文件字节缓冲区(mappedByteBuffer) ----> 映射文件字节缓冲区(mappedByteBuffer)flush
(MappedFile的刷盘方式待具体分析，待补充...)
