Solr10-SolrCloud的基本概念及其结构说明

1 什么是SolrCloud

SolrCloud是基于Solr和ZooKeeper的分布式搜索方案, 主要通过ZooKeeper作为集群的配置信息中心.

当你需要处理大规模数据的搜索, 并需要提供高可用、容错等方面的支持, 且具有分布式索引和检索能力的服务时, 可以考虑使用SolrCloud.

SolrCloud有下述几个特色:

(1) 集中式的配置信息;

(2) 自动容错;

(3) 近实时搜索;

(4) 查询时自动负载均衡.

2 SolrCloud的结构

SolrCloud为了降低单机的处理压力, 需要由多台服务器共同完成索引和搜索任务. 实现思路是将索引数据进行Shard(分片)拆分, 每个分片由多台服务器共同完成, 当客户端发起一个索引或搜索请求时, 并行地由各个Shard服务器进行相关的索引操作, 然后返回总的结果集.

SolrCloud需要多台服务器, 配置文件较多, 因而交由ZooKeeper协调管理SolrCloud.

下图是一个SolrCloud应用的例子, 以此图为例说明SolrCloud的结构:

SolrCloud的结构

2.1 物理结构

三台服务器(或同一服务器, 通过伪集群的方式提供服务)用来部署Solr实例, 每个实例包括两个Solr Core(包括完整的索引和检索服务), 组成一个SolrCloud.

2.2 逻辑结构

索引集合包括两个Shard(Shard1和Shard2), Shard1和Shard2分别由三个Core组成, 其中一个Leader两个Replication, Leader是由ZooKeeper选举产生, ZooKeeper负责每个Shard上三个Core的索引数据的一致性, 解决高可用问题.

用户发起的索引请求将分别从Shard1和Shard2上并行获取, 解决高并发问题.

2.2.1 Collection(集合)

Collection在SolrCloud集群中是一个逻辑意义上的完整的索引结构;

作为集群的访问入口, 用于区分不同的索引库;

它们使用相同的配置信息, 常被划分为一个或多个Shard(分片), 可以跨Node存在.

2.2.2 Shard(分片)

Shard是Collection的逻辑分片, 也可以跨Node.

每个Shard被分为一个或多个Replication(副本):

1个Shard有且只能有一个Leader;

1个Shard可以有0个或多个Replica;

如果Shard下的Leader宕机, Solr内部会发起选举, 从活跃的Replica中选出一个作为新的Leader.

各个Shard中存储的数据是互不重复的, 即它们的交集为空;

所有Shard的并集 == Collection中的所有文档;

同一Shard下的Replica(包括Leader)存储的数据相同, 即冗余副本, 提供高可用.

2.2.3 Core(内核)

Core是Solr中独立运行的单位, 提供索引和搜索服务:

在SolrCloud模式下, 同一Collection的所有Core的配置都相同;

一个Shard由一个(或多个)Core组成, 类似于collection_shard1_replica2;

Collection一般由多个Shard组成 ==> Collection一般由多个Core组成;

Core承担 Leader或Replica角色, 是由Solr内部自动协调决定的.

2.2.4 Master/Slave(主/从)

Master是master-slave结构中的主节点(通常说主服务器), Slave是从节点(通常说从服务器或备服务器).

同一个Shard下Master和Slave存储的数据是一致的, 这是为了达到高可用目的.

版权声明

作者: ma_shoufeng(马瘦风)

出处: 博客园 马瘦风的博客

您的支持是对博主的极大鼓励, 感谢您的阅读.

本文版权归博主所有, 欢迎转载, 但未经博主同意必须保留此段声明, 且在文章页面明显位置给出原文链接, 否则博主保留追究法律责任的权利.

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpypwd.html