还有如果是多台WEB服务器的情况了,如同一个项目可能在网通跟电信同时布署,那又怎么办?

实时我想是指transactional, compass号称实现了这个功能， 但又挺多的问题。 一个简单解决多个线程访问的办法就是用多个索引， 不一个是不行了的。 要是要满足事务的ACID， 情况就更复杂了， compass在几个方面都有缺陷， 但要求不高的， 也可将就。

Compass是集于Lucene封装的一个全文检索组件。有实时同步的功能，如果你使用Hibernate和jdbc，它提供现成的同步。
其它的可以集于AOP，参见Compass文档

compass 虽然可以，但是如果多线程做索引这个问题还是比较难解决的，现在实现lucene的实时搜索主要是做索引和更新IndexSearch 这个问题，这两个问题里面最难解决的就是做索引！

我们现在是靠schedule方式定期根据updateTime爬最新数据。每次爬完后记录已爬数据的截止时间。如果爬出的数据OID已经在索引中存在就update，如果不存在就add。周期很短。1分钟以下。我们称为正常扫描。

由于updateTime往往存在着偏差，因为updateTime要么是在java端生成，要么是在写入db时生成，都不是在真正commit时。我们会用补偿sheduler去进行补偿，补偿服务只需要爬出id和updateTime（或version），内存中保留一棵二叉排序树，根据OID排序，从db中查出补偿时间段的oid和updateTime也是排好序的。两个排好序的集合进行比较，如果oid在内存中的排序树中已经能存在，就比较updateTime，如果updateTime比现在的新就添加到updateOIDList中，如果OID在树中不存在，就放入addOIDList中。迭代的同时将树中每个资源的updateTime和（最后一次记录到文件中正常扫描的截至时间-transactionTimeOut）进行比较，如果比这个还老，就认为这些数据是肯定不会被更新过的，因为这个时间之前如果有更新就应该是完全可见的，把它从树中删除，下次补偿服务已经不再需要了。将updateList和addList中的资源加入索引中。补偿服务的截至时间是最后一次记录到文件中的正常扫描的截止时间，而开始时间是上一次补充服务运行时算出来的并保存在另外一个文件中，值是Lastb补偿服务（最后一次正常扫描的截至时间-transactionTimeOut）。这样每次补偿服务运行时我们都会补偿最新的数据因为我们用正常扫描的截至时间作为补偿服务的结束时间，也不会漏掉数据，因为transactionTimeout之前的数据是下一次补偿服务再也不care的数据，因为它们在当时已经完全可见，要么已经生成要么timeout。选择开始时间必须遵循两个原则：
1） 开始时间之前的数据更新已经是完全可见的
2） 开始时间之前的数据肯定被上一次补偿服务扫描过
为了提高performance我们把transactiontimeout做了三级划分，目的是为了减少延迟和提高性能。第一级和正常逻辑一样周期，但transaction timeout的值也取的是这个周期的时间大小。大部分事务如果是3分钟结束的，我们就会有一个补偿服务3分钟run一次，这是第二级。第三级当然是application server中设定的transaction timeout时间大概是10分钟，它是保证正确性，不care的延迟，它的周期是10分钟。只有最后一级的开始时间需要存文件，保证系统down掉后还可以正确从上一次已经补偿的起点开始，不会遗漏。最后一次截至时间也不需要涵盖最新的数据，只要涵盖下一次补偿服务扫描时完全可见时间点之前的数据就可以了。

deletion，对于删除的数据，也有个额外的服务。它获取索引中ID field值，获取时根据ID排序。取出排序后的最小值和最大值，根据最小值和最大值从DB中取出所有在这个OID段中的所有OID并排序。将两个排序好的集合进行比较。如果索引中有，而db中没有的，该资源就要删除。

我们部门小组在做了一套索引实时更新机制，大体思路是，当有数据的CRUD操作时，写消息队列通知索引服务器，索引服务器定时扫描队列，然后更新索引。目前索引更新频率为5分钟一次，每个应该的索引文件在G级别以下，目前线上跑的很好，300万左右的搜索访问量。

对于楼上的思想很早之前，我自己写代码实现过，可能我自己代码功夫不够硬，跑起来经常出现内存溢出，或者线程死锁的问题！可能是一个人写的原因吧，至今没法很好完善！

小数据量瓶颈在CPU,大数据量瓶颈在IO

可参考
Lucene Near Realtime Search
http://wiki.apache.org/lucene-java/NearRealtimeSearch
相关Patches
LUCENE-1314 – IndexReader.clone
LUCENE-1516 – IndexWriter.getReader
LUCENE-1313 – RAMDir in IndexWriter
LUCENE-1483 – Fast FieldCache loading
LUCENE-1231 – Column stride fields
LUCENE-1526 – Incremental copy-on-write