Solr分布式索引SolrCloud原理总结

最新推荐文章于 2024-05-30 11:15:49 发布

threeidiots

最新推荐文章于 2024-05-30 11:15:49 发布

阅读量6.8k

点赞数

本文链接：https://blog.csdn.net/threeidiots/article/details/41317743

版权

概要

Solr从4.0开始支持solrcloud模式，主要特性有：

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

在solr4-10.2源码和官方wiki中多次出现collection、shard、replica，collection指一个完整的索引，当索引数据量太大时，需要拆分成多个shard，shard代表子索引，为了增加并发请求能力和保证数据完整性，一个shard可以存在多份完全一致的副本，这些副本便是replica。

在solrcloud的众多solr服务中，solr分两种角色，leader和非leader，当solr实例数量发生变化时会重新进行选举leader。在使用solrcloud时，其中的shard和replica对于我们是透明的，且任何一台机器都可以接受查询、修改、删除请求，创建collection、shard、replica，更新索引等数据修改操作只能由leader进行，避免产生并发修改问题，当非leader节点收到修改操作请求时，要将请求信息存储在zookeeper中相应节点上，leader节点对该zookeeper信息进行监听，近实时进行处理。

创建索引

任意节点（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，整个集群状态得到更新，新索引创建成功。

更新索引数据

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得到更新。

检索流程

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

增加、减少solr实例

在创建索引时，会指定索引分成几个shard，每个shard生成多少replica，且每个solr实例上最多允许创建的replica数目。只有在所有solr实例允许创建的replica总数大于需要的replica数时才会创建成功。

当索引创建成功后，停掉某台solr，若该solr含有所创建的索引的replica，则某个shard的replica会减少，更新集群状态/clusterstate.json。此时增加一台新solr实例并连接上相同的zookeeper，会自动在该solr上创建失去的replica并从leader处复制来完整的数据。