深入浅出 jackrabbit 八 索引合并（上）

核心提示： 看完这段方法，我们发现，深入浅出 jackrabbit 八 索引合并（上）(7)，小的目录合并成大目录之后，这个大目录又被加到 indexbucket 等待下一次被合并，用的不爽，那么就---改它，如此递归，一直当一个目录的 document 的 index 数据超过 10 亿

看完这段方法，我们发现，小的目录合并成大目录之后，这个大目录又被加到 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还没有为分布式查询准备好的原因，它的这块设计还有待改进，人无完人，框架亦是如此，不用过于苛求，也不必抱怨，用的不爽，那么就---改它，再不行---重新实现（某个模块或者全部）。