Solr源碼掘金之 SolrCloud中的zookeeper使用分析

上一週，對公司搜索引擎工做流程的作改造工做。涉及到不一樣角色服務器之間的溝通工做。咱們試圖應用zookeeper到咱們的場景，實現應用模塊之間的解耦。本文深刻到solr源碼，從中掘金，看看solr是如何使用zookeeper的。

在作本次改造的時候，公司同事對於zookeeper的使用，提供了很好的建議，其中一個重要原則就是「誰建立，誰修改」，也就是各個服務應用本身創造本身的結點，本身去修改配置本身的最新狀態。通常狀況下，對結點的修改是結點的建立者，而不該該是其它對些結點數據的關注者，否則會增長操做複雜度與不肯定性。

在閱讀solr源碼會發現，solr對zookeeper的使用，使用的是另外一種思想，雖然增長了複雜度，但更適用於cloud中各結點角色不肯定的場景。

這裏涉及的相關代碼，主要在package org.apache.solr.cloud中。

 

說明

本人一開始閱讀的是4.4的版本的代碼，最新的是4.10.1, 後來簡單看了一下最新代碼，沒有發現多少變更。

別看我在這裏一本正經地給你們做源碼分析，但畢竟一我的看，總有疏漏的地方，存在理解不當的地方，若是錯誤，請你們指正。

 

solr在zookeeper中的結點

 

       一、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結點就消失了（由於是瞬時的）。

 

總結

看過這部份原碼後，跟同事討論了一下。Solr對zookeeper的這種使用方法，比角色分明集羣系統，確實複雜得多。但solr爲達到羣集自感知，高可用，最終造成cloud的效果，內部的角色是動態變化的，因此你們須要一個統一管理的角色。而使用分佈式隊列，由一個overseer統一處理操做的好處，在於保證了操做的有序，這點也很重要。將最要信息集中在clusterstate.json的做法，減小了其餘solr node對zk的關注邏輯的複雜度。