本文承接构造IndexWriter对象(六),继续介绍调用IndexWriter的构造函数的流程。
图1:
在文章构造IndexWriter对象(六)中,我们简单介绍了IndexFileDeleter作用,即用来删除索引目录中的索引文件,本文根据IndexFileDeleter的构造函数的实现来介绍关于计数引用、删除无效(Invalid)索引文件的内容。
图2:
点击查看大图
图3:
构造 IndexFileDeleter最重要的一个对象就是SegmentInfos,它是在图1的生成对象IndexFileDeleter
流程点之前通过用户配置的IndexCommit或者索引目录中的旧索引生成的SegmentInfos对象(见构造IndexWriter对象(三)、构造IndexWriter对象(四)、构造IndexWriter对象(五)中关于生成SegmentInfos的介绍),并作为 IndexFileDeleter的构造函数的参数之一。
图4:
构造IndexWriter对象里面调用 IndexFileDeleter的构造函数时,总是能通过SegmentInfos获得一个segments_N的文件名,并且通过下面的方法来获得segments_N的文件名,那么当前流程点的判断结果总是为true,由于该方法可能会返回null,所以在这里会有一个判断。
xxxxxxxxxx
SegmentInfos.getSegmentsFileName()
图5:
接着就是从索引目录依次取出索引文件,然后判断是否满足某个要求。
需要满足什么要求:
先给出该要求对应的代码:
xxxxxxxxxx
if (!fileName.endsWith("write.lock") && (m.matches() || fileName.startsWith(IndexFileNames.SEGMENTS) || fileName.startsWith(IndexFileNames.PENDING_SEGMENTS)){
... ...
}
其中fileName就是待处理的索引文件的文件名、m.matches()描述的是fileName是否满足下面的正则表达式
xxxxxxxxxx
_[a-z0-9]+(_.*)?\\..*
上述的代码进行拆分后即需要满足下面三个字要求之一:
子要求一:!fileName.endsWith("write.lock") && (m.matches()
图6:
子要求二:fileName.startsWith(IndexFileNames.SEGMENTS)
子要求三:fileName.startsWith(IndexFileNames.PENDING_SEGMENTS)
图7:
如果索引文件满足上文中的要求,那么我们初始化这些索引文件的计数引用。
Lucene中如何实现对索引文件的计数引用:
通过一个HashMap对象refCounts以及一个RefCount类实现,他们的定义如下所示:
xxxxxxxxxx
final private static class RefCount {
final String fileName; // 索引文件名
int count; // 计数值
public int IncRef() {
// 增加计数
}
public int DecRef() {
// 减少计数
}
}
// key为索引文件名,value为RefCount对象
private Map<String, RefCount> refCounts = new HashMap<>();
如果我们要增加某个索引文件的计数引用,那么根据refCounts找到该文件对应的RefCount对象,接着通过对象的IncRef()方法来增加计数。
上述的RefCount类的具体内容可以查看这个链接:https://github.com/LuXugang/Lucene-7.5.0/blob/master/solr-7.5.0/lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java 。
图8:
如果是segments_N文件,那么需要对该文件进行额外的处理,判断方法同上文中的子要求二。
图9:
索引目录中可能存在多个segments_N文件,那么这些文件都需要被处理,其中只有一个segments_N对应的SegmentInfos为构造IndexFileDeleter对象的参数,即图2中SegmentInfos
流程点的segmentInfos。
为什么索引目录中会存在多个segments_N文件:
原因主要取决于上一个IndexWriter对象使用了哪种索引删除策略IndexDeletionPolicy(见文档提交之commit(二)关于IndexDeletionPolicy的介绍),比如使用了索引删除策略NoDeletionPolicy,那么每次提交都会保留,又比如使用了默认的索引删除策略KeepOnlyLastCommitDeletionPolicy,那么只会保留最后一次提交。
图10:
在图10中,使用不同的索引删除策略对相同的数据进行索引,在执行了4次commit提交后,对于NODeletetionPolicy来说,它会保留所有的提交,而对于KeepOnlyLastCommitDeletionPolicy,当生成segments_2时,会删除segments_1,生成segments_3时,会删除segments_2,以此类推,即只保留最后一次提交。
为什么要根据每一个segments_N对应的SegmentInfos生成CommitPoint,并且添加到CommitPoint集合commits中:
接着如果某个segments_N对应的SegmentInfos为构造IndexFileDeleter的参数,即图2中SegmentInfos
流程点的SegmentInfos,那么它对应生成的CommitPoint被设置为当前提交点currentCommitPoint,该对象在后面的流程点是否出现异常
会作为条件进行异常判断。
最后我们需要增加每一个segments_N对应的SegmentInfos中对应的索引文件的计数引用,其原因是在后面的流程中能判断能否能删除索引文件。
图11:
这里考虑的异常是使用NFS(Network File System)网络文件系统的场景,使用该文件系统可能会导致下面的情况:我们能通过构造IndexFileDeleter的参数获得SegmentInfos对象,并且通过SegmentInfos获得segments_N的文件名(注意只是文件名),那么segments_N文件必定是在索引目录中(见构造IndexWriter对象(五)/构造IndexWriter对象(四)/构造IndexWriter对象(三)不同的打开模式OpenMode的内容),但是我们在图9的流程中,如果没有读取到segments_N文件(通过是否获得currentCommitPoint对象来判断),那么有可能就是NFS导致的,例如目录缓存机制的影响,那么可以根据segment_N文件名,通过重试机制来获得它对应的SegmentInfos对象,并且生成currentCommitPoint对象,如果还是读取不到,那么就会抛出下面的异常:
xxxxxxxxxx
throw new CorruptIndexException("unable to read current segments_N file", currentSegmentsFile, e);
基于篇幅,剩余的内容将在下一篇文章中展开。
点击下载附件