SolrCloud之分布式索引及与Zookeeper的集成--转载
原文地址：http://josh-persistence.iteye.com/blog/2234411
一、概述
Lucene是一個(gè)Java語(yǔ)言編寫(xiě)的利用倒排原理實(shí)現(xiàn)的文本檢索類庫(kù)，Solr是以Lucene為基礎(chǔ)實(shí)現(xiàn)的文本檢索應(yīng)用服務(wù)，SolrCloud是Solr4.0版本開(kāi)發(fā)出的具有開(kāi)創(chuàng)意義的基于Solr和Zookeeper的分布式搜索方案，主要思想是使用Zookeeper作為集群的配置信息中心。也可以說(shuō)，SolrCloud是Solr的一種部署方式，除SolrCloud之外，Solr還可以以單機(jī)方和多機(jī)Master-Slaver方式進(jìn)行部署。分布式索引是指當(dāng)索引越來(lái)越大，一個(gè)單一的系統(tǒng)無(wú)法滿足磁盤需求的時(shí)候，或者一次簡(jiǎn)單的查詢實(shí)在要耗費(fèi)很多時(shí)間的時(shí)候，我們就可以使用solr的分布式索引了。在分布式索引中，原來(lái)的大索引，將會(huì)分成多個(gè)小索引，solr可以將這些小索引返回的結(jié)果合并，然后返回給客戶端。
二、Solr Cloud的基本概念
SolrCloud模式下有Cluster，Node，Collection，Shard，LeaderCore，ReplicationCore等重要概念。
1、Cluster集群：Cluster是一組Solr節(jié)點(diǎn)，邏輯上作為一個(gè)單元進(jìn)行管理，整個(gè)集群必須使用同一套schema和SolrConfig。
2、Node節(jié)點(diǎn)：一個(gè)運(yùn)行Solr的JVM實(shí)例。
3、Collection：在SolrCloud集群中邏輯意義上的完整的索引,常常被劃分為一個(gè)或多個(gè)Shard，這些Shard使用相同的Config Set，如果Shard數(shù)超過(guò)一個(gè)，那么索引方案就是分布式索引。SolrCloud允許客戶端用戶通過(guò)Collection名稱引用它，這樣用戶不需要關(guān)心分布式檢索時(shí)需要使用的和Shard相關(guān)參數(shù)。
4、?Core:?也就是Solr Core，一個(gè)Solr中包含一個(gè)或者多個(gè)Solr Core，每個(gè)Solr Core可以獨(dú)立提供索引和查詢功能，Solr Core的提出是為了增加管理靈活性和共用資源。SolrCloud中使用的配置是在Zookeeper中的，而傳統(tǒng)的Solr Core的配置文件是在磁盤上的配置目錄中。
5、Config Set: Solr Core提供服務(wù)必須的一組配置文件,每個(gè)Config Set有一個(gè)名字。最小需要包括solrconfig.xml和schema.xml，除此之外，依據(jù)這兩個(gè)文件的配置內(nèi)容，可能還需要包含其它文件,如中文索引需要的詞庫(kù)文件。Config Set存儲(chǔ)在Zookeeper中，可以重新上傳或者使用upconfig命令進(jìn)行更新，可使用Solr的啟動(dòng)參數(shù)bootstrap_confdir進(jìn)行初始化或更新。
6、Shard分片: Collection的邏輯分片。每個(gè)Shard被分成一個(gè)或者多個(gè)replicas，通過(guò)選舉確定哪個(gè)是Leader。
7、Replica: Shard的一個(gè)拷貝。每個(gè)Replica存在于Solr的一個(gè)Core中。換句話說(shuō)一個(gè)Solr Core對(duì)應(yīng)著一個(gè)Replica，如一個(gè)命名為“test”的collection以numShards=1創(chuàng)建，并且指定replicationFactor為2，這會(huì)產(chǎn)生2個(gè)replicas，也就是對(duì)應(yīng)會(huì)有2個(gè)Core，分別存儲(chǔ)在不同的機(jī)器或者Solr實(shí)例上，其中一個(gè)會(huì)被命名為test_shard1_replica1，另一個(gè)命名為test_shard1_replica2，它們中的一個(gè)會(huì)被選舉為L(zhǎng)eader。
8、?Leader:?贏得選舉的Shard replicas，每個(gè)Shard有多個(gè)Replicas，這幾個(gè)Replicas需要選舉來(lái)確定一個(gè)Leader。選舉可以發(fā)生在任何時(shí)間，但是通常他們僅在某個(gè)Solr實(shí)例發(fā)生故障時(shí)才會(huì)觸發(fā)。當(dāng)進(jìn)行索引操作時(shí)，SolrCloud會(huì)將索引操作請(qǐng)求傳到此Shard對(duì)應(yīng)的leader，leader再分發(fā)它們到全部Shard的replicas。
9、Zookeeper: Zookeeper提供分布式鎖功能，這對(duì)SolrCloud是必須的，主要負(fù)責(zé)處理Leader的選舉。Solr可以以內(nèi)嵌的Zookeeper運(yùn)行，也可以使用獨(dú)立的Zookeeper，并且Solr官方建議最好有3個(gè)以上的主機(jī)。
?
三、SolrCloud中完整索引（Collection）的邏輯圖
?
在SolrCloud模式下Collection是訪問(wèn)Cluster的入口，這個(gè)入口有什么用呢？比如說(shuō)集群里面有好多臺(tái)機(jī)器，那么訪問(wèn)這個(gè)集群通過(guò)哪個(gè)地址呢，必須有一個(gè)接口地址，Collection就是這個(gè)接口地址。可見(jiàn)Collection是一個(gè)邏輯存在的東西，因此是可以跨Node的，在任意節(jié)點(diǎn)上都可以訪問(wèn)Collection。Shard其實(shí)也是邏輯存在的，因此Shard也是可以跨Node的；?1個(gè)Shard下面可以包含0個(gè)或者多個(gè)Replication，但1個(gè)Shard下面能且只能包含一個(gè)Leader
如果Shard下面的Leader掛掉了，會(huì)從Replication里面再選舉一個(gè)Leader。??
此處需要注意的是在Solr4.0中，可以在Solr Admin GUI里面增加和刪除Core，如果Shard里最后一個(gè)Core被刪除了，Shard是不會(huì)自動(dòng)刪除的，這會(huì)導(dǎo)致集群出錯(cuò)， 而且如果Shard里面所有的Core宕機(jī)了，會(huì)導(dǎo)致不能繼續(xù)插入新的記錄，從而導(dǎo)致查詢會(huì)受到影響，其實(shí)如果一個(gè)Shard下的所有Core宕機(jī)了，SolrCloud應(yīng)該允許插入到其它存活的Shard里面，這在后期版本中的Solr中應(yīng)該會(huì)被支持。
?
?
四、SolrCloud索引操作的基本架構(gòu)圖
?
???????????????????????????????????
圖中所示為擁有4個(gè)Solr節(jié)點(diǎn)的集群，索引分布在兩個(gè)Shard里面，每個(gè)Shard包含兩個(gè)Solr節(jié)點(diǎn)，一個(gè)是Leader節(jié)點(diǎn)，一個(gè)是Replica節(jié)點(diǎn)，此外集群中有一個(gè)負(fù)責(zé)維護(hù)集群狀態(tài)信息的Overseer節(jié)點(diǎn)，它是一個(gè)總控制器。
集群的所有狀態(tài)信息都放在Zookeeper集群中統(tǒng)一維護(hù)。從圖中還可以看到，任何一個(gè)節(jié)點(diǎn)都可以接收索引創(chuàng)建或者更新的請(qǐng)求，然后再將這個(gè)請(qǐng)求轉(zhuǎn)發(fā)到索引文檔所應(yīng)該屬于的那個(gè)Shard的Leader節(jié)點(diǎn)，Leader節(jié)點(diǎn)更新結(jié)束完成后，最后將版本號(hào)和文檔轉(zhuǎn)發(fā)給同屬于一個(gè)Shard的replicas節(jié)點(diǎn)。
五、SolrCloud的工作模式
首先來(lái)看下索引和Solr實(shí)體對(duì)照?qǐng)D
?
SolrCloud中包含有多個(gè)Solr Instance,而每個(gè)Solr Instance中包含有多個(gè)Solr Core，Solr Core對(duì)應(yīng)著一個(gè)可訪問(wèn)的Solr索引資源，每個(gè)Solr Core對(duì)應(yīng)著一個(gè)Replica或者Leader,這樣，當(dāng)Solr Client通過(guò)Collection訪問(wèn)Solr集群的時(shí)候，便可通過(guò)Shard分片找到對(duì)應(yīng)的Replica即Solr Core，從而就可以訪問(wèn)索引文檔了。
?
?
在SolrCloud模式下，同一個(gè)集群里所有Core的配置是統(tǒng)一的，Core有l(wèi)eader和replication兩種角色，每個(gè)Core一定屬于一個(gè)Shard，Core在Shard中扮演Leader還是replication由Solr內(nèi)部Zookeeper自動(dòng)協(xié)調(diào)。
訪問(wèn)SolrCloud的過(guò)程：Solr Client向Zookeeper咨詢Collection的地址，Zookeeper返回存活的節(jié)點(diǎn)地址供訪問(wèn)，插入數(shù)據(jù)的時(shí)候由SolrCloud內(nèi)部協(xié)調(diào)數(shù)據(jù)分發(fā)（內(nèi)部使用一致性哈希）。
?
六、Solr Cloud創(chuàng)建索引和更新索引
??
<一>、不得不知道的索引存儲(chǔ)細(xì)節(jié)
當(dāng)Solr客戶端發(fā)送add/update請(qǐng)求給CloudSolrServer,CloudSolrServer會(huì)連接至Zookeeper獲取當(dāng)前SolrCloud的集群狀態(tài)，并會(huì)在/clusterstate.json?和/live_nodes中注冊(cè)watcher，便于監(jiān)視Zookeeper和SolrCloud，這樣做的好處有以下兩點(diǎn)：
1、CloudSolrServer獲取到SolrCloud的狀態(tài)后，它可直接將document發(fā)往SolrCloud的leader，從而降低網(wǎng)絡(luò)轉(zhuǎn)發(fā)消耗。
2、注冊(cè)watcher有利于建索引時(shí)候的負(fù)載均衡，比如如果有個(gè)節(jié)點(diǎn)leader下線了，那么CloudSolrServer會(huì)立馬得知，那它就會(huì)停止往已下線的leader發(fā)送document。
此外，CloudSolrServer?在發(fā)送document時(shí)候需要知道發(fā)往哪個(gè)shard？對(duì)于建好的SolrCloud集群，每一個(gè)shard都會(huì)有一個(gè)Hash區(qū)間，當(dāng)Document進(jìn)行update的時(shí)候，SolrCloud就會(huì)計(jì)算這個(gè)Document的Hash值，然后根據(jù)該值和shard的hash區(qū)間來(lái)判斷這個(gè)document應(yīng)該發(fā)往哪個(gè)shard，Solr使用document route組件來(lái)進(jìn)行document的分發(fā)。目前Solr有兩個(gè)DocRouter類的子類CompositeIdRouter(Solr默認(rèn)采用的)類和ImplicitDocRouter類，當(dāng)然我們也可以通過(guò)繼承DocRouter來(lái)定制化我們的document route組件。
舉例來(lái)說(shuō)當(dāng)Solr Shard建立時(shí)候，Solr會(huì)給每一個(gè)shard分配32bit的hash值的區(qū)間，比如SolrCloud有兩個(gè)shard分別為A,B，那么A的hash值區(qū)間就為80000000-ffffffff?，B的hash值區(qū)間為0-7fffffff。默認(rèn)的CompositeIdRouter hash策略會(huì)根據(jù)document ID計(jì)算出唯一的Hash值，并判斷該值在哪個(gè)shard的hash區(qū)間內(nèi)。
SolrCloud對(duì)于Hash值的獲取提出了以下兩個(gè)要求：
1、hash計(jì)算速度必須快，因?yàn)閔ash計(jì)算是分布式建索引的第一步。
2、?hash值必須能均勻的分布于每一個(gè)shard，如果有一個(gè)shard的document數(shù)量大于另一個(gè)shard，那么在查詢的時(shí)候前一個(gè)shard所花的時(shí)間就會(huì)大于后一個(gè)，SolrCloud的查詢是先分后匯總的過(guò)程，也就是說(shuō)最后每一個(gè)shard查詢完畢才算完畢，所以SolrCloud的查詢速度是由最慢的shard的查詢速度決定的。
基于以上兩點(diǎn)，SolrCloud采用了MurmurHash?算法以提高h(yuǎn)ash計(jì)算速度和hash值的均勻分布。
<二>、Solr創(chuàng)建索引可以分為5個(gè)步驟（如下圖所示）：
<!--[if !supportLists]-->1、<!--[endif]-->用戶可以把新建文檔提交給任意一個(gè)Replica（Solr Core）。
<!--[if !supportLists]-->2、<!--[endif]-->如果它不是leader，它會(huì)把請(qǐng)求轉(zhuǎn)給和自己同Shard的Leader。
3、Leader把文檔路由給本Shard的每個(gè)Replica。
III、如果文檔基于路由規(guī)則(如取hash值)并不屬于當(dāng)前的Shard，leader會(huì)把它轉(zhuǎn)交給對(duì)應(yīng)Shard的Leader。
VI、對(duì)應(yīng)Leader會(huì)把文檔路由給本Shard的每個(gè)Replica。
需要注意的是，添加索引時(shí)，單個(gè)document的路由非常簡(jiǎn)單，但是SolrCloud支持批量添加索引，也就是說(shuō)正常情況下可對(duì)N個(gè)document同時(shí)進(jìn)行路由。這時(shí)SolrCloud會(huì)根據(jù)document路由的去向分開(kāi)存放document，即對(duì)document進(jìn)行分類，然后進(jìn)行并發(fā)發(fā)送至相應(yīng)的shard，這就需要較高的并發(fā)能力。
?
<三>、更新索引的關(guān)鍵點(diǎn)：
1、?Leader接受到update請(qǐng)求后，先將update信息存放到本地的update log，同時(shí)Leader還會(huì)給document分配新的version，對(duì)于已存在的document，如果新的版本高就會(huì)拋棄舊版本，最后發(fā)送至replica。
2、一旦document經(jīng)過(guò)驗(yàn)證以及加入version后，就會(huì)并行的被轉(zhuǎn)發(fā)至所有上線的replica。SolrCloud并不會(huì)關(guān)注那些已經(jīng)下線的replica，因?yàn)楫?dāng)他們上線時(shí)候會(huì)有recovery進(jìn)程對(duì)他們進(jìn)行恢復(fù)。如果轉(zhuǎn)發(fā)的replica處于recovering狀態(tài)，那么這個(gè)replica就會(huì)把update放入update transaction?日志。
3、當(dāng)leader接受到所有的replica的反饋成功后，它才會(huì)反饋客戶端成功。只要shard中有一個(gè)replica是active的，Solr就會(huì)繼續(xù)接受update請(qǐng)求。這一策略其實(shí)是犧牲了一致性換取了寫(xiě)入的有效性。這其中有一個(gè)重要參數(shù)：leaderVoteWait參數(shù)，它表示當(dāng)只有一個(gè)replica時(shí)候，這個(gè)replica會(huì)進(jìn)入recovering狀態(tài)并持續(xù)一段時(shí)間等待leader的重新上線。如果在這段時(shí)間內(nèi)leader沒(méi)有上線，那么他就會(huì)轉(zhuǎn)成leader，其中可能會(huì)有一些document丟失。當(dāng)然可以使用majority quorum來(lái)避免這個(gè)情況,這跟Zookeeper的leader選舉策略一樣，比如當(dāng)多數(shù)的replica下線了，那么客戶端的write就會(huì)失敗。
4、索引的commit有兩種，一種是softcommit，即在內(nèi)存中生成segment，document是可見(jiàn)的(可查詢到)但是沒(méi)寫(xiě)入磁盤，斷電后數(shù)據(jù)會(huì)丟失。另一種是hardcommit，直接將數(shù)據(jù)寫(xiě)入磁盤且數(shù)據(jù)可見(jiàn)。
? ?<四>、對(duì)Solr更新索引和創(chuàng)建索引的幾點(diǎn)總結(jié)：
1、leader轉(zhuǎn)發(fā)的規(guī)則
1）請(qǐng)求來(lái)自leader轉(zhuǎn)發(fā)：那么就只需要寫(xiě)到本地ulog,不需要轉(zhuǎn)發(fā)給leader，也不需要轉(zhuǎn)發(fā)給其它replicas。如果replica處于非active狀態(tài)，就會(huì)將update請(qǐng)求接受并寫(xiě)入ulog，但不會(huì)寫(xiě)入索引。如果發(fā)現(xiàn)重復(fù)的更新就會(huì)丟棄舊版本的更新。
2）請(qǐng)求不是來(lái)自leader，但自己就是leader，那么就需要將請(qǐng)求寫(xiě)到本地，順便分發(fā)給其他的replicas。
3）請(qǐng)求不是來(lái)自leader，但自己又不是leader,也就是該更新請(qǐng)求是最原始的更新請(qǐng)求，那么需要將請(qǐng)求寫(xiě)到本地ulog，順便轉(zhuǎn)發(fā)給leader,再由leader分發(fā)。每commit一次，就會(huì)重新生成一個(gè)ulog更新日志，當(dāng)服務(wù)器掛掉，內(nèi)存數(shù)據(jù)丟失的時(shí)候，數(shù)據(jù)就可以從ulog中恢復(fù)。
2、建索引的時(shí)候最好使用CloudSolrServer，因?yàn)镃loudSolrServer直接向leader發(fā)送update請(qǐng)求，從而避免網(wǎng)絡(luò)開(kāi)銷。
3、批量添加索引的時(shí)候，建議在客戶端提前做好document的路由，在SolrCloud內(nèi)進(jìn)行文檔路由，開(kāi)銷較大。
?
七、Solr Cloud索引的檢索
?
在創(chuàng)建好索引的基礎(chǔ)上，SolrCloud檢索索引相對(duì)就比較簡(jiǎn)單了：
1、用戶的一個(gè)查詢，可以發(fā)送到含有該Collection的任意Solr的Server，Solr內(nèi)部處理的邏輯會(huì)轉(zhuǎn)到一個(gè)Replica。
2、此Replica會(huì)基于查詢索引的方式，啟動(dòng)分布式查詢，基于索引的Shard的個(gè)數(shù)，把查詢轉(zhuǎn)為多個(gè)子查詢，并把每個(gè)子查詢定位到對(duì)應(yīng)Shard的任意一個(gè)Replica。
3、每個(gè)子查詢返回查詢結(jié)果。
4、最初的Replica合并子查詢，并把最終結(jié)果返回給用戶。
?
SolrCloud中提供NRT近實(shí)時(shí)搜索：
SolrCloud支持近實(shí)時(shí)搜索，所謂的近實(shí)時(shí)搜索即在較短的時(shí)間內(nèi)使得新添加的document可見(jiàn)可查，這主要基于softcommit機(jī)制(注意：Lucene是沒(méi)有softcommit的，只有hardcommit)。上面提到Solr建索引時(shí)的數(shù)據(jù)是在提交時(shí)寫(xiě)入磁盤的，這是硬提交，硬提交確保了即便是停電也不會(huì)丟失數(shù)據(jù)；為了提供更實(shí)時(shí)的檢索能力，Solr提供了一種軟提交方式。軟提交（soft commit）指的是僅把數(shù)據(jù)提交到內(nèi)存，index可見(jiàn)，此時(shí)沒(méi)有寫(xiě)入到磁盤索引文件中。在設(shè)計(jì)中一個(gè)通常的做法是：每1-10分鐘自動(dòng)觸發(fā)硬提交，每秒鐘自動(dòng)觸發(fā)軟提交，當(dāng)進(jìn)行softcommit時(shí)候，Solr會(huì)打開(kāi)新的Searcher從而使得新的document可見(jiàn)，同時(shí)Solr還會(huì)進(jìn)行預(yù)熱緩存及查詢以使得緩存的數(shù)據(jù)也是可見(jiàn)的，這就必須保證預(yù)熱緩存以及預(yù)熱查詢的執(zhí)行時(shí)間必須短于commit的頻率，否則就會(huì)由于打開(kāi)太多的searcher而造成commit失敗。
最后說(shuō)說(shuō)在項(xiàng)目中近實(shí)時(shí)搜索的感受吧，近實(shí)時(shí)搜索是相對(duì)的，對(duì)于有客戶需求，1分鐘就是近實(shí)時(shí)了，而有些需求3分鐘就是近實(shí)時(shí)了。對(duì)于Solr來(lái)說(shuō)，softcommit越頻繁實(shí)時(shí)性更高，而softcommit越頻繁則Solr的負(fù)荷越大（commit越頻繁越會(huì)生成小且多的segment，于是Solr merge出現(xiàn)的更頻繁）。目前我們項(xiàng)目中的softcommit頻率是3分鐘，之前設(shè)置過(guò)1分鐘而使得Solr在Index所占資源過(guò)多，從而大大影響了查詢。所以近實(shí)時(shí)蠻困擾著我們的，因?yàn)榭蛻魰?huì)不停的要求你更加實(shí)時(shí)，目前項(xiàng)目中我們采用加入緩存機(jī)制來(lái)彌補(bǔ)這個(gè)實(shí)時(shí)性。
八、Solr Shard Splitting的具體過(guò)程
一般情況下，增加Shard和Replica的數(shù)量能提升SolrCloud的查詢性能和容災(zāi)能力，但是我們?nèi)匀坏酶鶕?jù)實(shí)際的document的數(shù)量，document的大小，以及建索引的并發(fā)，查詢復(fù)雜度，以及索引的增長(zhǎng)率來(lái)統(tǒng)籌考慮Shard和Replica的數(shù)量。Solr依賴Zookeeper實(shí)現(xiàn)集群的管理，在Zookeeper中有一個(gè)Znode?是/clusterstate.json?，它存儲(chǔ)了當(dāng)前時(shí)刻下整個(gè)集群的狀態(tài)。同時(shí)在一個(gè)集群中有且只會(huì)存在一個(gè)overseer，如果當(dāng)前的overseer fail了那么SolrCloud就會(huì)選出新的一個(gè)overseer，就跟shard leader選取類似。
?
Shard分割的具體過(guò)程（old shard split為newShard1和newShard2）可以描述為：
a、在一個(gè)Shard的文檔到達(dá)閾值，或者接收到用戶的API命令，Solr將啟動(dòng)Shard的分裂過(guò)程。
b、此時(shí)，原有的Shard仍然會(huì)提供服務(wù)，Solr將會(huì)提取原有Shard并按路由規(guī)則，轉(zhuǎn)到新的Shard做索引。同時(shí)，新加入的文檔：
1.2．用戶可以把文檔提交給任意一個(gè)Replica,并轉(zhuǎn)交給Leader。
3.Leader把文檔路由給原有Shard的每個(gè)Replica，各自做索引。
III.V.?同時(shí)，會(huì)把文檔路由給新的Shard的Leader
IV.VI．新Shard的Leader會(huì)路由文檔到自己的Replica，各自做索引，在原有文檔重新索引完成，系統(tǒng)會(huì)把分發(fā)文檔路由切到對(duì)應(yīng)的新的Leader上，原有Shard關(guān)閉。Shard只是一個(gè)邏輯概念，所以Shard的Splitting只是將原有Shard的Replica均勻的分不到更多的Shard的更多的Solr節(jié)點(diǎn)上去。
?
九、Zookeeper :
<一>、SolrCloud中使用ZooKeeper主要實(shí)現(xiàn)以下三點(diǎn)功能：
?
<!--[if !supportLists]-->1、<!--[endif]-->集中配置存儲(chǔ)以及管理。
<!--[if !supportLists]-->2、<!--[endif]-->集群狀態(tài)改變時(shí)進(jìn)行監(jiān)控以及通知。
<!--[if !supportLists]-->3、<!--[endif]-->shard leader的選舉。
<二>、?Znode與短鏈接
Zookeeper的組織結(jié)構(gòu)類似于文件系統(tǒng)，每一層是一個(gè)Znode，每一個(gè)Znode存儲(chǔ)了一些元數(shù)據(jù)例如創(chuàng)建時(shí)間，修改時(shí)間以及一些小量的數(shù)據(jù)。需要主要的是，Zookeeper并不支持存放大數(shù)據(jù)，它只支持小于1M大小的數(shù)據(jù)，因?yàn)樾阅茉?#xff0c;Zookeeper將數(shù)據(jù)存放在內(nèi)存中。
Zookeeper另一個(gè)重要的概念是短鏈接，當(dāng)Zookeeper客戶端與Zookeeper建立一個(gè)短連接后會(huì)在Zookeeper新建一個(gè)Znode，客戶端會(huì)一直與Zookeeper進(jìn)行通信并保證這個(gè)Znode一直存在。如果當(dāng)客戶端與Zookeeper的短連接斷開(kāi)，這個(gè)Znode就會(huì)消失。在SolrCloud中，/live_nodes下存儲(chǔ)了了所有客戶端的短連接，表示有哪些Solr組成SolrCloud，具體來(lái)說(shuō)就是當(dāng)Solr跟Zookeeper保持短連接時(shí)，這些Solr主機(jī)就組成了SolrCloud，如果其中一個(gè)Solr的短連接斷掉了，那么Live_nodes下就少了一個(gè)Znode，SolrCloud也就少了一個(gè)主機(jī)，于是Zookeeper就會(huì)告訴其他剩余的Solr有一個(gè)Solr掛掉了，那么在今后進(jìn)行查詢以及l(fā)eader數(shù)據(jù)分發(fā)的時(shí)候就不用再經(jīng)過(guò)剛才那個(gè)Solr了。Zookeeper是通過(guò)watch知道有Solr掛了的,而Zookeeper維護(hù)的集群狀態(tài)數(shù)據(jù)是存放在solr/zoo_data目錄下的。
?
<三>、SolrCloud配置Zookeeper集群的基本過(guò)程
????事例1、單節(jié)點(diǎn)的Zookeeper，包含2個(gè)簡(jiǎn)單的Shard集群：把一個(gè)collection的索引數(shù)據(jù)分布到兩個(gè)shard上去，并假定兩個(gè)shard分別存儲(chǔ)在兩臺(tái)Solr服務(wù)器上。
?
集群構(gòu)建的基本流程：
先從第一臺(tái)solr服務(wù)器說(shuō)起：
1、啟動(dòng)一個(gè)嵌入式的Zookeeper服務(wù)器，作為集群狀態(tài)信息的管理者。
2、將自己這個(gè)節(jié)點(diǎn)注冊(cè)到/node_states/目錄。
3、同時(shí)將自己注冊(cè)到/live_nodes/目錄下。
4、創(chuàng)建/overseer_elect/leader，為后續(xù)Overseer節(jié)點(diǎn)的選舉做準(zhǔn)備，新建一個(gè)Overseer。
5、更新/clusterstate.json目錄下json格式的集群狀態(tài)信息
6、本機(jī)從Zookeeper中更新集群狀態(tài)信息，維持與Zookeeper上的集群信息一致。
7、上傳本地配置文件到Zookeeper中，供集群中其他solr節(jié)點(diǎn)使用。
8、啟動(dòng)本地的Solr服務(wù)器，
9、Solr啟動(dòng)完成后，Overseer會(huì)得知shard中有第一個(gè)節(jié)點(diǎn)進(jìn)來(lái)，更新shard狀態(tài)信息，并將本機(jī)所在節(jié)點(diǎn)設(shè)置為shard1的leader節(jié)點(diǎn)，并向整個(gè)集群發(fā)布最新的集群狀態(tài)信息。
10、本機(jī)從Zookeeper中再次更新集群狀態(tài)信息，第一臺(tái)solr服務(wù)器啟動(dòng)完畢。
?
然后來(lái)看第二臺(tái)solr服務(wù)器的啟動(dòng)過(guò)程：
1、本機(jī)連接到集群所在的Zookeeper。
2、將自己這個(gè)節(jié)點(diǎn)注冊(cè)到/node_states/目錄下。
3、同時(shí)將自己注冊(cè)到/live_nodes/目錄下。
4、本機(jī)從Zookeeper中更新集群狀態(tài)信息，維持與Zookeeper上的集群信息一致。
5、從集群中保存的配置文件加載Solr所需要的配置信息。
6、啟動(dòng)本地solr服務(wù)器。
7、solr啟動(dòng)完成后，將本節(jié)點(diǎn)注冊(cè)為集群中的shard，并將本機(jī)設(shè)置為shard2的Leader節(jié)點(diǎn)。
8、本機(jī)從Zookeeper中再次更新集群狀態(tài)信息，第二臺(tái)solr服務(wù)器啟動(dòng)完畢。
?
示例2、單節(jié)點(diǎn)的Zookeeper，包含2個(gè)shard的集群，每個(gè)shard中有replica節(jié)點(diǎn)。
?
?
如圖所示，集群包含2個(gè)shard，每個(gè)shard中有兩個(gè)solr節(jié)點(diǎn)，一個(gè)是leader，一個(gè)是replica節(jié)點(diǎn)， 但Zookeeper只有一個(gè)。
因?yàn)镽eplica節(jié)點(diǎn)，使得這個(gè)集群現(xiàn)在具備容錯(cuò)性了，背后的實(shí)質(zhì)是集群的overseer會(huì)監(jiān)測(cè)各個(gè)shard的leader節(jié)點(diǎn)，如果leader節(jié)點(diǎn)掛了，則會(huì)啟動(dòng)自動(dòng)的容錯(cuò)機(jī)制，會(huì)從同一個(gè)shard中的其他replica節(jié)點(diǎn)集中重新選舉出一個(gè)leader節(jié)點(diǎn)，甚至如果overseer節(jié)點(diǎn)自己也掛了，同樣會(huì)自動(dòng)在其他節(jié)點(diǎn)上啟用新的overseer節(jié)點(diǎn)，這樣就確保了集群的高可用性。
?
示例3、包含2個(gè)shard的集群，帶shard備份和zookeeper集群機(jī)制
?
?
示例2中存在的問(wèn)題是：盡管solr服務(wù)器具有容錯(cuò)機(jī)制，但集群中只有一個(gè)Zookeeper服務(wù)器來(lái)維護(hù)集群的狀態(tài)信息，單點(diǎn)的存在即是不穩(wěn)定的根源。如果這個(gè)Zookeeper服務(wù)器掛了，那么分布式查詢還是可以工作的，因?yàn)槊總€(gè)solr服務(wù)器都會(huì)在內(nèi)存中維護(hù)最近一次由Zookeeper維護(hù)的集群狀態(tài)信息，但新的節(jié)點(diǎn)無(wú)法加入集群，集群的狀態(tài)變化也不可知了。
因此，為了解決這個(gè)問(wèn)題，需要對(duì)Zookeeper服務(wù)器也設(shè)置一個(gè)集群，讓其也具備高可用性和容錯(cuò)性。有兩種方式可選，一種是提供一個(gè)外部獨(dú)立的Zookeeper集群，另一種是每個(gè)solr服務(wù)器都啟動(dòng)一個(gè)內(nèi)嵌的Zookeeper服務(wù)器，再將這些Zookeeper服務(wù)器組成一個(gè)集群。
?
?
總結(jié)：?通過(guò)以上的介紹，可看出SolrCloud相比Solr而言，有了很多的新特性，保證了整個(gè)Solr應(yīng)用的High Availability。
1、集中式的配置信息
使用ZK進(jìn)行集中配置。啟動(dòng)時(shí)可以指定把Solr的相關(guān)配置文件上傳Zookeeper，多機(jī)器共用。這些ZK中的配置不會(huì)再拿到本地緩存，Solr直接讀取ZK中的配置信息。另外配置文件的變動(dòng)，所有機(jī)器都可以感知到，?Solr的一些任務(wù)也是通過(guò)ZK作為媒介發(fā)布的，目的是為了容錯(cuò)，這使得Solr接收到任務(wù)，但在執(zhí)行任務(wù)時(shí)崩潰的機(jī)器，在重啟后，或者集群選出候選者時(shí)，可以再次執(zhí)行這個(gè)未完成的任務(wù)。
2、SolrCloud對(duì)索引分片，并對(duì)每個(gè)分片創(chuàng)建多個(gè)Replication。每個(gè)Replication都可以對(duì)外提供服務(wù)。一個(gè)Replication掛掉不會(huì)影響索引服務(wù)，更強(qiáng)大的是，SolrCloud還能自動(dòng)的在其它機(jī)器上幫你把失敗機(jī)器上的索引Replication重建并投入使用。
3、近實(shí)時(shí)搜索：立即推送式的replication（也支持慢推送），可以在秒內(nèi)檢索到新加入索引。
4、查詢時(shí)自動(dòng)負(fù)載均衡：SolrCloud索引的多個(gè)Replication可以分布在多臺(tái)機(jī)器上，均衡查詢壓力，如果查詢壓力大，可以通過(guò)擴(kuò)展機(jī)器，增加Replication來(lái)減緩。
5、自動(dòng)分發(fā)的索引和索引分片：發(fā)送文檔到任何節(jié)點(diǎn)，SolrCloud都會(huì)轉(zhuǎn)發(fā)到正確節(jié)點(diǎn)。
6、事務(wù)日志：事務(wù)日志確保更新無(wú)丟失，即使文檔沒(méi)有索引到磁盤。
除此之外，SolrCloud中還提供了其它一些特色功能：
<!--[if !supportLists]-->1、??<!--[endif]-->可將索引存儲(chǔ)在HDFS上
<!--[if !supportLists]-->2、? <!--[endif]-->通過(guò)MR批量創(chuàng)建索引
3、強(qiáng)大的RESTful API
4、優(yōu)秀的管理界面：主要信息一目了然，可以清晰的以圖形化方式看到SolrCloud的部署分布，當(dāng)然還有不可或缺的Debug功能。
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/4972686.html
總結(jié)
以上是生活随笔為你收集整理的SolrCloud之分布式索引及与Zookeeper的集成--转载的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： solrCloud源码分析之CloudS
- 下一篇： zookeeper源码分析之二客户端启动