SolrCloud分布式企业搜索引擎架构原理解析

前言

在企业系统架构中，使用到了分布式文档搜索引擎Solr，这儿作一个简单的知识整理。

SolrCloud分布式企业搜索引擎架构原理解析

1、关于SolrCloud

Lucene 是一个Java语言编写的利用倒排原理实现的文本检索类库；而Solr则是以Lucene为核心来实现的企业级文本检索应用服务。Solr 部署方式有单机方式、多机Master-Slaver方式、Cloud方式。

SolrCloud 则是 Solr4.x 版本以后加入的基于 Solr 和 Zookeeper 的分布式搜索解决方案。SolrCloud 是 Solr 基于 Zookeeper 作为集群的配置信息中心的一种部署方式。Solr 可以以多种方式部署，例如：单机方式，多机Master-Slaver方式。

关于Zookeeper的原理及其优点，请参考【 Eureka 与 zookeeper 的区别、原理及各自优缺点 】

2、SolrCloud 特点

1）、集中式的配置

所有配置信息使用 Zookeeper 进行集中管理。启动时可以指定把 Solr 的相关配置文件上传 Zookeeper，跨主机共享。这些 Zookeeper 中的配置不会再拿到本地缓存，Solr 直接读取 Zk 中的配置信息。配置文件的变动，所有机器都可以感知到。另外，Solr 的一些任务也是通过 Zk 作为媒介发布的。目的是为了容错。接收到任务，但在执行任务时崩溃的机器，在重启后，或者集群选出候选者时，可以再次执行这个未完成的任务。

2）、自动容错（高可用）

SolrCloud 对索引进行分片，并对每个分片创建多个 Replication。每个 Replication 都可以对外提供服务。一个 Replication 挂掉不会影响整体的索引服务。更强大的是，它还能自动的在其它机器上帮你把失败机器上的索引 Replication 重建并投入使用。

3）、实时性

近实时搜索立即推送式的 replication（也支持慢推送，可配置）。可以在秒内检索到新加入索引。

4）、负载均很LB

查询时自动负载均衡SolrCloud索引的多个Replication可以分布在多台机器上，均衡查询压力。如果查询压力大，可以通过扩展机器，增加Replication来减缓。

5）、自动分发

自动分发的索引和索引分片发送文档到任何节点，它都会转发到正确节点。

6）、日志跟踪

事务日志事务日志确保更新无丢失，即使文档没有索引到磁盘。

7）、RESTful API

强大的RESTful API通常你能想到的管理功能，都可以通过此API方式调用。这样写一些维护和管理脚本就方便多了。

8）、可视化操作

优秀的管理界面主要信息一目了然；可以清晰的以图形化方式看到SolrCloud的部署分布；当然还有不可或缺的Debug功能。

2、Solr集群体系架构

物理结构层组成：

1）、Solr

三个 Solr 实例，每个实例包括两个Core，组成一个SolrCloud（随着业务流量的提升，灵活扩展Solr实列）。

2）、Core

每个 Core 是 Solr 实例中一个独立的运行单位，提供文档索引和搜索服务。

3）、Zookeeper

Zookeeper 在整个SolrCloud 集群中扮演了分布式锁的角色，对SolrCloud是必须的。由Zookeeper来确定 Leader 选举。Solr 可以以内嵌的 Zookeeper 运行，但是建议用独立的，并且最好有3个以上的主机。
 

逻辑结构层组成：
1）、Collection

Collection 在 SolrCloud 集群中是一个逻辑意义上的完整的索引结构。它常常被划分为一个或多个Shard（逻辑分片），它们使用相同的Config。如果Shard数超过一个，它就是分布式索引，SolrCloud让你通过Collection名称引用它，而不需要关心分布式检索时需要使用的和Shard相关参数。

比如：针对商品信息搜索服务可以创建一个Collection：

 Collection = Shard-01 + Shard-02 + ... + Shard-N
2）、Shard

Collection 的逻辑分片。每个 Shard 被拆分成一个或者多个 replication，通过指定的某种选举机制来确定哪个是Leader。一个 Shard 需要由一个 Core 或多个 Core 组成。而 Collection 则一般由多个 Core 组成。

3）、Master/Slave

Master：是 Master-Slave 结构中的主结点；

Slave：是Master-slave结构中的从结点；

在同一个 Shard 下 Master 和 Slave 存储的数据是一致的，其目的为实现服务的高可用（何为高可用，就是在一个 Shard下，当 Master 节点挂掉后，某个 Slave 通过指定的选举机制，顶上来成为 Master，使服务正常运行，而不会出现服务访问中断的现象）。

参考文档（老版本）：【Solr4.10参考指南】<-这个版本已经在官方找不到了

参考文档（新版本）：【Solr8.1参考指南】

 好了，关于 SolrCloud分布式企业搜索引擎架构原理解析 就写到这儿了，如果还有什么疑问或遇到什么问题欢迎扫码提问，也可以给我留言哦，我会一一详细的解答的。 
歇后语：“ 共同学习，共同进步 ”，也希望大家多多关注CSND的IT社区。