符合中小企业对网站设计、功能常规化式的企业展示型网站建设
本套餐主要针对企业品牌型网站、中高端设计、前端互动体验...
商城网站建设因基本功能的需求不同费用上面也有很大的差别...
手机微信网站开发、微信官网、微信商城网站...
SolrCloud中zookeeper如何使用,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
成都创新互联是一家集网站建设,金溪企业网站建设,金溪品牌网站建设,网站定制,金溪网站建设报价,网络营销,网络优化,金溪网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
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结点就消失了(因为是瞬时的)。
关于SolrCloud中zookeeper如何使用问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注创新互联行业资讯频道了解更多相关知识。