亚马逊上的休眠搜索问题

Question

技术版本：

休眠 3.6.5
休眠搜索 3.4.0
Lucene (lucene-core-*.jar) 3.1.0
弹簧 3.1.0.M2

休眠（搜索）配置：

<prop key="hibernate.search.default.indexBase">/some/dir</prop>
<prop key="hibernate.search.default.directory_provider">org.hibernate.search.store.FSDirectoryProvider</prop>
<prop key="hibernate.search.default.locking_strategy">native</prop>
<prop key="hibernate.search.default.exclusive_index_use">false</prop>

问题：
我们的应用程序部署在 Amazon（AWS 云）中，但我们在本地集群中也遇到了这个问题：

应用程序设计是这样的，有一个Thread，它是从主（Web）应用程序中产生的，我们需要从中更新一个索引实体。基本上它就像一个状态监视器线程，它读取一个 .status 文件并每 30 秒左右更新一次数据库。这种情况平均持续大约 10 分钟到 1/2 小时。 我们看到的问题是：每隔几天我们就需要重新生成索引，因为 Hibernate Search 停止为有问题的实体返回任何内容（上面讨论的那个）。

我浏览了几个论坛，似乎建议只有一个线程应该更新 Lucene 索引。但也考虑到索引写入是线程安全的。因此，即使多个线程正在写入同一个索引，我仍然希望它不会导致问题（搜索中没有返回任何内容）。也就是说，我可能会得到相关实体的过时状态，但仍然应该返回 something。

我们使用 Hibernate Search 的默认 IndexReader/Writer 实现。

任何帮助将不胜感激。谢谢。

Answer 1

这里有一些想法。

我浏览了几个论坛，似乎建议只有一个 线程应该正在更新 Lucene 索引。

通常情况并非如此。 Lucene 和 Hibernate Search 允许多个索引编写器，但必须通过 Lucene 的 org.apache.lucene.store.LockFactory 正确同步对索引的访问。锁工厂是可配置的，您可以通过属性 *hibernate.search.default.locking_strategy* 使用本地锁工厂。问题可能在于此策略是基于文件的。我不太了解亚马逊的分布式文件系统内部工作原理，但我想文件锁在这种情况下不起作用。您可能需要实施自定义锁定策略。

但也考虑到索引写入是线程安全的。所以即使有多个线程 写入相同的索引，我仍然希望它不会导致问题

正确，只要锁定有效。

如果您可以保证只有更新线程会写入索引，则另一种方法是不使用锁（将 *hibernate.search.default.locking_strategy* 设置为 none）。您是否启用了更新线程自动索引？如果是这样，请尝试关闭它（允许您的用例允许您这样做）。

Answer 2

好的，对于那些来到这里寻找解决方案的人 - 这是我们最终所做的，这似乎已经解决了这个问题（我们已经在 AWS 上对此修复进行了负载测试并且到目前为止没有遇到任何问题）：

我们基于 Lucene 的 NativeFSLockFactory 编写了锁工厂的实现。我们修改了obtain 方法，以便在放弃之前重试几次获取锁。我们在重试之间添加了一个短暂的延迟 (sleep) 以处理 NFS 延迟。

我们使用 Lucene 的 LockVerifyServer 测试了此修复程序，并观察到在高负载下，即使一些锁定获取请求必须等待获取锁定 - 但最终每个锁定获取请求都会得到解决。这实时解释为索引文件的成功更新。

感谢Hardy 向我们展示了路径。 :)

更新：昨天，我们不得不将重试次数提高到大约 30 次，因为我们遇到了索引更新滑点，之前的值为 3。此后一切似乎都很好。