本文链接: http://quentinXXZ.iteye.com/blog/2149891
上一周,对公司搜索引擎工作流程的做改造工作。涉及到不同角色服务器之间的沟通工作。我们试图应用zookeeper到我们的场景,实现应用模块之间的解耦。本文深入到solr源码,从中掘金,看看solr是如何使用zookeeper的。
在做本次改造的时候,公司同事对于zookeeper的使用,提供了很好的建议,其中一个重要原则就是“谁创建,谁修改”,也就是各个服务应用自己创造自己的结点,自己去修改配置自己的最新状态。一般情况下,对结点的修改是结点的创建者,而不应该是其它对些结点数据的关注者,不然会增加操作复杂度与不确定性。
在阅读solr源码会发现,solr对zookeeper的使用,使用的是另一种思想,虽然增加了复杂度,但更适用于cloud中各结点角色不确定的场景。
这里涉及的相关代码,主要在package org.apache.solr.cloud中。
说明
本人一开始阅读的是4.4的版本的代码,最新的是4.10.1, 后来简单看了一下最新代码,没有发现多少变动。
别看我在这里一本正经地给大家作源码分析,但毕竟一个人看,总有疏漏的地方,存在理解不当的地方,如果错误,请大家指正。
solr在zookeeper中的结点
1、aliases.json 对colletion别名,另有妙用(solrcloud的build search分离),以后再写博客说明。
2、clusterstate.json 重要信息文件。包含了colletion ,shard replica的具体描述信息。
3、live_nodes ,下面都是瞬时的zk结点,代表当前存活的solrcloud中的节点。
4、overseer, solrcloud中的重要角色。下面存有三个重要的分布式队列,代表待执行solrcloud相关的zookeeper操作的任务队列。collection-queue-work是存放与collection相关的特办操作,如createcollection ,reloadcollection,createalias,deletealias ,splitshard 等。
5、queue则存放了所有与collection无关的操作,例如deletecore,removecollection,removeshard,leader,createshard,updateshardstate,还有包括节点的状态(down、active、recovering)的变化。
6、queue-work是一个临时队列,指正在处理中的消息。操作会先保存到/overseer/queue,在overseser进行处理时,被移到/overseer/queue-work中,处理完后消息之后在从/overseer/queue-work中删除。如果overseer中途挂了,新选举的overseer会选将/overseer/queue-work中的操作执行完,再去处理/overseer/queue中的操作。
注意:以上队列中存放的所有子结点,都是PERSISTENT_SEQUENTIAL类型的。
7、overseer_elect ,用于overseer的选举工作
8、colletcion,存放当前collection一些简单信息(主要信息都在clusterstate.json中)。 下面的leader_elect自然是用于collection中shard中副本集的leader选举的。
Overseer 的zk写流程
在看solrcloud的官方文档的时候,几乎也很少有overseer的这个角色的说明介绍。相信不少成功配置solrcloud的开发者,也没有意识到这个角色的存在。
Overseer,顾名思义,是一个照看全局的角色,做总控工作。体现在代码与zk的相关操作中,就是zookeeper中大多的写操作,是由overseer去处理的,并且维护好clusterstate.josn与aliases.json这两个zk结点的内容。与我们“谁创建,谁修改”做法不同。由各个solr node发起的操作,都会publish到/overseer结点下面相应的queue中去,再由overseer去些分布式队列中去取这些操作信息,做相应的zk修改,并将整个solrcloud中相关的具体状态信息,更新到cluseterstate.json中去,最终会将个操作,从queue中删除,表示完成操作。
以一个solr node将自身状态标记为down为例。该node会将这种“state”operation的相关信息,publish到/overseer/queue中。由Overseer去从中取得这个操作,然后将node state为down的信息写入clusterstate.json。最后删除queue中的这个结点。
当然overseer这个角色,是利用zookeeper在solrcloud中内部选举出来的。
一般的zk读操作
Solr将最重要且信息最全面的内容都放在了cluseterstate.json中。这样做减少了,普通solr node需要关注的zk 结点数。除了clusterstate.json,普通的solr node在需要当前collection整体状态的时候,还会获取zk的/live_nodes中的信息,根据live_nodes中的信息,得知collection存活的node, 再从clusterstate.json获得这些node的信息。
这种处理,其实也好理解。假如一个solr node非正常下线,clusterstate.json中不一定会有变化,但/live_nodes中这个node对应的zk结点就消失了(因为是瞬时的)。
总结
看过这部份原码后,跟同事讨论了一下。Solr对zookeeper的这种使用方法,比角色分明集群系统,确实复杂得多。但solr为达到群集自感知,高可用,最终形成cloud的效果,内部的角色是动态变化的,所以大家需要一个统一管理的角色。而使用分布式队列,由一个overseer统一处理操作的好处,在于保证了操作的有序,这点也很重要。将最要信息集中在clusterstate.json的作法,减少了其他solr node对zk的关注逻辑的复杂度。
相关推荐
solrcloud5结合zookeeper搭建、使用详解,是一部难得的好教程
solrcloud与zookeeper
该项目旨在帮助在Docker环境中尝试最新版本SolrCloud(和Zookeeper)的开发人员和新手。 此项目的版本完全基于较新的Solr和Zookeeper官方图像。 先决条件 Mac-OS或Linux环境 泊坞窗最新版本- 多克尔-撰写最新...
Win7 下面 安装solrCloud5.2.1 + tomcat7 + zookeeper3.4.6 集成。 有安装步骤,裁图和说明 1分物超所值 哈哈
该项目旨在帮助在Kubernetes环境中尝试使用最新版本的SolrCloud(和Zookeeper)的开发人员和新手。 在这里,您将发现基本上两种不同的配置: 一个(或多个)Solr实例和一个Zookeeper配置为“独立”节点 一个(或多...
solrcloud部署;作者:家和一定万事兴; 参考文章:2014-02-19,于测试机器上部署solrcloud;
solr-6.2.0 强大的分布式搜索引擎,包含各种详细例子及源码解析
solr全文检索,里面包含文档,源代码,jar包,使用的是solr4.2,东西比较全,安装文档就能跑起来,,适合参考借鉴
SolrCloud使用 SolrCloud的集合(SolrCores)管理API 添加集合 http://localhost:8080/solr/admin/collections?action=CREATE&name=mycollection&numShards=1&replicationFactor=4 ...
solr6.6.0源码
本人用ant idea命令花了214分钟,35秒编译的lucene-solr源码,可以用idea打开,把项目放在D:\space\study\java\lucene-solr路径下,再用idea打开就行了
Solr,SolrCloud, Windows, Tomcat, Apache 在Windows操作系统上进行Solr的云安装与配置
Solr的安装部署包,只能分卷上传,稍后上传依赖jar包,及部署攻略
solr4.9+tomcat+zookeeper集群
SolrCloud集群搭建和使用步骤
solr zookeeper solrcloud 描述solr 使用的初级详细教程原版
为三台远程Linux服务器搭建SolrCloud 本次目的是在tomcat以及zookeeper的基础上,搭建三台远程服务器的SolrCloud 工具:WinSCP,SecureCRT,apache-tomcat-...此处我们使用的是Solr-4.10.4,因而采用Zookeeper-3.4.6.
SolrCloud是Solr4.0版本以后基于Solr和Zookeeper的分布式搜索方案。SolrCloud是Solr的基于Zookeeper一种部署方式。Solr可以以多种方式部署,例如单机方式,多机Master-Slaver方式。
详细阐述Solr-search 源码级别过程
ZooKeeper实例 + Solr(tomcat)集群部署