一、简介

Apache solr是基于Lucene的全文索引库实现的开源搜索引擎，支持索引的统计维护(Overview)、结构权重分析优化（Analyse）、配置在线预览（Config）、数据库导入刷新索引（Dataimport）、接口开放查询（Query）、分布式集群（Replication）及结构预览（Schema）。另外Solr Admin将系统的管理做的尽可能透明化 （ 在线日志&线程池、索引管理等），并也很简单高效的方式呈现给用户。

二、系统特征

Solr4.0版本基于Zookeeper分布式系统集群方案，实现了多级Master-Slaver，主要特色如下

 1. 集中式的配置信息

使用ZK进行集中配置，启动时可以指定把Solr的相关配置文件上传Zookeeper，多机器共用。Solr直接读取ZK中的配置文件信息，不做缓存，确保更新的实时性。如之前在执行任务时崩溃的机器，在重启后，或者集群选出候选者时，可以再次执行这个未完成的任务。

2. 自动容错

 SolrCloud对索引分片，并对每个分片创建多个Replication。每个Replication都可以对外提供服务。一个Replication挂掉不会影响索引服务。自动将其他负应用服务器上的创建失败的索引任务重新恢复，达到所有自动索引Replication效果

3. 近实时搜索

在毫秒内检索到新加入索引

4. 负载均衡

SolrCloud索引的多个Replication可以分布在多台机器上，均衡查询压力。如果查询压力大，可以通过扩展机器，增加Replication来减缓。

5. 自动分发的索引和索引分片

发送文档到任何节点，它都会转发到正确节点。

6. 事务日志

事务日志确保更新无丢失，即使文档没有索引到磁盘。

三、系统逻辑架构图

前言

Collection：在SolrCloud集群中逻辑意义上的完整的索引。它常常被划分为一个或多个Shard，它们使用相同的Config Set。如果Shard数超过一个，它就是分布式索引，SolrCloud让你通过Collection名称引用它，而不需要关心分布式检索时需要使用的和Shard相关参数。

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

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

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

Replica: Shard的一个拷贝。每个Replica存在于Solr的一个Core中。一个命名为“test”的collection以numShards=1创建，并且指定replicationFactor设置为2，这会产生2个replicas，也就是对应会有2个Core，每个在不同的机器或者Solr实例。一个会被命名为test_shard1_replica1，另一个命名为test_shard1_replica2。它们中的一个会被选举为Leader。

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

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

1. 索引（collection）的逻辑图

2. 索引和Solr实体对照图

3. 索引创建过程

4. 检索过程

5. 索引分片Shard Splitting