1、架构

经典的例子：

  SolrCloud是基于Solr和Zookeeper的分布式搜索方案，是正在开发中的Solr4.0的核心组件之一，它的主要思想是使用Zookeeper作为集群的配置信息中心。

它有几个特色功能：1）集中式的配置信息 2）自动容错 3）近实时搜索 4）查询时自动负载均衡

这是一个拥有4个Solr节点的集群，索引分布在两个Shard里面，每个Shard包含两个Solr节点，一个是Leader节点，一个是Replica节点，此外集群中有一个负责维护集群状态信息的Overseer节点，它是一个总控制器。集群的所有状态信息都放在Zookeeper集群中统一维护。从图中还可以看到，任何一个节点都可以接收索引更新的请求，然后再将这个请求转发到文档所应该属于的那个Shard的Leader节点，Leader节点更新结束完成，最后将版本号和文档转发给同属于一个Shard的replicas节点。

2、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操作的任务队列。

4.1 collection-queue-work是存放与collection相关的特办操作，如createcollection ，reloadcollection，createalias，deletealias ，splitshard 等。

4.2 queue则存放了所有与collection无关的操作，例如deletecore，removecollection，removeshard，leader，createshard，updateshardstate，还有包括节点的状态（down、active、recovering）的变化。

4.3 queue-work是一个临时队列，指正在处理中的消息。操作会先保存到/overseer/queue，在overseser进行处理时，被移到/overseer/queue-work中，处理完后消息之后在从/overseer/queue-work中删除。如果overseer中途挂了，新选举的overseer会选将/overseer/queue-work中的操作执行完，再去处理/overseer/queue中的操作。

注意：以上队列中存放的所有子结点，都是PERSISTENT_SEQUENTIAL类型的。

5、overseer_elect ,用于overseer的选举工作

6、colletcion，存放当前collection一些简单信息（主要信息都在clusterstate.json中）。 下面的leader_elect自然是用于collection中shard中副本集的leader选举的。

3、overseer：

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结点就消失了（因为是瞬时的）。

4、索引创建过程：

添加文档的过程：

（1）当SolrJ发送update请求给CloudSolrServer ，CloudSolrServer会连接至Zookeeper获取当前SolrCloud的集群状态，并会在/clusterstate.json 和/live_nodes 注册watcher，便于监视Zookeeper和SolrCloud，这样做的好处有以下几点：

CloudSolrServer获取到SolrCloud的状态后，它能直接将document发往SolrCloud的leader，降低网络转发消耗。

　　注册watcher有利于建索引时候的负载均衡，比如如果有个节点leader下线了，那么CloudSolrServer会立马得知，那它就会停止往leader发送document。

（2）路由document至正确的shard。CloudSolrServer 在发送document时候需要知道发往哪个shard，但是这里需要注意，单个document的路由非常简单，但是SolrCloud支持批量add，也就是说正常情况下N个document同时进行路由。这个时候SolrCloud就会根据document路由的去向分开存放document即进行分类，然后进行并发发送至相应的shard，这就需要较高的并发能力。

（3）Leader接受到update请求后，先将update信息存放到本地的update log，同时Leader还会给documrnt分配新的version，对于已存在的document，Leader就会验证分配的新version与已有的version，如果新的版本高就会抛弃旧版本，最后发送至replica。

（4）当只有一个Replica的时候，replica会进入recovering状态并持续一段时间等待leader重新上线，如果在这段时间内，leader没有上线，replica会转成leader并有一些文档损失。

（5）最后的步骤就是commit了，commit有两种，一种是softcommit，即在内存中生成segment，document是可见的(可查询到)但是没有写入磁盘，断电后数据丢失。另一种是hardcommit，直接将数据写入磁盘且数据可见。前一种消耗较少，后一种消耗较大。

每commit一次，就会重新生成一个ulog更新日志，当服务器挂掉，内存数据丢失，就可以从ulog中恢复。

5、查询过程：

6、容错：

（1）读

每个搜索的请求都被一个collection的所有的shards执行，如果有些shard没有返回结果，那么查询是失败的。这时候根据配置 shards.tolerant 参数，如果是true， 那么部分结果会被返回。

（2）写

每个节点的组织和内容的改变都会写入Transaction log，日志被用来决定节点中的哪些内容应该被包含在replica，当一个新的replica被创建的时候，通过leader和Transaction log去判断哪些内容应该被包含。同时，这个log也可以用来恢复。TransactionLog由一个保存了一系列的更新操作的记录构成，它能增加索引操作的健壮性，因为只要某个节点在索引操作过程中意外中断了，它可以重做所有未提交的更新操作。

假如一个leader节点宕机了，可能它已经把请求发送到了一些replica节点但是却另一些却没有发送，所以在一个新的leader节点在被选举出来之前，它会依靠其他replica节点来运行一个同步处理操作。如果这个操作成功了的话，所有节点的数据就都保持一致了，然后leader节点把自己注册为活动节点，普通的操作就会被处理。如果一个replica节点的数据脱离整体同步太多了的话，系统会请求执行一个全量的基于普通的replication同步恢复。

集群的overseer会监测各个shard的leader节点，如果leader节点挂了，则会启动自动的容错机制，会从同一个shard中的其他replica节点集中重新选举出一个leader节点，甚至如果overseer节点自己也挂了，同样会自动在其他节点上启用新的overseer节点，这样就确保了集群的高可用性。

1、架构

经典的例子：

  SolrCloud是基于Solr和Zookeeper的分布式搜索方案，是正在开发中的Solr4.0的核心组件之一，它的主要思想是使用Zookeeper作为集群的配置信息中心。

它有几个特色功能：1）集中式的配置信息 2）自动容错 3）近实时搜索 4）查询时自动负载均衡

这是一个拥有4个Solr节点的集群，索引分布在两个Shard里面，每个Shard包含两个Solr节点，一个是Leader节点，一个是Replica节点，此外集群中有一个负责维护集群状态信息的Overseer节点，它是一个总控制器。集群的所有状态信息都放在Zookeeper集群中统一维护。从图中还可以看到，任何一个节点都可以接收索引更新的请求，然后再将这个请求转发到文档所应该属于的那个Shard的Leader节点，Leader节点更新结束完成，最后将版本号和文档转发给同属于一个Shard的replicas节点。

2、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操作的任务队列。

4.1 collection-queue-work是存放与collection相关的特办操作，如createcollection ，reloadcollection，createalias，deletealias ，splitshard 等。

4.2 queue则存放了所有与collection无关的操作，例如deletecore，removecollection，removeshard，leader，createshard，updateshardstate，还有包括节点的状态（down、active、recovering）的变化。

4.3 queue-work是一个临时队列，指正在处理中的消息。操作会先保存到/overseer/queue，在overseser进行处理时，被移到/overseer/queue-work中，处理完后消息之后在从/overseer/queue-work中删除。如果overseer中途挂了，新选举的overseer会选将/overseer/queue-work中的操作执行完，再去处理/overseer/queue中的操作。

注意：以上队列中存放的所有子结点，都是PERSISTENT_SEQUENTIAL类型的。

5、overseer_elect ,用于overseer的选举工作

6、colletcion，存放当前collection一些简单信息（主要信息都在clusterstate.json中）。 下面的leader_elect自然是用于collection中shard中副本集的leader选举的。

3、overseer：

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结点就消失了（因为是瞬时的）。

4、索引创建过程：

添加文档的过程：

（1）当SolrJ发送update请求给CloudSolrServer ，CloudSolrServer会连接至Zookeeper获取当前SolrCloud的集群状态，并会在/clusterstate.json 和/live_nodes 注册watcher，便于监视Zookeeper和SolrCloud，这样做的好处有以下几点：

CloudSolrServer获取到SolrCloud的状态后，它能直接将document发往SolrCloud的leader，降低网络转发消耗。

　　注册watcher有利于建索引时候的负载均衡，比如如果有个节点leader下线了，那么CloudSolrServer会立马得知，那它就会停止往leader发送document。

（2）路由document至正确的shard。CloudSolrServer 在发送document时候需要知道发往哪个shard，但是这里需要注意，单个document的路由非常简单，但是SolrCloud支持批量add，也就是说正常情况下N个document同时进行路由。这个时候SolrCloud就会根据document路由的去向分开存放document即进行分类，然后进行并发发送至相应的shard，这就需要较高的并发能力。

（3）Leader接受到update请求后，先将update信息存放到本地的update log，同时Leader还会给documrnt分配新的version，对于已存在的document，Leader就会验证分配的新version与已有的version，如果新的版本高就会抛弃旧版本，最后发送至replica。

（4）当只有一个Replica的时候，replica会进入recovering状态并持续一段时间等待leader重新上线，如果在这段时间内，leader没有上线，replica会转成leader并有一些文档损失。

（5）最后的步骤就是commit了，commit有两种，一种是softcommit，即在内存中生成segment，document是可见的(可查询到)但是没有写入磁盘，断电后数据丢失。另一种是hardcommit，直接将数据写入磁盘且数据可见。前一种消耗较少，后一种消耗较大。

每commit一次，就会重新生成一个ulog更新日志，当服务器挂掉，内存数据丢失，就可以从ulog中恢复。

5、查询过程：

6、容错：

（1）读

每个搜索的请求都被一个collection的所有的shards执行，如果有些shard没有返回结果，那么查询是失败的。这时候根据配置 shards.tolerant 参数，如果是true， 那么部分结果会被返回。

（2）写

每个节点的组织和内容的改变都会写入Transaction log，日志被用来决定节点中的哪些内容应该被包含在replica，当一个新的replica被创建的时候，通过leader和Transaction log去判断哪些内容应该被包含。同时，这个log也可以用来恢复。TransactionLog由一个保存了一系列的更新操作的记录构成，它能增加索引操作的健壮性，因为只要某个节点在索引操作过程中意外中断了，它可以重做所有未提交的更新操作。

假如一个leader节点宕机了，可能它已经把请求发送到了一些replica节点但是却另一些却没有发送，所以在一个新的leader节点在被选举出来之前，它会依靠其他replica节点来运行一个同步处理操作。如果这个操作成功了的话，所有节点的数据就都保持一致了，然后leader节点把自己注册为活动节点，普通的操作就会被处理。如果一个replica节点的数据脱离整体同步太多了的话，系统会请求执行一个全量的基于普通的replication同步恢复。

集群的overseer会监测各个shard的leader节点，如果leader节点挂了，则会启动自动的容错机制，会从同一个shard中的其他replica节点集中重新选举出一个leader节点，甚至如果overseer节点自己也挂了，同样会自动在其他节点上启用新的overseer节点，这样就确保了集群的高可用性。