SolrCloud原理

最新推荐文章于 2019-10-11 14:42:11 发布

卤蛋的天空

最新推荐文章于 2019-10-11 14:42:11 发布

阅读量339

点赞数

CC 4.0 BY-SA版权

分类专栏： solr

本文链接：https://blog.youkuaiyun.com/zshaowoo/article/details/86291630

solr 专栏收录该内容

7 篇文章

订阅专栏

SolrCloud提供配置文件集中存储、负载均衡和故障恢复等功能。它将索引拆分成多个Shard，每个Shard有多个Replica，通过选举确定Leader。创建索引和更新数据操作由Leader处理，其他节点通过Zookeeper协调。检索时，任意节点可接受请求，实现分布式查询。增加或减少Solr实例，集群状态会自动调整。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 主要特性

配置文件集中式存储，集群中的配置文件存储在zookeeper中，仅保存一份，而过去是每个core一份配置文件，非常容易导致不一致
负载均衡和故障恢复，自动将流量分配到各台机器上，不再需要nginx或haproxy的支持，自动剔除故障机器

2. 原理

collection指一个完整的索引，当索引数据量太大时，需要拆分成多个shard，shard代表子索引，为了增加并发请求能力和保证数据完整性，一个shard可以存在多份完全一致的副本，这些副本便是replica。
在solrcloud的众多solr服务中，solr分两种角色，leader和非leader，当solr实例数量发生变化时会重新进行选举leader。在使用solrcloud时，其中的shard和replica对于我们是透明的，且任何一台机器都可以接受查询、修改、删除请求，创建collection、shard、replica，更新索引等数据修改操作只能由leader进行，避免产生并发修改问题，当非leader节点收到修改操作请求时，要将请求信息存储在zookeeper中相应节点上，leader节点对该zookeeper信息进行监听，近实时进行处理。

3.SolrCloud配置

有两种方式：
（1）把solr作为web应用部署到Tomcat容器，然后Tomcat与zookeeper关联
（2）从solr 5开始， solr自身有jetty容器，不必部署到Tomcat，这样会容易一些。

4.SolrCloud基础知识概念

Collection：在SolrCloud集群中逻辑意义上的完整的索引。它常常被划分为一个或多个Shard，它们使用相同的Config Set。如果Shard数超过一个，它就是分布式索引，SolrCloud让你通过Collection名称引用它，而不需要关心分布式检索时需要使用的和Shard相关参数。
ConfigSet: 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个以上的主机。
SolrCor：单机运行时，单独的索引叫做SolrCor，如果创建多个索引，可以创建的多个SolrCore。
索引：一个索引可以在不同的Solr服务上，也就是一个索引可以由不同机器上的SolrCore组成。不同机器上的SolrCore组成逻辑上的索引，这样的一个索引叫做Collection，组成Collection的SolrCore包括数据索引和备份。
SolrCloud collection shard关系：一个SolrCloud包含多个collection，collection可以被分为多个shards，每个shard可以有多个备份（replicas），这些备份通过选举产生一个leader，
Optimization：是一个进程，压缩索引和归并segment，Optimization只会在master node运行，
Leader 和 replica
（1） leader负责保证replica和leader是一样的最新的信息
（2）replica 被分到 shard 按照这样的顺序：在集群中他们第一次启动的次序轮询加入，除非新的结点被人工地使用shardId参数分派到shard。
人工指定replica属于哪个shard的方法：
```
This parameter is used as a system property, as in -DshardId=1, the value of which is the ID number of theshard the new node should be attached to.
```
以后重启的时候，每个node加入之前它第一次被指派的shard。 Node如果以前是replica，当以前的leader不存在的时候，会成为leader。

5.创建索引

任意节点（leader节点或者非leader节点）接收创建索引请求后，将请求参数转化成json格式存储至zookeeper的/overseer/collection-queue-work的children节点上
leader节点的OverseerCollectionProcessor线程一直在监控/overseer/collection-queue-work节点，检测到变化后，根据请求参数计算出需要创建的shard, replica，将创建具体replica的请求转向各对应节点。
各节点创建完具体的replica后，将该节点的状态（创建成功与否等）更新到/overseer/queue的children节点上。
leader节点的ClusterStateUpdater线程监控/overseer/queue节点，将overseer/queue的children节点的状态更新至/clusterstate.json。
各节点同步/clusterstate.json，整个集群状态得到更新，新索引创建成功。

6.更新索引数据

solr根据add doc数据创建出AddUpdateCommand，由DistrubutedUpdateProcessor.processAdd处理。
根据router规则计算出该doc所属shard并找出该shard对应的leader replica。
如果当前replica（接收add doc命令的replica）不是（所属shard且leader replica），将请求转出至对应leader replica。
如果当前replica是对应shard且是leader，首先更新本地索引，再将add doc转向该shard的其余replica。
所有replica得到更新。

7.检索流程

搜索流程中，solr实例不区分是否为leader状态。任意replica接收搜索请求时，从zookeeper中获取改replica对应的collection及所有的shard和replica。
将请求同时发送向该collection的所有shard上，对同一shard下的多replica进行负载均衡，在LBHttpSolrServer 中实现。

8.增加、减少solr实例

在创建索引时，会指定索引分成几个shard，每个shard生成多少replica，且每个solr实例上最多允许创建的replica数目。只有在所有solr实例允许创建的replica总数大于需要的replica数时才会创建成功。
当索引创建成功后，停掉某台solr，若该solr含有所创建的索引的replica，则某个shard的replica会减少，更新集群状态/clusterstate.json。此时增加一台新solr实例并连接上相同的zookeeper，会自动在该solr上创建失去的replica并从leader处复制来完整的数据。