solr4.0 OverSeer （一）：创建、删除 collection 的消息流

文章来源：http://www.tnove.com/?p=111

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

1. 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处理。该消息处理具体过程为：

这里实际上是将待创建的collection的基本信息（传入的参数）组装成一个zookeeper节点对象，并将该节点信息写入zookeeper的队列。当写入zookeeper成功后，该创建或删除collection的请求将返回请求者“成功”的消息。（创建或删除是否真能成功，后续操作的稳定性如何？后面接续分析）

1. zookeeper 上消息的存储情况

这节我们将分析下zookeeper上关于队列消息的存储情况，我们先看一下admin工具上看到的zookeeper先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.tnove.com/?p=111