SolrCloud是基于Solr和ZooKeeper的分布式搜索方案, 主要通过ZooKeeper作为集群的配置信息中心.
当你需要处理大规模数据的搜索, 并需要提供高可用、容错等方面的支持, 且具有分布式索引和检索能力的服务时, 可以考虑使用SolrCloud.
SolrCloud有下述几个特色：
(1) 集中式的配置信息;
(2) 自动容错;
(3) 近实时搜索;
(4) 查询时自动负载均衡.
2 SolrCloud的结构SolrCloud为了降低单机的处理压力, 需要由多台服务器共同完成索引和搜索任务. 实现思路是将索引数据进行Shard(分片)拆分, 每个分片由多台服务器共同完成, 当客户端发起一个索引或搜索请求时, 并行地由各个Shard服务器进行相关的索引操作, 然后返回总的结果集.
SolrCloud需要多台服务器, 配置文件较多, 因而交由ZooKeeper协调管理SolrCloud.
下图是一个SolrCloud应用的例子, 以此图为例说明SolrCloud的结构:
三台服务器(或同一服务器, 通过伪集群的方式提供服务)用来部署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(马瘦风)
出处: 博客园 马瘦风的博客
您的支持是对博主的极大鼓励, 感谢您的阅读.
本文版权归博主所有, 欢迎转载, 但未经博主同意必须保留此段声明, 且在文章页面明显位置给出原文链接, 否则博主保留追究法律责任的权利.