我在我的门户网站中使用 Lucene API，它将有 1000 多个并发用户。我们的 Web 服务器将调用位于应用服务器上的 Lucene API。我们计划使用 2 个应用服务器进行负载平衡。鉴于此，我们在第二个应用服务器上复制 lucene 索引的策略应该是什么？有什么建议吗？
问问题
5227 次
4 回答
3
您可以使用solr，其中包含内置复制。这可能是最好和最简单的解决方案，因为实现您自己的复制方案可能需要大量工作。
也就是说，对于我正在从事的项目，我将自己做这件事。不同之处在于，由于我们使用 PHP 作为前端，我们在套接字服务器中实现了 lucene，它接受查询并返回数据库主键列表。我的计划是将更改推送到服务器并将它们存储在队列中，我将首先将它们存储到内存索引中，然后在负载足够低时将内存索引刷新到磁盘。
尽管如此，这仍然是一件复杂的事情，在我们有一个足够可靠的稳定最终解决方案之前，我准备做很多工作。
于 2009-03-21T23:24:40.607 回答
1
根据经验，Lucene 扩展到成千上万的用户应该没有问题。也就是说，如果您只使用第二个 App 服务器进行负载平衡而不是故障转移情况，您应该可以只在其中一个服务器上托管 Lucene 并通过 NDS（如果您有 unix 环境）访问它或共享来自第二台服务器的目录（在 Windows 环境中）。
同样，这取决于您的具体情况。如果您正在谈论在您的索引中拥有数百万（5 个或更多）文档并且需要您的 lucene 索引是可故障转移的，您可能需要研究 Solr 或 Katta。
于 2009-03-21T23:42:25.573 回答
1
我们正在开发与您所描述的概念证明类似的实现。我们看到的最终产品由三个独立的服务器组成，以完成此任务。
有一个“发布”服务器，负责生成将要使用的索引。有一个服务实现可以处理用于构建这些索引的工作流，并且能够发出完成信号（通过 WCF Web 服务公开的自定义管理 API）。
有两个“面向站点”的 Lucene.NET 服务器。通过 WCF 服务向站点提供对 API 的访问。它们位于物理负载平衡器后面，并会定期“ping”发布服务器，以查看是否存在比当前运行的更新的索引集。如果是，它会从发布服务器请求锁定并通过启动到本地“传入”文件夹的传输来更新本地索引。到达那里后，只需在附加索引时暂停搜索器即可。然后它释放它的锁，其他服务器也可以做同样的事情。
就像我说的那样，我们只是接近概念验证阶段，作为我们当前解决方案的替代品，这是一个负载平衡的 Endeca 集群。指数的大小和实际完成所需任务所需的时间是尚未证明的更大问题。
我们正在考虑的只是一些随机的事情：
如果在每台接收数据的机器上使用两个本地文件夹来实现“循环”方法，则可以减少给定服务器的停机时间。
我们正在查看负载均衡器是否允许编程访问以从集群中删除和添加节点。如果他/她在更新期间访问，这将减少用户遇到挂起的机会。
如果无法进行集群操作，我们正在研究“请求转发”。
我们也看了 solr。虽然其中很多都是开箱即用的，但我们有一些工作时间来探索这条路径作为学习练习 - 学习诸如 Lucene.NET 之类的东西，提高我们的 WF 和 WCF 技能，以及为管理前端实现 ASP.NET MVC -结尾。在最坏的情况下，我们使用 solr 之类的东西，但在一些我们希望改进的技能方面获得了经验。
于 2009-03-23T13:45:30.217 回答
0
我正在将发布后端机器上的索引创建到文件系统中，并将它们复制到市场营销中。这样，每个负载和故障平衡的节点都有自己的索引，没有网络延迟。
唯一的缺点是，您不应该尝试在已复制文件夹中重新创建索引，因为您将在每个节点处都有锁定文件，从而阻塞索引读取器，直到您的重新索引完成。
于 2009-04-27T21:56:18.093 回答