后面提到了ConsumeQueue和IndexFile是通过ReputMessageService线程异步同步commitlog日志文件信息的，如果Commitlog日志文件写入胜利后，Broker宕机，那就没方法进行同步了，导致Commitlog、ConsumeQueue、IndexFile文件数据不统一。那RocketMQ是怎么解决的呢？

stroe目录下的有一个文件，叫abort。

这个abort文件，在Broker启动的时候，会创立，如果是失常退出的话，那就会销毁。

所以失常状况下，abort文件只会存在运行期，进行的时候，是没有这个文件的。

当Broker启动的时候，如果没有abort文件，阐明是失常退出。如果发现存在abort文件，那就是之前是异样退出的，可能Commitlog、ConsumeQueue、IndexFile文件呈现数据不统一的状况，此时就须要进行修数。

stroe目录下的还有一个文件，叫checkpoint（同abort图），存储着Commitlog文件刷盘工夫点、ConsumeQueue文件刷盘工夫点、IndexFile文件刷盘工夫点，这些信息用于异样退出时的判断解决。

加载IndexFile的时候，如果是异样退出，IndexFile文件刷盘工夫点小于该索引文件最大的音讯工夫戳该文件将立刻销毁。

对于ConsumeQueue文件来说，文件复原机制又分为异样进行、失常进行。异样进行就是用abort文件来判断。

如果是失常进行，从倒数第三个开始复原，有余三个的，间接第一个遍历，找到以后Commitlog日志文件的刷新指针和提交指针，并删除ConsumeQueue文件中这个指针后的所有文件。

剩下的就是通过偏移量，通过转发音讯复原ConsumeQueue文件和IndexFile文件的内容，这个步骤同上一篇。

假如有4个Commitlog日志文件，倒数第三个就是2，而后从2开始查找。因为是失常进行的，所以预留3个Commitlog日志文件来校验是不会出问题的。

如果是异样进行，间接读取最初一个文件，而后向前遍历到第一个正确存储的文件，剩下的步骤就和失常进行的差不多。

同样假如是4个Commitlog日志文件，因为是异样退出的，所以不晓得在哪里呈现问题，就只能从最初一个开始往前面遍历查找，直至找到正确的文件。