后面提到了 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 日志文件，因为是异样退出的，所以不晓得在哪里呈现问题，就只能从最初一个开始往前面遍历查找，直至找到正确的文件。