我们从文本提取的逻辑中走出来,回到主体流程。
在前面的文章中,我们可以看到一次索引创建的操作,可能会产生多个 persistentindex 对象,而这些对象其实代表着一个索引目录。随着创建索引的次数越来越多,那么索引目录也在增多,但是索引目录中的数据却不是很多,所以我们需要把多个目录合并,其实也就是索引的合并。
执行这个操作的类是 IndexMerger ,看其定义为:
class IndexMerger extends Thread implements IndexListener
/*由此可见它是一个线程,并且同时充当着listener的角色,看看它的构造方法:
*/
IndexMerger(MultiIndex multiIndex) {
this.multiIndex = multiIndex;
setName("IndexMerger");
setDaemon(true);
try {
mergerIdle.acquire();
} catch (InterruptedException e) {
// will never happen, lock is free upon construction
throw new InternalError("Unable to acquire mutex after construction");
}
}
还是一个 deamon 线程。而且一构造就来了一个 mergerIdle.acquire(); 真是迫不及待啊。啥意思啊?得到一把锁,一把非阻塞的锁。
在创建完 IndexMerger ,那么就有可能把 PersistentIndex 加进来了,因为 Merger 类必须知道哪些 PersistentIndex 是需要 Merger 的,那么我们看看负责这段逻辑的代码:这段代码主要负责 3 个功能,一个是初始化 indexBuckets ,这个一个 ArrayList ,其中放的是需要 Merger 的 PersistentIndex 的列表,也就是我们可以认为 indexBucket 里放的还是 list ,这里有一个非常奇怪的设计,就是在初始化的时候将 PersistentIndex 按照 docnums 的范围分组了,一组就是一个 indexBucket 。
第二个是把需要加入的 PersistentIndex 加入到对应的分组中。
第三个是判断是否需要合并,如果需要就加到一个队列中,等待被合并。
先看第一段代码:
synchronized (lock) {
// initially create buckets
if (indexBuckets.size() == 0) {
long lower = 0;
// default minMergeDocs is 100
long upper = minMergeDocs;
//default maxMergeDocs is 2147483647
// IndexBucket实际上就是一个ArrayList
while (upper < maxMergeDocs) {
indexBuckets.add(new IndexBucket(lower, upper, true));
lower = upper + 1;
//default mergeFactor is 10
upper *= mergeFactor;
}
// one with upper = maxMergeDocs
indexBuckets.add(new IndexBucket(lower, maxMergeDocs, false));
// and another one as overflow, just in case...
indexBuckets.add(new IndexBucket(maxMergeDocs + 1, Long.MAX_VALUE, false));
}
············
仔细阅读代码,我们发现,在初始化 indexBuckets 的代码中,其实按照范围来初始化的,比如当添加第一 IndexBucket 的时候 lower=0 , upper=100
即 new IndexBucket(0 100 , rue )
第二个则为: new IndexBucket(101, 100*10, t rue )
第三个则为: new IndexBucket(1001, 100*10*10, t rue )
第四个则为: new IndexBucket(10001, 100*10*10*10, t rue )
第五个则为: new IndexBucket(100001, 100*10*10*10*10, t rue )
````````````
一直持续下去直到 upper 小于 2147483647 ,且是 10 的最大幂。那么就是说 10 亿,当一个目录中有 10 亿个 document 的 index 数据时,这个目录将不再参与 merge 过程, indexBuckets 中总共有 8 个 IndexBucket, 不过在循环外面还有两个创建 IndexBucket 的语句,不过这两个都是不允许参加合并的,所以第 3 个参数是 false ,也就是说一共有 10 个,第九个是:
new IndexBucket(1000000001, 2147483647, false)
那么第十个是:
new IndexBucket(2147483648, 0x7fffffffffffffffL, false)
搞清楚 indexBuckets 的 初始化之后,我们再来看看第二个步骤,把根据 docNums 把对应的 persistentindex 加入到 IndexBucket 中 :
// put index in bucket
IndexBucket bucket = (IndexBucket) indexBuckets.get(indexBuckets.size() - 1);
for (int i = 0; i < indexBuckets.size(); i++) {
bucket = (IndexBucket) indexBuckets.get(i);
if (bucket.fits(numDocs)) {
break;
}
}
/*如果indexBuckets 没有值,那么就把Index 添加到第10个IndexBucket中,否则就从indexBuckets 的第一IndexBucket开始匹配,根据numDocs的值放到对应的IndexBucket中。*/
bucket.add(new Index(name, numDocs));
if (log.isDebugEnabled()) {
log.debug("index added: name=" + name + ", numDocs=" + numDocs);
}
// if bucket does not allow merge, we don't have to continue
//如果是最后两个IndexBucket,那么即刻退出
if (!bucket.allowsMerge()) {
return;
}
/*这段代码没有什么难的,接着看第3个步骤:
*/ // check if we need a merge
//超过indexbucket中超过10个元素<其实就是10个目录>则开始合并
if (bucket.size() >= mergeFactor) {
long targetMergeDocs = bucket.upper;
targetMergeDocs = Math.min(targetMergeDocs * mergeFactor, maxMergeDocs);
// sum up docs in bucket
List indexesToMerge = new ArrayList();
int mergeDocs = 0;
for (Iterator it = bucket.iterator(); it.hasNext() && mergeDocs <= targetMergeDocs;) {
indexesToMerge.add(it.next());
}
/* 结合上下文,indexesToMerge.size()这值会小于2吗?????*/
if (indexesToMerge.size() > 2) {
// found merge
Index[] idxs = (Index[]) indexesToMerge.toArray(new Index[indexesToMerge.size()]);
bucket.removeAll(indexesToMerge);
if (log.isDebugEnabled()) {
log.debug("requesting merge for " + indexesToMerge);
}
mergeTasks.add(new Merge(idxs));
log.debug("merge queue now contains " + mergeTasks.size() + " tasks.");
}
}
这段代码的主要功能是把 indexbucket 里的 persistentindex 信息拿出来,而且量超过 2 的话就把他们加入到一个队列中,并将它们从该 indexbucket 里删除。通过这个步骤,那么 mergeTasks 队列中就存在一些需要合并的 index 了。
中场总结:
通过上面的方法和前面的索引提交的文章我们得到一些重要信息:当用户把 ramdirectory 中超过 100 的 docs 的 index data 刷到 fsdirectory 中时,新建一个目录,作为这个新 fsdirectory 的目录,接着把这个 fsdirectory 对应的 PersistentIndex 加到 IndexMerger 类的某个 IndexBucket 中,接着当某个 IndexBucket 中的 PersistentIndex 数量(即这些目录的数量)超过 10 ( mergefactor )的时候,就会执行合并的操作。
那么下面的问题是,合并之后,这 10 个目录将会何去何从,它们是把另外 9 个合并到其中一个中去呢还是怎么滴?接着看吧。
显然,这里又用到生产消费模型,任何调用 indexAdded 方法的都属性生产者,生产者根据一些条件,有选择的把需要合并的 persistentindex 放到 mergeTasks 的队列中,有了生产者肯定存在消费者,文章开头提过, IndexMerger 类是一个 deamon 线程,看看它的 run 方法,那么就发现,其实它就是消费者。它主要完成以下几个功能:
1 判断消费者是否空闲
2 判断队列中是否有退出命令
3 如果空闲则进入 wait 状态
4 根据 persistentindex 的名字取到所有的 persistentindex
的 IndexReader 对象
5 再创建一个新的 PersistentIndex, , 原来的 index 文件合并到这个新的目录中
6 将前面的 IndexReader 对象添加到 PersistentIndex 的 indexwriter 方法中,并执行 optimize 。
7 关闭这些 readers
8 根据名字删除已经被合并的 PersistentIndex 的索引文件和目录等。
我们再来看看代码,代码中已经加入了 ahuaxuan 的注释:
public void run() {
for (;;) {
boolean isIdle = false;
//队列长度为0,表示消费者处于空闲状态,那么会进入wait状态
if (mergeTasks.size() == 0) {
mergerIdle.release();
isIdle = true;
}
/*2判断队列中是否有退出命令
*/
Merge task = (Merge) mergeTasks.remove();
if (task == QUIT) {
mergerIdle.release();
break;
}
if (isIdle) {
try {
mergerIdle.acquire();
} catch (InterruptedException e) {
Thread.interrupted();
log.warn("Unable to acquire mergerIdle sync");
}
}
log.debug("accepted merge request");
// reset deleted documents
deletedDocuments.clear();
// get readers
/*4 根据persistentindex的名字取到所有的persistentindex
的IndexReader对象
*/
String[] names = new String[task.indexes.length];
for (int i = 0; i < task.indexes.length; i++) {
names[i] = task.indexes[i].name;
}
try {
log.debug("create new index");
/*再创建一个新的PersistentIndex,原来的index文件合并到这个新的目录中
*/
PersistentIndex index = multiIndex.getOrCreateIndex(null);
boolean success = false;
try {
log.debug("get index readers from MultiIndex");
IndexReader[] readers = multiIndex.getIndexReaders(names, this);
try {
// do the merge
long time = System.currentTimeMillis();
/*6 将前面的IndexReader对象添加到PersistentIndex的indexwriter方法中,并执行optimize。
*/
index.addIndexes(readers);
time = System.currentTimeMillis() - time;
int docCount = 0;
for (int i = 0; i < readers.length; i++) {
docCount += readers[i].numDocs();
}
log.info("merged " + docCount + " documents in " + time + " ms into " + index.getName() + ".");
} finally {
for (int i = 0; i < readers.length; i++) {
/*7 关闭这些readers
*/
try {
readers[i].close();
} catch (IOException e) {
log.warn("Unable to close IndexReader: " + e);
}
}
}
// inform multi index
// if we cannot get the sync immediately we have to quit
if (!indexReplacement.attempt(0)) {
log.debug("index merging canceled");
break;
}
try {
log.debug("replace indexes");
multiIndex.replaceIndexes(names, index, deletedDocuments);
} finally {
indexReplacement.release();
}
success = true;
} finally {
if (!success) {
// delete index
log.debug("deleting index " + index.getName());
/*8 根据名字删除已经被合并的PersistentIndex的索引文件和目录等。
*/
multiIndex.deleteIndex(index);
}
}
} catch (Throwable e) {
log.error("Error while merging indexes: " + e);
}
}
log.info("IndexMerger terminated");
}
看到这里爱思考的同学们一定会意识到这里还漏了什么,是什么呢?前面讲到,一个 bucket 中超过 10 个目录,会被合并一个新的目录,那么也就是说这个新目录中至少有 1000 个 document 的索引数据,这样下来,如果我有 100000 个节点,而且恰好每个目录中之后 1000 个 document 的数据,那么就得用 100 个目录来存储数据了。这样带来的问题是,每做一次查询,都需要把 100 个 indexReader 传给 search ,即使使用多线程并行搜索,那目录数也还是太多了,而且如果是 100w 个节点,那就更不得了了,所以 jackrabbit 中一定还有机制会把这些目录合并成更大目录的逻辑。为什么这么说,因为之前在创建 indexbucket 中的时候,分了 8 个允许合并的段,而上面的逻辑只会用到前面一个 bucket ,后面的几个肯定是有用处的,那么是谁来触发它们的,它们在哪里呢?
我们看到在上面的 run 方法中,我们有一个方法没有讲到: multiIndex .replaceIndexes(names, index, deletedDocuments );
我们将会在这个方法中寻找到真相,同样, ahuaxuan 在代码中加入了自己的注释
/* obsoleteIndexes 是需要被删除的 dir ,因为他们的数据已经被合并到新的目录里, index 参数则表示那个对应那个新目录的 PersistentIndex , deleted 表示需要被删除的类 */
void replaceIndexes(String[] obsoleteIndexes,
PersistentIndex index,
Collection deleted)
throws IOException {
/*在multiIndex中,到处都是synchronized ,而且都是锁定multiindex对象,为啥呢? 详见后文*/
synchronized (this) {
/*这段代码在multiIndex#update方法中也出现过,你知道它的用途吗,其实可以猜出来*/
synchronized (updateMonitor) {
updateInProgress = true;
}
try {
// if we are reindexing there is already an active transaction
if (!reindexing) {
executeAndLog(new Start(Action.INTERNAL_TRANS_REPL_INDEXES));
}
// delete obsolete indexes
/*10个目录已经合并成一个了,那这个10个目录该删的就删,不需要犹豫*/
Set names = new HashSet(Arrays.asList(obsoleteIndexes));
for (Iterator it = names.iterator(); it.hasNext();) {
// do not try to delete indexes that are already gone
String indexName = (String) it.next();
if (indexNames.contains(indexName)) {
executeAndLog(new DeleteIndex(getTransactionId(), indexName));
}
}
// Index merger does not log an action when it creates the target
// index of the merge. We have to do this here.
/*还记得CreateIndex的作用吗?复习一下:根据名字获取PersistentIndex对象,如果名字不存在或者为null,则新建一个PersistentIndex对象,罗嗦一句,一个PersistentIndex代表一个目录*/
executeAndLog(new CreateIndex(getTransactionId(), index.getName()));
/*又来了AddIndex对象,还记得它的作用吗,将这个persistentIndex加入到*/
executeAndLog(new AddIndex(getTransactionId(), index.getName()));
// delete documents in index
for (Iterator it = deleted.iterator(); it.hasNext();) {
Term id = (Term) it.next();
index.removeDocument(id);
}
index.commit();
if (!reindexing) {
// only commit if we are not reindexing
// when reindexing the final commit is done at the very end
executeAndLog(new Commit(getTransactionId()));
}
} finally {
synchronized (updateMonitor) {
updateInProgress = false;
updateMonitor.notifyAll();
releaseMultiReader();
}
}
}
if (reindexing) {
// do some cleanup right away when reindexing
attemptDelete();
}
}
看完这段方法,我们发现,小的目录合并成大目录之后,这个大目录又被加到 indexbucket 等待下一次被合并,如此递归,一直当一个目录的 document 的 index 数据超过 10 亿,那么就不会再合并了, ahuaxuan 画了一张图:
=========================================================================
图中的0-100表示最基层的目录级别,这些目录只包含0-100个document的index数据,而默认参数情况下这些目录根本用不着,因为在前面的流程中,我们看到,ramdirectory中的数据只有满100才会加入到fsdirectory中,这意味着一开始用到的目录就是101-1000级别的目录(101-1000的目录表示这些目录中的document的index数据也只有101-1000个这个范围。)。这种目录超过10个就会合并成一个新目录。依次类推高层目录。见图中ahuaxuan的注释
说到这里,大部分人都知道了,很多参数可以控制合并的调优,这些参数在前文已经讲过了,不再赘述。
到这里,IndexMerger的主体流程基本上完成了,其实就是一个生产-消费模型+小目录生产大目录,大目录生成更大目录的算法,这样做的好处是什么?当然是尽量少改动索引文件,应该说是便于分布式的查询架构。但是在后文中,我们会详细分析jackrabbit还没有为分布式查询准备好的原因,它的这块设计还有待改进,人无完人,框架亦是如此,不用过于苛求,也不必抱怨,用的不爽,那么就---改它,再不行---重新实现(某个模块或者全部)。
TO BE CONTINUE