本文介绍了Lucene在非集群及集群环境下两种不同的工作模式：直接更新Lucene索引目录和通过JMS队列进行更新。前者简单易用，变化内容能即时在查询中体现；后者适合高吞吐量场景，通过主从模式确保更新的一致性和可靠性。
2.2.1. Lucene
In this mode, all index update operations applied on a given node (JVM) will be executed to the Lucene directories (through the directory providers) by the same node. This mode is typically used in non clustered environment or in clustered environments where the directory store is shared.
[img]http://www.hibernate.org/hib_docs/search/reference/en/shared/images/lucene-backend.png[/img]
This mode targets non clustered applications, or clustered applications where the Directory is taking care of the locking strategy.
The main advantage is simplicity and immediate visibility of the changes in Lucene queries (a requirement is some applications).
此模式适用于非集群应用程序，或者集群化的应用程序处理了共享索引文件的文件锁策略。此实现方式主要的优势是简单，可以立即在集群的任何服务器的Lucene搜索请求中见到被索引的内容
2.2.2. JMS
All index update operations applied on a given node are sent to a JMS queue. A unique reader will then process the queue and update the master Lucene index. The master index is then replicated on a regular basis to the slave copies. This is known as the master / slaves pattern. The master is the sole responsible for updating the Lucene index. The slaves can accept read as well as write operations. However, they only process the read operation on their local index copy and delegate the update operations to the master.
[img]http://www.hibernate.org/hib_docs/search/reference/en/shared/images/jms-backend.png[/img]
This mode targets clustered environments where throughput is critical, and index update delays are affordable. Reliability is ensured by the JMS provider and by having the slaves working on a local copy of the index.
所有在各个应用服务器节点索引的更新操作都被发送到JMS队列。一个唯一的阅读器将处理这个队列，更新这个lucene索引。接下来主索引将被拷贝到从索引中。就是所谓的主从模式。主索引服务器是唯一负责更新Lucene索引的。从夫妇其可以接收读和写操作。可是他们值处理读操作在它们的本地索引拷贝，并且代理更新操作到主服务器。
Note
Hibernate Search is an extensible architecture. While not yet part of the public API, plugging a third party back end is possible. Feel free to drop ideas to hibernate-dev@lists.jboss.org.
支持同步异步索引策略，但是建议先使用同步策略，当同步出现性能问题时，使用异步策略，但是要proper benchmark([b]not a lonely cowboy hitting the system in a completely unrealistic way[/b])需要模拟一个真实的环境来考察。
看到这里，感觉hibernate的lucene还是有些诱惑力的。已经解决了前端应用服务器集群的索引问题。但是相对于使用solr这样的独立索引服务器(solr是否支持索引服务器集群?)，似乎这个分布式体系需要重新考虑了。
还是功能划分，索引服务交给独立的索引服务器，前端的应用服务器需要时可以调用索引服务器的内容。
如何合理的实现一个大型系统，是让每一台服务器成为全能型选手,还是分别成为某一方面的专家?参考人类社会，服务器分工应该是最终的解决方式吧.
[url]http://www.hibernate.org/hib_docs/search/reference/en/html_single/#d0e403[/url]
In this mode, all index update operations applied on a given node (JVM) will be executed to the Lucene directories (through the directory providers) by the same node. This mode is typically used in non clustered environment or in clustered environments where the directory store is shared.
[img]http://www.hibernate.org/hib_docs/search/reference/en/shared/images/lucene-backend.png[/img]
This mode targets non clustered applications, or clustered applications where the Directory is taking care of the locking strategy.
The main advantage is simplicity and immediate visibility of the changes in Lucene queries (a requirement is some applications).
此模式适用于非集群应用程序，或者集群化的应用程序处理了共享索引文件的文件锁策略。此实现方式主要的优势是简单，可以立即在集群的任何服务器的Lucene搜索请求中见到被索引的内容
2.2.2. JMS
All index update operations applied on a given node are sent to a JMS queue. A unique reader will then process the queue and update the master Lucene index. The master index is then replicated on a regular basis to the slave copies. This is known as the master / slaves pattern. The master is the sole responsible for updating the Lucene index. The slaves can accept read as well as write operations. However, they only process the read operation on their local index copy and delegate the update operations to the master.
[img]http://www.hibernate.org/hib_docs/search/reference/en/shared/images/jms-backend.png[/img]
This mode targets clustered environments where throughput is critical, and index update delays are affordable. Reliability is ensured by the JMS provider and by having the slaves working on a local copy of the index.
所有在各个应用服务器节点索引的更新操作都被发送到JMS队列。一个唯一的阅读器将处理这个队列，更新这个lucene索引。接下来主索引将被拷贝到从索引中。就是所谓的主从模式。主索引服务器是唯一负责更新Lucene索引的。从夫妇其可以接收读和写操作。可是他们值处理读操作在它们的本地索引拷贝，并且代理更新操作到主服务器。
Note
Hibernate Search is an extensible architecture. While not yet part of the public API, plugging a third party back end is possible. Feel free to drop ideas to hibernate-dev@lists.jboss.org.
支持同步异步索引策略，但是建议先使用同步策略，当同步出现性能问题时，使用异步策略，但是要proper benchmark([b]not a lonely cowboy hitting the system in a completely unrealistic way[/b])需要模拟一个真实的环境来考察。
看到这里，感觉hibernate的lucene还是有些诱惑力的。已经解决了前端应用服务器集群的索引问题。但是相对于使用solr这样的独立索引服务器(solr是否支持索引服务器集群?)，似乎这个分布式体系需要重新考虑了。
还是功能划分，索引服务交给独立的索引服务器，前端的应用服务器需要时可以调用索引服务器的内容。
如何合理的实现一个大型系统，是让每一台服务器成为全能型选手,还是分别成为某一方面的专家?参考人类社会，服务器分工应该是最终的解决方式吧.
[url]http://www.hibernate.org/hib_docs/search/reference/en/html_single/#d0e403[/url]
扫一扫
1600
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
