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