非原創(chuàng)，記錄。
一.簡介
SolrCloud是Solr4.0版本以后基于Solr和Zookeeper的分布式搜索方案。SolrCloud是Solr的基于Zookeeper一種部署方式。Solr可以以多種方式部署，例如單機(jī)方式，多機(jī)Master-Slaver方式。
二.特色功能
SolrCloud有幾個(gè)特色功能：
集中式的配置信息使用ZK進(jìn)行集中配置
啟動(dòng)時(shí)可以指定把Solr的相關(guān)配置文件上傳Zookeeper，多機(jī)器共用。這些ZK中的配置不會(huì)再拿到本地緩存，Solr直接讀取ZK中的配置信息。配置文件的變動(dòng)，所有機(jī)器都可以感知到。另外，Solr的一些任務(wù)也是通過ZK作為媒介發(fā)布的。目的是為了容錯(cuò)。接收到任務(wù)，但在執(zhí)行任務(wù)時(shí)崩潰的機(jī)器，在重啟后，或者集群選出候選者時(shí)，可以再次執(zhí)行這個(gè)未完成的任務(wù)。
自動(dòng)容錯(cuò)
SolrCloud對索引分片，并對每個(gè)分片創(chuàng)建多個(gè)Replication。每個(gè)Replication都可以對外提供服務(wù)。一個(gè)Replication掛掉不會(huì)影響索引服務(wù)。更強(qiáng)大的是，它還能自動(dòng)的在其它機(jī)器上幫你把失敗機(jī)器上的索引Replication重建并投入使用。
近實(shí)時(shí)搜索
立即推送式的replication（也支持慢推送）?？梢栽诿雰?nèi)檢索到新加入索引。
查詢時(shí)自動(dòng)負(fù)載均衡
SolrCloud索引的多個(gè)Replication可以分布在多臺(tái)機(jī)器上，均衡查詢壓力。如果查詢壓力大，可以通過擴(kuò)展機(jī)器，增加Replication來減緩。
自動(dòng)分發(fā)的索引和索引分片
發(fā)送文檔到任何節(jié)點(diǎn)，它都會(huì)轉(zhuǎn)發(fā)到正確節(jié)點(diǎn)。
事務(wù)日志
事務(wù)日志確保更新無丟失，即使文檔沒有索引到磁盤。
其它值得一提的功能有：
索引存儲(chǔ)在HDFS上
索引的大小通常在G和幾十G，上百G的很少，這樣的功能或許很難實(shí)用。但是，如果你有上億數(shù)據(jù)來建索引的話，也是可以考慮一下的。我覺得這個(gè)功能最大的好處或許就是和下面這個(gè)“通過MR批量創(chuàng)建索引”聯(lián)合實(shí)用。
通過MR批量創(chuàng)建索引
有了這個(gè)功能，你還擔(dān)心創(chuàng)建索引慢嗎？
強(qiáng)大的RESTful API通常你能想到的管理功能，都可以通過此API方式調(diào)用。這樣寫一些維護(hù)和管理腳本就方便多了。
優(yōu)秀的管理界面主要信息一目了然；可以清晰的以圖形化方式看到SolrCloud的部署分布；當(dāng)然還有不可或缺的Debug功能。
三.概念
Collection：在SolrCloud集群中邏輯意義上的完整的索引。它常常被劃分為一個(gè)或多個(gè)Shard，它們使用相同的Config Set。如果Shard數(shù)超過一個(gè)，它就是分布式索引，SolrCloud讓你通過Collection名稱引用它，而不需要關(guān)心分布式檢索時(shí)需要使用的和Shard相關(guān)參數(shù)。
Config Set: Solr Core提供服務(wù)必須的一組配置文件。每個(gè)config set有一個(gè)名字。最小需要包括solrconfig.xml (SolrConfigXml)和schema.xml (SchemaXml)，除此之外，依據(jù)這兩個(gè)文件的配置內(nèi)容，可能還需要包含其它文件。它存儲(chǔ)在Zookeeper中。Config sets可以重新上傳或者使用upconfig命令更新，使用Solr的啟動(dòng)參數(shù)bootstrap_confdir指定可以初始化或更新它。
Core: 也就是Solr Core，一個(gè)Solr中包含一個(gè)或者多個(gè)Solr Core，每個(gè)Solr Core可以獨(dú)立提供索引和查詢功能，每個(gè)Solr Core對應(yīng)一個(gè)索引或者Collection的Shard，Solr Core的提出是為了增加管理靈活性和共用資源。在SolrCloud中有個(gè)不同點(diǎn)是它使用的配置是在Zookeeper中的，傳統(tǒng)的Solr core的配置文件是在磁盤上的配置目錄中。
Leader: 贏得選舉的Shard replicas。每個(gè)Shard有多個(gè)Replicas，這幾個(gè)Replicas需要選舉來確定一個(gè)Leader。選舉可以發(fā)生在任何時(shí)間，但是通常他們僅在某個(gè)Solr實(shí)例發(fā)生故障時(shí)才會(huì)觸發(fā)。當(dāng)索引documents時(shí)，SolrCloud會(huì)傳遞它們到此Shard對應(yīng)的leader，leader再分發(fā)它們到全部Shard的replicas。
Replica: Shard的一個(gè)拷貝。每個(gè)Replica存在于Solr的一個(gè)Core中。一個(gè)命名為“test”的collection以numShards=1創(chuàng)建，并且指定replicationFactor設(shè)置為2，這會(huì)產(chǎn)生2個(gè)replicas，也就是對應(yīng)會(huì)有2個(gè)Core，每個(gè)在不同的機(jī)器或者Solr實(shí)例。一個(gè)會(huì)被命名為test_shard1_replica1，另一個(gè)命名為test_shard1_replica2。它們中的一個(gè)會(huì)被選舉為Leader。
Shard: Collection的邏輯分片。每個(gè)Shard被化成一個(gè)或者多個(gè)replicas，通過選舉確定哪個(gè)是Leader。
Zookeeper: Zookeeper提供分布式鎖功能，對SolrCloud是必須的。它處理Leader選舉。Solr可以以內(nèi)嵌的Zookeeper運(yùn)行，但是建議用獨(dú)立的，并且最好有3個(gè)以上的主機(jī)。
四.架構(gòu)圖
索引（collection）的邏輯圖
Solr和索引對照圖
創(chuàng)建索引過程
分布式查詢
Shard Splitting
五.其它
NRT 近實(shí)時(shí)搜索Solr的建索引數(shù)據(jù)是要在提交時(shí)寫入磁盤的，這是硬提交，確保即便是停電也不會(huì)丟失數(shù)據(jù)；為了提供更實(shí)時(shí)的檢索能力，Solr設(shè)定了一種軟提交方式。軟提交（soft commit）：僅把數(shù)據(jù)提交到內(nèi)存，index可見，此時(shí)沒有寫入到磁盤索引文件中。
一個(gè)通常的用法是：每1-10分鐘自動(dòng)觸發(fā)硬提交，每秒鐘自動(dòng)觸發(fā)軟提交。
RealTime Get 實(shí)時(shí)獲取允許通過唯一鍵查找任何文檔的最新版本數(shù)據(jù)，并且不需要重新打開searcher。這個(gè)主要用于把Solr作為NoSQL數(shù)據(jù)存儲(chǔ)服務(wù)，而不僅僅是搜索引擎。Realtime Get當(dāng)前依賴事務(wù)日志，默認(rèn)是開啟的。另外，即便是Soft Commit或者commitwithin，get也能得到真實(shí)數(shù)據(jù)。 注：commitwithin是一種數(shù)據(jù)提交特性，不是立刻，而是要求在一定時(shí)間內(nèi)提交數(shù)據(jù).
