SolrCloud架构

原文链接  https://blog.csdn.net/dingzfang/article/details/42804489

1 核心概念

Collection Shard 均为逻辑上的概念 Core为物理上真实存在

  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,每个SolrCore可以独立提供索引和查询功能,每个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个以上的主机。

 

2.总体架构

3.内部结构

 

4.Shard结构

 

5.索引的创建

 

 

分布式索引的过程如下:

1.用户可以把创建文档索引的请求提交给任一个Replica或Leader

2.如果它不是Leader,它会把请求转交给和自己同Shard的Leader

3.Leader把文档路由给本Shard的每个Replica,各自做索引

4.如果文档基于路由规则并不属于本Shard,Leader会把它转交给该文档对应Shard的Leader

5.对应的Leader会把文档路由给本Shard的每个Replica,各自做索引

 

6.搜索

分布式搜索过程如下:

1.用户的一个查询请求,可以发送到含有该Collection的任意机器,Solr的内部处理逻辑会转到一个Replica

2.此Replica会基于查询索引的方式,启动分布式查询,基于索引的Shard个数,把查询转换为多个子查询,并把每个子查询定位到对应Shard的任意一个Replica

3.每个子查询返回查询结果

4.最初的Replica合并每个子查询的查询结果,并把最终结果返回给用户

 

7.自动shard

 

 

索引的自动shard-split过程如下:

在一个Shard中的索引文档达到阀值时,或者接收到用户的shard-split的API命令,就可以启动shard分裂过程。此时,旧的shard仍然提供服务,旧shard上的现有索引文档,会再次提取并按照路由规则,转到新的shard上再次进行索引。同时,对于新加入的索引文档,会按照如下步骤进行:

1.用户可以把创建文档索引的请求提交给任一个Replica或Leader

2.如果它不是Leader,它会把请求转交给和自己同Shard的Leader

3.Leader将索引文档路由给本Shard的每个Replica,各自做索引

4,6.在一个Shard中的索引文档达到阀值时,或者接收到用户的shard-split的API命令,就可以启动shard分裂过程。此时旧的shard的Leader会将索引文档路由给新的shard的Leader

5,7.新的shard的Leader会将索引文档路由给本Shard的每个Replica,各自做索引

 

在旧的索引文档重新索引完成后,系统会把分发文档的路由切换到对应的新的Leader上,旧Shard关闭

posted @ 2018-08-24 10:19  wdmiye  阅读(272)  评论(0编辑  收藏  举报