Solr 全文索引详解（一）

本系列文章系翻译整理官方文档，结合实践的总结而来。



1. 概述
Solr是一个基于lucene的开源全文索引引擎。具有良好的伸缩性，并且具有良好的可编程性，支持多种插件。本文档提供简单的基础技术支持，包含了部署的步骤、solr数据类型定义、索引与基础数据操作、搜索等方面。
本文档介绍的内容基本属于Solr4.x（1.4）。

2. 部署Solr
Solr的部署非常简单，并且支持StandAlone/Cloud方式部署。所需要的部署文件包括标准化的solr的war包，和一个带有solr配置文件的solr主文件夹（sol.home）。

2.1 Solr的部署目录简析
Solr的部署文件包含一个war包，和一个solr主文件夹。

2.1.1 Solr的war包
war包里包含有http的接口，是所有的操作solr的入口，需要被部署到servlet容器上。入口基于servlet，可以被部署到任何的servlet容器上。

2.1.2 Solr的主文件夹
主文件夹里包含有Solr需要的配置文件和数据文件。

[img]http://dl2.iteye.com/upload/attachment/0099/4651/3dbf9ab9-07de-34ac-927d-9bb1c02a816b.png" alt="[/img]

 bin目录。
 collection1。装载的核心的目录
[img]http://dl2.iteye.com/upload/attachment/0099/4655/ddcc1c55-0654-339c-a999-6217bddbf5c1.png" alt="[/img]
     conf目录。这个目录里存放了核心的配置文件，包括schema.xml等
     core.properties。配置核心的名字等属性
     data。存放所有的数据文件和索引文件
 lib目录。核心引用的自定义函数的包路径

2.2 StandAlone模式的部署
StandAlone模式是单机模式。
 将solr.war包部署到容器下。


 将solr.home文件夹部署到节点上。


 启动容器的同时指定solr.home的位置。一般使用-Dsolr.solr.home=%SOLR_HOME%方法来指定，也可以通过JNDI的方式来指定。


 启动容器之后就可以直接在浏览器中验证solr的部署情况了。


2.3 SolrCloud模式的部署
SolrCloud模式是以集群的方式部署Solr。集群方式基于ZooKeeper（zk）做节点的管理，允许部署主备机，自动分片（Sharding）。

 将solr.war包部署到容器下。


 将solr.home文件夹部署到节点上。



 启动容器的同时指定solr.home的位置。指定的方式和StandAlone模式一样。与之不同的是，需要指定zk服务的ip和端口，以便各节点可以通过zk来交互。

 依次启动的节点将使用zk上的集中式配置，节点的角色（leader、slave、shard）将由solr自动分配。

2.4 StandAlone与SolrCloud的核心概念
在Solr中，有几个概念是StandAlone模式与SolrCloud模式互通的。但有些概念在不同模式下的表现形式可能又有差距。

 Node 节点。 server
 Index 索引。 Index概念可以理解为由很多Document(文档)组成的Logic Index（逻辑索引）
 Collection 数据集。 从抽象上来看，Collection可以理解为一个逻辑索引在Solr里的表现，以及被索引的数据。
 Core 核心。 从抽象上来看，Core可以理解为一个Node上的一个管理一个逻辑索引的实例。
2.4.1 StandAlone模式中的概念
在单节点的情况下，一个Core，装载了一个单一的Index，组成一个单一的Collection，如果你想要多个索引，则必须有多个核心。solr 1.3以后支持在一个solr实例中运行多个核心，这为管理多个索引提供了方便快捷的处理方式，而不是尝试去启动多个solr实例。

2.4.2 SolrCloud模式中的概念
 Shard 分片。 在SolrCloud模式中，数据可以被按照某种算法切分而分布到不同的节点上，从而实现负载的分发。但是SolrCloud中分片数量是预定义的，不支持动态扩展，这种实现方式意味着如果分片数量想要增加，则必须停机修改配置，然后把所有数据全部重新索引一次，以便分布到正确的节点上。
 Replication 复制。 SolrCloud提供简单的数据冗余以增加Fault Tolerance（容错性）和High Availability（HA、可用性）。某个Shard下可以有多个节点提供服务，其中的某个节点将会成为leader，其他的节点成为Replication提供冗余服务，数据通过log的形式在节点之间进行同步。
 Leader 主机。 分片以后的集群，将有多个节点装载同一个分片的数据，但是这些节点中只有一个节点为主节点，负责处理例如写请求这样的请求，这个主节点就叫Leader。Leader由多个节点选举产生，选举算法由zk提供支持，这里不多做介绍。

在SolrCloud模式下，一个Index、Collection将由分布在多个节点上的多个Core组成，这是与StandAlone模式的一大不同。

2.5 SolrCloud中的一些机制
集群模式的Solr提供的服务与单机相比，主要区别在于数据是分布式的，存储在多个节点上，这样的机制使得整个集群向外暴露的服务具有一定的容错性、高可用性。
2.5.1 分布式集群的管理
Solr 集群依赖于ZooKeeper提供的管理服务，其中包括：
 集中式的配置中心。 Solr中的所有配置将在第一个Solr节点启动的时候上传到zk，以后的启动，如果不需要修改配置，则不需要提供任何额外的参数，直接从zk中读取配置。
 节点状态管理。 zk提供心跳服务，可以随时监控集群中节点的健康状况。每一个节点连接上zk时将创建一个EPHEMERAL（临时）的节点，当节点宕机失去联系，节点将消息，而其他监听的节点将收到消息。
 选举服务。 zk提供简单的选举支持，Solr分片中的Leader由此而来。

2.5.2 配置文件的管理
Solr的配置文件存储在zk上，所以要求第一个节点第一次启动的时候需要上传配置文件。
如果配置文件需要修改，则需要从zk上down下来，修改完之后再手动上传。
这里需要正确理解配置文件与core的关系。配置文件与core并不是绑定的关系，二者是独立的，可以独立管理。core只是简单的引用被上传的配置文件。

2.5.3 数据路由机制
集群存在的一大意义就是分散系统的负载，其中一个核心问题就是：数据是如何分布的。
SolrCloud里提供两种数据分布的策略：
 hash 分布。根据索引请求中的documentId做简单的hash分布，分布到预定义的shardNum分片里。
 根据特征前缀分布。将具有特定前缀的documentId分布到预定义的shard里
2.5.4 请求路由机制
SolrCloud的客户端是轻量级的客户端，并不负责计算数据分布，而是简单的将请求发送到集群，由集群来决定由哪个节点来处理请求。
SolrCloud也允许请求中限定处理请求的shard，既只需要搜索部分数据。
 读请求
读请求比较简单，只需要被转发到每个shard，搜索后将结果组装成为响应，然后返回。

 写请求
     客户端从zk中获取到一个节点的地址
     如果这个节点是一个replica，请求被转发到leader
     如果这个节点是leader，则计算出正确的shard，转发到正确的shard-leader
     请求到了正确的leader，索引之，并将数据同步到此shard上所有的replica
2.5.5 集群的读写容错性
 读容错性
默认情况下，一个搜索请求需要搜索所有的shard，然后将各个shard上搜索的结果合并形成一个完整的数据集作为响应。如果某个shard上的搜索任务失败了，那么整个请求都将失败，这种策略将浪费在其他shard上已经消费的计算能力，所以Solr允许返回部分搜索结果，忽略失败的部分。需要显示声明shards.tolerant=true。如果出现了部分失败的情况，返回结果里将出现一个标识"partialResults": true。
 写容错性
Solr 使用transaction log进行leader与replica之间的数据同步，当leader宕机了，replica将重新选举出一个拥有最新版本数据的节点成为leader，由于transaction log的存在，可以最大范围的保证数据的安全。