非原創(chuàng)亚皂，記錄蜻底。
一.簡介
SolrCloud是Solr4.0版本以后基于Solr和Zookeeper的分布式搜索方案碍庵。SolrCloud是Solr的基于Zookeeper一種部署方式了赌。Solr可以以多種方式部署巩那，例如單機方式吏夯，多機Master-Slaver方式。
二.特色功能
SolrCloud有幾個特色功能：
集中式的配置信息使用ZK進行集中配置
啟動時可以指定把Solr的相關配置文件上傳Zookeeper即横，多機器共用噪生。這些ZK中的配置不會再拿到本地緩存，Solr直接讀取ZK中的配置信息东囚。配置文件的變動跺嗽，所有機器都可以感知到。另外页藻，Solr的一些任務也是通過ZK作為媒介發(fā)布的桨嫁。目的是為了容錯。接收到任務惕橙，但在執(zhí)行任務時崩潰的機器瞧甩，在重啟后，或者集群選出候選者時弥鹦，可以再次執(zhí)行這個未完成的任務肚逸。
自動容錯
SolrCloud對索引分片爷辙，并對每個分片創(chuàng)建多個Replication。每個Replication都可以對外提供服務朦促。一個Replication掛掉不會影響索引服務膝晾。更強大的是，它還能自動的在其它機器上幫你把失敗機器上的索引Replication重建并投入使用务冕。
近實時搜索
立即推送式的replication（也支持慢推送）血当。可以在秒內檢索到新加入索引禀忆。
查詢時自動負載均衡
SolrCloud索引的多個Replication可以分布在多臺機器上臊旭，均衡查詢壓力。如果查詢壓力大箩退，可以通過擴展機器离熏，增加Replication來減緩。
自動分發(fā)的索引和索引分片
發(fā)送文檔到任何節(jié)點戴涝，它都會轉發(fā)到正確節(jié)點滋戳。
事務日志
事務日志確保更新無丟失，即使文檔沒有索引到磁盤啥刻。
其它值得一提的功能有：
索引存儲在HDFS上
索引的大小通常在G和幾十G奸鸯，上百G的很少，這樣的功能或許很難實用可帽。但是娄涩，如果你有上億數(shù)據(jù)來建索引的話，也是可以考慮一下的蘑拯。我覺得這個功能最大的好處或許就是和下面這個“通過MR批量創(chuàng)建索引”聯(lián)合實用钝满。
通過MR批量創(chuàng)建索引
有了這個功能兜粘，你還擔心創(chuàng)建索引慢嗎申窘？
強大的RESTful API通常你能想到的管理功能，都可以通過此API方式調用孔轴。這樣寫一些維護和管理腳本就方便多了剃法。
優(yōu)秀的管理界面主要信息一目了然；可以清晰的以圖形化方式看到SolrCloud的部署分布路鹰；當然還有不可或缺的Debug功能贷洲。
三.概念
Collection：在SolrCloud集群中邏輯意義上的完整的索引。它常常被劃分為一個或多個Shard晋柱，它們使用相同的Config Set优构。如果Shard數(shù)超過一個，它就是分布式索引雁竞，SolrCloud讓你通過Collection名稱引用它钦椭，而不需要關心分布式檢索時需要使用的和Shard相關參數(shù)拧额。
Config Set: Solr Core提供服務必須的一組配置文件。每個config set有一個名字彪腔。最小需要包括solrconfig.xml (SolrConfigXml)和schema.xml (SchemaXml)侥锦，除此之外，依據(jù)這兩個文件的配置內容德挣，可能還需要包含其它文件恭垦。它存儲在Zookeeper中。Config sets可以重新上傳或者使用upconfig命令更新格嗅，使用Solr的啟動參數(shù)bootstrap_confdir指定可以初始化或更新它番挺。
Core: 也就是Solr Core，一個Solr中包含一個或者多個Solr Core屯掖，每個Solr Core可以獨立提供索引和查詢功能建芙，每個Solr Core對應一個索引或者Collection的Shard，Solr Core的提出是為了增加管理靈活性和共用資源懂扼。在SolrCloud中有個不同點是它使用的配置是在Zookeeper中的禁荸，傳統(tǒng)的Solr core的配置文件是在磁盤上的配置目錄中。
Leader: 贏得選舉的Shard replicas阀湿。每個Shard有多個Replicas赶熟，這幾個Replicas需要選舉來確定一個Leader。選舉可以發(fā)生在任何時間陷嘴，但是通常他們僅在某個Solr實例發(fā)生故障時才會觸發(fā)映砖。當索引documents時，SolrCloud會傳遞它們到此Shard對應的leader灾挨，leader再分發(fā)它們到全部Shard的replicas邑退。
Replica: Shard的一個拷貝。每個Replica存在于Solr的一個Core中劳澄。一個命名為“test”的collection以numShards=1創(chuàng)建地技，并且指定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和索引對照圖
創(chuàng)建索引過程
分布式查詢
Shard Splitting
五.其它
NRT 近實時搜索Solr的建索引數(shù)據(jù)是要在提交時寫入磁盤的，這是硬提交搂橙，確保即便是停電也不會丟失數(shù)據(jù)歉提；為了提供更實時的檢索能力，Solr設定了一種軟提交方式区转。軟提交（soft commit）：僅把數(shù)據(jù)提交到內存苔巨，index可見，此時沒有寫入到磁盤索引文件中废离。
一個通常的用法是：每1-10分鐘自動觸發(fā)硬提交侄泽，每秒鐘自動觸發(fā)軟提交。
RealTime Get 實時獲取允許通過唯一鍵查找任何文檔的最新版本數(shù)據(jù)蜻韭，并且不需要重新打開searcher悼尾。這個主要用于把Solr作為NoSQL數(shù)據(jù)存儲服務，而不僅僅是搜索引擎肖方。Realtime Get當前依賴事務日志闺魏，默認是開啟的。另外俯画，即便是Soft Commit或者commitwithin析桥，get也能得到真實數(shù)據(jù)。 注：commitwithin是一種數(shù)據(jù)提交特性艰垂，不是立刻泡仗，而是要求在一定時間內提交數(shù)據(jù).
