solr基本概念

开发环境说明：

ambari v2.6.1

Solr v5.5.5

笔者使用的ambari来自动化安装的Solr

一、什么是Solr，及其主要特点

其实简单的说，Solr是一个基于Apache Lucene 项目的开源企业级搜索平台，是用JAVA编写的、运行在Servlet容器中的一个独立的全文搜索服务器（换句话说就是个JAVA-WEB APP），并具有类似REST的HTTP/XML和JSON的API。

主要功能包括全文检索，高亮命中，分面搜索(faceted search)，近实时索引，动态集群，数据库集成，富文本索引，空间搜索；通过提供分布式索引，复制，负载均衡查询，自动故障转移和恢复，集中配置等功能实现高可用，可伸缩和可容错。

• Advanced Full-Text Search Capabilities（高级全文搜索能力）
• Optimized for High Volume Traffic（大数据性能优化）
• Standards Based Open Interfaces - XML, JSON and HTTP（标准的XML,JSON,HTTP接口）
• Comprehensive Administration Interfaces（综合管理界面）
• Easy Monitoring（易于监控）
• Highly Scalable and Fault Tolerant（高可扩展和容错力）
• Flexible and Adaptable with easy configuration（通过简单配置带来灵活性和适应性）
• Near Real-Time Indexing（近乎实时的索引）
• Extensible Plugin Architecture（可扩展的插件构架）

扩展：Solr和Lucene之间的关系

• Solr是Lucene的一个子项目，它在Lucene的基础上进行包装，成为一个企业级搜索服务器开发框架。
• Solr与Lucene的主要区别体现在：
• Solr更加贴近实际应用，是Lucene在面向企业搜索服务领域的扩展；
• Solr的缓存等机制使全文检索获得性能上的提升；通过配置文件的开发使得Solr具有良好的扩展性；
• Solr提供了用户友好的管理界面与查询结果界面。

简单讲：Solr使用Lucene并且扩展了它！

二、Solr目录结构

以使用ambari安装的solr为例，源码路径： /usr/lib/ambari-infra-solr

三、重要的配置文件

Solr5的主要配置文件有 solrconfig.xml和 managed-schema，另外一些还有 solr.xml, 数据导入配置, ZooKeeper配置等。这里先提示记录一下

四、SolrCloud概念

SolrCloud(solr 云)是Solr提供的分布式搜索方案，当你需要大规模，容错，分布式索引和检索能力时使用 SolrCloud。当一个系统的索引数据量少的时候是不需要使用SolrCloud的，当索引量很大，搜索请求并发很高，这时需要使用SolrCloud来满足这些需求。

SolrCloud是基于Solr和Zookeeper的分布式搜索方案，它的主要思想是使用Zookeeper作为集群的配置信息中心。该模式下有Cluster，Node，Collection，Shard，LeaderCore，ReplicationCore等重要概念。

1. Cluster集群：

Cluster是一组Solr节点，逻辑上作为一个单元进行管理，整个集群必须使用同一套schema和SolrConfig。

2. Node节点：

一个运行Solr的JVM实例。

3. Collection：

在SolrCloud集群中逻辑意义上的完整的索引,常常被划分为一个或多个Shard，这些Shard使用相同的Config Set，如果Shard数超过一个，那么索引方案就是分布式索引。SolrCloud允许客户端用户通过Collection名称引用它，这样用户不需要关心分布式检索时需要使用的和Shard相关参数。

4. Core:

也就是Solr Core，一个Solr中包含一个或者多个Solr Core，每个Solr Core可以独立提供索引和查询功能，Solr Core的提出是为了增加管理灵活性和共用资源。SolrCloud中使用的配置是在Zookeeper中的，而传统的Solr Core的配置文件是在磁盘上的配置目录中。

5. Config Set:

Solr Core提供服务必须的一组配置文件,每个Config Set有一个名字。最小需要包括solrconfig.xml和schema.xml，除此之外，依据这两个文件的配置内容，可能还需要包含其它文件,如中文索引需要的词库文件。Config Set存储在Zookeeper中，可以重新上传或者使用upconfig命令进行更新，可使用Solr的启动参数bootstrap_confdir进行初始化或更新。

6. Shard分片:

Collection的逻辑分片。每个Shard被分成一个或者多个replicas，通过选举确定哪个是Leader。

7. Replica:

Shard的一个拷贝。每个Replica存在于Solr的一个Core中。换句话说一个Solr Core对应着一个Replica，如一个命名为“test”的collection以numShards=1创建，并且指定replicationFact为2，这会产生2个replicas，也就是对应会有2个Core，分别存储在不同的机器或者Solr实例上，其中一个会被命名为testshard1replica1，另一个命名为testshard1replica2，它们中的一个会被选举为Leader。

8. Leader:

赢得选举的Shard replicas，每个Shard有多个Replicas，这几个Replicas需要选举来确定一个Leader。选举可以发生在任何时间，但是通常他们仅在某个Solr实例发生故障时才会触发。当进行索引操作时，SolrCloud会将索引操作请求传到此Shard对应的leader，leader再分发它们到全部Shard的replicas。

9. Zookeeper:

Zookeeper提供分布式锁功能，这对SolrCloud是必须的，主要负责处理Leader的选举。Solr可以以内嵌的Zookeeper运行，也可以使用独立的Zookeeper，并且Solr官方建议最好有3个以上的主机。

zookeeper的主要作用有：

• 集中配置存储以及管理。
• 集群状态改变时进行监控以及通知。
• shard leader的选举。
• 自动容错
• 近实时搜索
• 查询时自动负载均衡

五、Collection逻辑图

解释：

• 从上图可以看到，有一个collection，被分为两个shard，每个shard分为三个replica，其中每个shard从自己的三个replica选择一个作为Leader。
• 每个shard的replica被分别存储在三台不同的机器（Solr实例）中，这样的目的是容灾处理，提高可用性。如果有一个机器挂掉之后，因为每个shard在别的机器上有复制品，所以能保证整个数据的可用，这是Solrcloud就会在还存在的replica中重新选举一个作为这个shard的Leader。