Lucene4.3进阶开发之初入仙界(一)

    本篇开始从源码的角度分析下Lucene的根基Directory的实现&＃xff0c;在此之前&＃xff0c;我们先来看下Directory家族的层级分布式图&＃xff1a;

从上图中&＃xff0c;我们可以看出Directory共有11个直接或间接的子类&＃xff0c;不同子类的作用和功能不一样&＃xff0c;那么Directory作为次继承图的顶级父类&＃xff0c;在Lucene中确实发挥重要的根基作用&＃xff0c;就像Hadoop的根基是HDFS一样&＃xff0c;Directory肩负着索引存储的重任&＃xff0c;如果没有存储&＃xff0c;那么检索就无从谈起了&＃xff0c;虽然我们经常称全文检索&＃xff0c;搜索引擎什么的&＃xff0c;其实他们的背后&＃xff0c;Directory才是默默无闻的雷锋。

线面就来详细剖析Directory的核心实现&＃xff1a;

Directory是由lucene中的一些索引文件组成的目录&＃xff0c;一个典型的索引文件结构截图如下&＃xff1a;

而Directory的作用&＃xff0c;就是负责管理这些索引文件&＃xff0c;包括数据的读取和写入&＃xff0c;以及索引文件的添加、删除和合并。从这样的角度来分析&＃xff0c;Directory更像一个系统的管理员&＃xff0c;下面再具体分析一下核心方法的作用。

我们都知道lucene的索引体系&＃xff0c;支持读共享&＃xff0c;写独占的方式来访问索引目录&＃xff0c;也就是说&＃xff0c;它允许多个线程实例同时并发的读取&＃xff0c;而不允许多个线程同时写入&＃xff0c;大家可能会有疑问&＃xff0c;为什么不支持多线程写入呢&＃xff1f;这其实是因为索引目录有自己的某一时刻的内部状态&＃xff0c;比如说文件指针&＃xff0c;而多线程写入时&＃xff0c;会造成指针混乱&＃xff0c;从而引起索引结构或某些数据丢失&＃xff0c;所以lucene任何时候都禁止有多个线程并发的写入索引&＃xff0c;即使是多线程写&＃xff0c;每次也只能通过队列的方式&＃xff0c;一次只允许一个线程操作索引&＃xff0c;按这样的情况分析&＃xff0c;多线程写入与单线程写入&＃xff0c;在性能上的提升&＃xff0c;并不是明显的&＃xff0c;那么lucene又是怎样控制一次只能只有一个线程的写入呢&＃xff1f;打开Directory的源码&＃xff0c;我们就会发现&＃xff0c;他其实是在内部维护了一个锁的实例&＃xff0c;通过加锁方式&＃xff0c;来禁止后来线程的写入操作&＃xff0c;当然锁的作用不仅仅是防止并发写入&＃xff0c;他还可以通过锁的名字来判断&＃xff0c;这两份索引是否为同一份索引&＃xff0c;那么如果我们想使用多线程来提升写入速度&＃xff0c;一个折中的办法就是&＃xff0c;每一个I型按成写一份目录&＃xff0c;最后再对这些目录进行合并&＃xff0c;下面给出了一些源码中锁的实现&＃xff1a;

protected LockFactory lockFactory;//锁实现&＃xff0c;只能由子类覆盖
//设置锁名public Lock makeLock(String name) {return lockFactory.makeLock(name);}//清除锁public void clearLock(String name) throws IOException {if (lockFactory !&＃61; null) {lockFactory.clearLock(name);}}

下面来分析Directory源码中另一个重要isOpen的作用

  //注意&＃xff0c;使用的是volatile关键字修饰volatile protected boolean isOpen &＃61; true;

isOpen是用来判断当前的Directory实例&＃xff0c;在内存中的状态&＃xff0c;它使用的是volatile关键字修饰的&＃xff0c;被此变量修饰的内容&＃xff0c;JVM虚拟机读取的时候会直接在主存中读取该变量的值&＃xff0c;而不会再各个线程的本地内存中读&＃xff0c;这样一来&＃xff0c;当并发读的时候&＃xff0c;如果Directory实例关闭了&＃xff0c;那么各个读取的线程会立即获取最新的状态&＃xff0c;如果不做处理的话&＃xff0c;将会抛出一个目录实例关闭的异常。isOpen确保了索引在并发读的时候&＃xff0c;各个线程实例获取Directory状态的一致性。

  private static final class SlicedIndexInput extends BufferedIndexInput {IndexInput base;long fileOffset;long length;SlicedIndexInput(final String sliceDescription, final IndexInput base, final long fileOffset, final long length) {this(sliceDescription, base, fileOffset, length, BufferedIndexInput.BUFFER_SIZE);}SlicedIndexInput(final String sliceDescription, final IndexInput base, final long fileOffset, final long length, int readBufferSize) {super("SlicedIndexInput(" &＃43; sliceDescription &＃43; " in " &＃43; base &＃43; " slice&＃61;" &＃43; fileOffset &＃43; ":" &＃43; (fileOffset&＃43;length) &＃43; ")", readBufferSize);this.base &＃61; base.clone();this.fileOffset &＃61; fileOffset;this.length &＃61; length;}

接下来分析Directory的静态常量内部类。

SlicedIndexInput的作用&＃xff0c;lucene的索引文件时非常松散的&＃xff0c;不同类型的数据存储在不同的文件里&＃xff0c;我们可以通过文件名&＃xff0c;来单独读取指定索引文件的内容&＃xff0c;同样的道理我们也可以&＃xff0c;在写入信息时候&＃xff0c;单独写入某部分数据的信息&＃xff0c;这样一来&＃xff0c;就避免了操作整个目录的可能&＃xff0c;按需所用&＃xff0c;从一定程度上来说&＃xff0c;这样的实际提升了性能&＃xff0c;保证了数据的稳定与可靠性&＃xff0c;虽然也从某种程度上加大了Directory目录管理的复杂度&＃xff0c;但是这是微不足道的。

SlicedIndexInput这个类的作用保证了lucene可以单独读取部分索引文件的内容&＃xff0c;注意这些内容都不是最原始的数据&＃xff0c;而是SlicedIndexInput克隆的一份副本&＃xff0c;这样一来在并发读的环境下是非常有利的&＃xff0c;每个线程都会从主存中load一份副本出来。在我们的源码中&＃xff0c;我们并没有发现它具有深度克隆的功能&＃xff0c;但是通过一系列继承的追踪&＃xff0c;我们发现&＃xff0c;SlicedIndexInput->BufferIndexInput->IndexInput->DataInput&＃xff0c;在最后的这个父类中实现了Cloneable和Closeable接口&＃xff0c;从而确保了SlicedIndexInput可以正常的工作&＃xff0c;以及释放一些占用的IO资源。

除了上面几个比较重要的作用外&＃xff0c;Directory还提供了&＃xff0c;其他的一些文件管理功能&＃xff0c;例如获取所有的索引文件信息&＃xff0c;删除一个索引文件&＃xff0c;获取一个索引文件的大小&＃xff0c;索引的备份&＃xff0c;等等。