索引复制和负载平衡 [英] Index replication and Load balancing

问题描述

我在我的Web门户中使用Lucene API，它将有1000个并发用户. 我们的Web服务器将调用Lucene API，它将位于一个应用程序服务器上.我们计划使用2个应用程序服务器进行负载平衡. 鉴于此，我们在第二个应用程序服务器上复制Lucene索引的策略应该是什么?请提供任何提示?

Am using Lucene API in my web portal which is going to have 1000s of concurrent users. Our web server will call Lucene API which will be sitting on an app server.We plan to use 2 app servers for load balancing. Given this, what should be our strategy for replicating lucene indexes on the 2nd app server?any tips please?

推荐答案

您可以使用 solr ，其中包含内置复制.这可能是最好，最简单的解决方案，因为实现您自己的复制方案可能需要花费大量的工作.

You could use solr, which contains built in replication. This is possibly the best and easiest solution, since it probably would take quite a lot of work to implement your own replication scheme.

也就是说，对于我正在从事的项目，我将完全按照自己的意愿去做.区别在于，由于我们在前端使用PHP，因此我们在套接字服务器中实现了lucene，该套接字服务器接受查询并返回db主键列表.我的计划是将更改推送到服务器，并将它们存储在队列中，首先将它们存储在内存索引中，然后在负载足够低时将内存索引刷新到磁盘.

That said, I'm about to do exactly that myself, for a project I'm working on. The difference is that since we're using PHP for the frontend, we've implemented lucene in a socket server that accepts queries and returns a list of db primary keys. My plan is to push changes to the server and store them in a queue, where I'll first store them into the the memory index, and then flush the memory index to disk when the load is low enough.

仍然，这是一件复杂的事情，在我们有一个足够可靠的稳定最终解决方案之前，我要做很多工作.

Still, it's a complex thing to do and I'm set on doing quite a lot of work before we have a stable final solution that's reliable enough.

这篇关于索引复制和负载平衡的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！