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