深入浅出 jackrabbit 十 redolog 和 recovery.docx

5 将这次新增的PersistentIndex加入到redolog。并将redolog的数据加刷到磁盘

6或提交事务（之所以”或”，是因为每次新建目录不一定提交事务，因为一个事务中是可以创建多个目录的），将新增的node索引请求记录到redolog，并将redolog的数据刷到磁盘

7 或进入flush，将indexes在内存中的数据刷到磁盘上。

8 在flush中clear redolog

如果我们将第5，6步去掉，那么在4和7步之间当机，那么新增的这个目录则不会记录在indexes对应的文件中，应用程序则不知道这个目录的存在。这个目录就变成了一个没爹没娘的孩子了。(当然，如果我们加上第5步，那么在4-5直接crash，还是有可能产生孤子目录.不过这样的几率非常小，因为4-5之间几乎没有什么逻辑，但是5-8的步骤中存在很多逻辑，相对来讲crash的可能性大很多)

而如果假设，存在第5步，在5和8之间出现了crash，那么显然，indexes对应在磁盘上的文件中是会有这个新的 PersistentIndex所对应的目录存在的。那么这个时候当机也不要紧，redolog重做的时候会找到错误的目录，然后将这个错误的目录销毁。事实上，一次MultiIndex#update方法调用的过程中，假设传进来500个nodeid，那么其实在这次操作中，磁盘上会多出5个目录来（默认的minimergefactor=100），那么一旦第四次出错，导致事务不完整，但是前面4个目录就变成了脏目录了。那么在重启应用的时候应该把这个不完整事务带来的脏目录都删除掉。

讲完redolog的作用，存储类型以及和indexes直接的关系之后，我们来看看如何利用这个redolog进行recovery。

Recovery的逻辑集中在Recovery这个类中，在MultiIndex被创建的时候，会先新建这个类，然后通过读取redolog文件的方式来进行之前当机的recovery操作。其主要逻辑在Recovery#run方法中。