qq276726581的博客

以下面的一个demo例子来分析一下，探索RocketMQ事务消息原理。通过上述例子的输出结果可以发现，checkLocalTransaction中queueOffset、msgId都发生的变化。那么在broker中到底发生了什么呢。

最近排查线上线上业务时，发现有丢消息的情况。线上通过traceId查询相关日志后发现MQProducer报了如下错误通过翻阅RocketMQ代码，定位在BrokerFastFailure中Os PageCache busy，判断操作系统PageCache是否繁忙，如果忙，则返回true。想必看到这里大家肯定与我一样好奇，RocketMQ是如何判断pageCache是否繁忙呢？下面会重点分析。

答：从上述代码可以发现commit流程是独立的，又要有半数follower写入成功就算append成功了。在删除server2的StoreBaseDir后模拟消息数据被删除，触发同步。客户端请求写入消息时是Append成功就返回，还是要等待Commit才返回？定时会触发persistCheckPoint，保存checkpoint文件。EntryDispatcher.doWork继续工作时为APPEND状态。在EntryDispatcher代码中有如下状态转换。checkpoint文件格式。

当然dataFileList里写入的时候由于每个消息的大小不一样，所以在通过index的方式查询的时候只能一个个消息的遍历。为了提升查询的速度要需要使用到indexFileList，记录了每一个消息在dataFileList中的index和消息size，每一个indexBuffer的长度都是固定的，由magic(4)+pos(8)+size(4)+index(8)+term(8)共32个字节组成。方法里isPendingFull判断当前等待同步到peer的消息数是不是过多，默认是10000个。

DefaultMmapFile中使用wrotePosition来记录buffer的写入位置，同时WROTE_POSITION_UPDATER.addAndGet更新wrotePosition当前位置。那这个就是一样的过程了，必须先把数据写入到用户进程空间里去，然后从这里再进入内核空间，最后进入磁盘文件里去。读取数据时，获取wrotePosition判断读取的位置是否大于写入位置，大于写入位置则返回null。普通的IO操作的一个弊端，必然涉及到两次数据拷贝操作，对磁盘读写性能是有影响的。