当前位置: 首页 > solr, 搜索 > 正文

solr4:创建、删除 collection 的消息流

关键字:
1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

unnamed01
以上图solr4.0集群为例说明,该集群有4台服务器,每台服务器上运行一个solr实例(instance)。配置为:整个集群只有一个collection为collection1,该collection有两个shard(shard1、shard2),每个shard各有一个replica。其中假设shard2-leader被选为Overseer。

create/delete collection时消息(命令)走向
当用户打算create/delete一个collection时,将向上面4台solr节点中任一节点调用collection API,例如创建一个“collection2”(假设其中一台solr节点为192.168.1.11),那么可以发送:http://192.168.1.11:8983/solr/admin/collections?action=CREATE&name=collection2&numShards=2&numReplicas=2&collection.configName=myconf. 该请求到达192.168.1.11节点上之后,由collectionshandler处理。该消息处理具体过程为:
create-collection1
这里实际上是将待创建的collection的基本信息(传入的参数)组装成一个zookeeper节点对象,并将该节点信息写入zookeeper的队列。当写入zookeeper成功后,该创建或删除collection的请求将返回请求者“成功”的消息。(创建或删除是否真能成功,后续操作的稳定性如何?后面接续分析)

zookeeper 上消息的存储情况
这节我们将分析下zookeeper上关于队列消息的存储情况,我们先看一下admin工具上看到的zookeeper先overseer节点下的路径结构:
overseer
OverSeer由solr集群中一台普通的节点担任。我们开始的图例中是低3个节点。至于由哪个节点担任OverSeer则由一套选举算法决定(该算法同时用于选举shard leader)。此处不作介绍。如上图OverSeer在zookeeper上有一个overseer节点,下面存放的是overseer会处理相关的一些消息队列。具体如下:

Queue:该队列存放新的处理消息,即所有的集群配置状态更新的消息都是先写入该队列,比如上面的collection创建的消息,就是首先写入该队列。还包括节点的状态(down、active、recovering)更新消息。

Collection-queue-work:该队列存放所有正在处理的与collection相关的消息。以上面collection创建消息为例,首先该消息写入queue队列,overseer上的OverseerCollectionProcessor线程(由overseer创建)定期访问queue队列取出与collection先关的消息,并将消息移到collection-queue-work队列,之后对该消息进行处理。如果该消息成功处理,则将该消息从collection-queue-work队列中删除。则该消息的整个生命周期结束。

Queue-work:该队列类似于collection-queue-work队列,唯一区别为处理的消息为除collection相关外的其他所有消息,由ClusterStateUpdater线程负责。

上面创建collection的例子中,最后创建collection的过程将由OverseerCollectionProcessor线程负责,目前对于该线程能否成功创建collection,还没有有效的途径能通知请求者。请求者所得到的“成功”消息,只表示请求消息已经成功放入zookeeper队列中。

除了collection的创建删除外,其他collection的操作流程也遵循同样的处理过程。

本文固定链接: http://www.chepoo.com/solr4-create-del-collection.html | IT技术精华网

solr4:创建、删除 collection 的消息流:等您坐沙发呢!

发表评论