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

 

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

                             ----------shard1  leader

                             ----------shard1  replica

collection----{    

                              ---------shard2  leader

                              ---------shard2  replica

简单架构如上，该集群有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处理。collectionshandler将待创建的collection的基本信息（传入的参数）组装成一个zookeeper节点对象，并将该节点信息写入zookeeper的队 列。当写入zookeeper成功后，该创建或删除collection的请求将返回请求者“成功”的消息。

 

2.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的操作流程也遵循同样的处理过程。

 

solr4.x OverSeer （二）：ClusterState update 消息

此主要介绍OverSeer中除collection外的另一类重要消息：ClusterState Update message。这类消息的典型样子：

{"shard":"shard1", "roles":null, "state":"active", "core":"core4", "collection":"collection4", "node_name":"x.x.x.253:8983_solr", "base_url":"http://x.x.x.253:8983/solr"}

该消息的意思是一个更新solr  节点状态的消息。OverSeer在读取该消息后修改zookeeper上clusterstate.json文件collection4的shard1 的replica状态信息。该信息表明节点“x.x.x.253:8983_solr”的“state”为“active”。这个active是该消息中 最重要的信息。 下面一几个问题来描述这些消息。

 

1.谁什么时候会向zookeeper发送这类消息？

各个solr  node都会向zookeeper发送该类消息。solr节点中的每个core都会发送消息。发送消息的时间主要是该core的状态发生变化的时候。调用 ZkCotroller.publish()函数向zookeeper发送状态消息，本文中以publish（“active”）表示发送状态为 “active”的core状态更新消息。 

几个主要core状态有：

active //core状态正常，正常服务中处于该状态

down //core当前不可用，不能正常服务 

recovering //core正在做recovering，该状态将影响updateLog 

recavery_failed //core尝试recoverey失败

leader消息是在上面core的状态消息的基础上加上“leader”项：

{"shard":"shard1", "roles":null, "state":"active", "core":"collectionp0", "collection":"collectionp0", "node_name":"x.x.x.253:8983_solr", "base_url":"http://x.x.x.253:8983/solr", "leader":"true"}

 

2.消息保存在哪里？

消息同样保存在zookeeper的/overseer/queue队列里。正在处理中的消息将被移动到/overseer/queue-work队列中，处理完后消息将从/overseer/queue-work中删除

 

3.谁来处理，怎么处理？

OverSeer有两个线程，分别为OverSeerCollectionProcessor和ClusterStateUpdatater。前者 为处理Collection相关的消息，如创建、删除和Unload  Collection的消息。后者即为处理clusterstate的线程。   ClusterStateUpdatater对消息的处理主要就是修改zookeeper上的clusterstate.json文件。将queue中的消息移到queue-work中，根据消息修改clusterstate.json，修改成功则删除queue-work中的对应消息。

 

 

------------------------------------------------------------------------------------

Solrcloud 中 shard leader的选举

1。每个shard进入集群后，会在zookeeper上注册一个序列号类似，n_0000000001 or n_0000000003，最先进的序列号最小

2。leader挂掉后，首先调用setup方法保证选举初始化，主要是保证写在zookeeper上的信息节点存在

3。选取最小序号的作为新leader

4。挂掉的leader重启后，序号为最大，当然其不能恢复原leader位置，而是作为follower