Solr分布式索引SolrCloud原理总结
Solr分布式索引SolrCloud原理总结
低调的糊涂虫 发表于2年前
Solr分布式索引SolrCloud原理总结
  • 发表于 2年前
  • 阅读 155
  • 收藏 0
  • 点赞 0
  • 评论 0

新睿云服务器60天免费使用,快来体验!>>>   

摘要: SolrCloud分布式原理介绍

[原]Solr分布式索引SolrCloud原理总结


概要

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信息进行监听,近实时进行处理。


创建索引

  1. 任意节点(leader节点或者非leader节点)接收创建索引请求后,将请求参数转化成json格式存储至zookeeper的/overseer/collection-queue-work的children节点上

  2. leader 节点的OverseerCollectionProcessor线程一直在监控/overseer/collection-queue-work节点,检 测到变化后,根据请求参数计算出需要创建的shard, replica,将创建具体replica的请求转向各对应节点。

  3. 各节点创建完具体的replica后,将该节点的状态(创建成功与否等)更新到/overseer/queue的children节点上。

  4. leader节点的ClusterStateUpdater线程监控/overseer/queue节点,将overseer/queue的children节点的状态更新至/clusterstate.json。

  5. 各节点同步/clusterstate.json,整个集群状态得到更新,新索引创建成功。


更新索引数据

  1. solr根据add doc数据创建出AddUpdateCommand,由DistrubutedUpdateProcessor.processAdd处理。

  2. 根据router规则计算出该doc所属shard并找出该shard对应的leader replica。

  3. 如果当前replica(接收add doc命令的replica)不是(所属shard且leader replica),将请求转出至对应leader replica。

  4. 如果当前replica是对应shard且是leader,首先更新本地索引,再将add doc转向该shard的其余replica。

  5. 所有replica得到更新。


检索流程

  1. 搜索流程中,solr实例不区分是否为leader状态。任意replica接收搜索请求时,从zookeeper中获取改replica对应的collection及所有的shard和replica。

  2. 将请求同时发送向该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处复制来完整的数据。




主要类介绍

  • CollectionsHandler 操作collection、replica、alias、shard创建、删除的入口

  • OverseerCollectionProcessor 仅在Leader节点上起作用,负责监控zookeeper,处理和collection相关的任务

  • ClusterStateUpdater 仅在leader节点上起作用,负责监控/overseer/queue和/overseer/queue-work

  • LBHttpSolrServer solr实现的负载均衡类,在某shard存在多个replica时使用


参考


  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
粉丝 1
博文 33
码字总数 9521
×
低调的糊涂虫
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: