1、SolrCloud簡介一.簡介SolrCloud是Solr4.0版本以后基于Solr和Zookeeper的分布式搜索方案。SolrCloud是Solr的基于Zookeeper一種部署方式。Solr可以以多種方式部署，例如單機方式，多機Master-Slaver方式。二.特色功能SolrCloud有幾個特色功能：集中式的配置信息使用ZK進行集中配置。啟動時可以指定把Solr的相關配置文件上傳Zookeeper，多機器共用。這些ZK中的配置不會再拿到本地緩存，Solr直接讀取ZK中的配置信息。配置文件的變動，所有機器都可以感知到。另外，Solr的一些任務也是通過ZK作為媒介發布的。目的是為了容錯。

2、接收到任務，但在執行任務時崩潰的機器，在重啟后，或者集群選出候選者時，可以再次執行這個未完成的任務。自動容錯SolrCloud對索引分片，并對每個分片創建多個Replication。每個Replication都可以對外提供服務。一個Replication掛掉不會影響索引服務。更強大的是，它還能自動的在其它機器上幫你把失敗機器上的索引Replication重建并投入使用。近實時搜索立即推送式的replication（也支持慢推送）。可以在秒內檢索到新加入索引。查詢時自動負載均衡SolrCloud索引的多個Replication可以分布在多臺機器上，均衡查詢壓力。如果查詢壓力大，可以通過擴展機器，

3、增加Replication來減緩。自動分發的索引和索引分片發送文檔到任何節點，它都會轉發到正確節點。事務日志事務日志確保更新無丟失，即使文檔沒有索引到磁盤。其它值得一提的功能有：索引存儲在HDFS上索引的大小通常在G和幾十G，上百G的很少，這樣的功能或許很難實用。但是，如果你有上億數據來建索引的話，也是可以考慮一下的。我覺得這個功能最大的好處或許就是和下面這個“通過MR批量創建索引”聯合實用。通過MR批量創建索引有了這個功能，你還擔心創建索引慢嗎？強大的RESTful API通常你能想到的管理功能，都可以通過此API方式調用。這樣寫一些維護和管理腳本就方便多了。優秀的管理界面主要信息一目了然；

4、可以清晰的以圖形化方式看到SolrCloud的部署分布；當然還有不可或缺的Debug功能。三.概念Collection：在SolrCloud集群中邏輯意義上的完整的索引。它常常被劃分為一個或多個Shard，它們使用相同的Config Set。如果Shard數超過一個，它就是分布式索引，SolrCloud讓你通過Collection名稱引用它，而不需要關心分布式檢索時需要使用的和Shard相關參數。Config Set: Solr Core提供服務必須的一組配置文件。每個config set有一個名字。最小需要包括solrconfig.xml (SolrConfigXml)和schema.xml

5、 (SchemaXml)，除此之外，依據這兩個文件的配置內容，可能還需要包含其它文件。它存儲在Zookeeper中。Config sets可以重新上傳或者使用upconfig命令更新，使用Solr的啟動參數bootstrap_confdir指定可以初始化或更新它。Core: 也就是Solr Core，一個Solr中包含一個或者多個Solr Core，每個Solr Core可以獨立提供索引和查詢功能，每個Solr Core對應一個索引或者Collection的Shard，Solr Core的提出是為了增加管理靈活性和共用資源。在SolrCloud中有個不同點是它使用的配置是在Zookeeper中

6、的，傳統的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創建，并

7、且指定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運行，但是建議用獨立的，并且最好有

8、3個以上的主機。四.架構圖索引（collection）的邏輯圖Solr和索引對照圖創建索引過程分布式查詢Shard Splitting：（索引拆分，分發到新的節點）五.其它NRT近實時搜索Solr的建索引數據是要在提交時寫入磁盤的，這是硬提交，確保即便是停電也不會丟失數據；為了提供更實時的檢索能力，Solr設定了一種軟提交方式。軟提交（soft commit）：僅把數據提交到內存，index可見，此時沒有寫入到磁盤索引文件中。一個通常的用法是：每1-10分鐘自動觸發硬提交，每秒鐘自動觸發軟提交。RealTime Get 實時獲取允許通過唯一鍵查找任何文檔的最新版本數據，并且不需要重新打開sea

9、rcher。這個主要用于把Solr作為NoSQL數據存儲服務，而不僅僅是搜索引擎。Realtime Get當前依賴事務日志，默認是開啟的。另外，即便是Soft Commit或者commitwithin，get也能得到真實數據。 注：commitwithin是一種數據提交特性，不是立刻，而是要求在一定時間內提交數據.新的SolrCloud設計思想這只是一些想法的草稿記錄，并不作為 這個頁面不描述SolrCloud被實現的設計，它的存在出于歷史的原因。1. 什么是SolrCloud？SolrCloud對已有的Solr來說，是對管理和操作作為云搜索服務的Solr的一大改進。2.術語表（Glossar

10、y）。Cluster：Cluster是作為獨立單位管理的一組Solr節點。整個集群必須有唯一的schema和solrconfig。Node：一個運行Solr的JVM實例。Partition：一個partition是整個文檔集合的一個子集。一個partition被以這樣的方式創建，它的所有文檔可以被包含在一個單獨的索引中。Shard：一個partition需要在多個節點中存儲，由replication因子(factor)來指定。所有這些節點共同構成一個shard. 一個節點可能是多個shards的一部分。Leader：每個Shard有一個節點確認為它的leader.所有屬于一個partition

11、的文檔的寫操作應該被路由到leader。Replication Factor：由集群維護的文檔的最小復制數。Transaction Log：每個節點維護的只可追加的寫操作日志。Partition Version：由每個Shard維護的一個計數器，在每個寫操作時增加，并且發送到同等節點。Cluster Lock：一個全局鎖，必須獲取才能改變range-partition或partition-node的映射3. 指導原則（Guiding Principles）。任何操作都可以在集群的任何節點上調用。沒有不可恢復的單點故障。集群應該是可伸縮的。寫操作必須從不會丟失，即確保持久性。寫的順序應該被保持。

12、如果兩個客戶端同時發送文檔”A”到兩個不同的replicas，其中一個總是”贏”過其他所有replicas。集群配置應該被集中管理，并且可以通過集群中的任何節點更新。除了本地的值，如端口、索引/日志存放位置，不應要求按節點配置。讀的自動故障恢復。寫的自動故障恢復。在節點故障事件時，自動地獲得repliaction factor.4. ZookeeperZookeeper集群作為以下用途：。Solr集群的集中式配置存儲。需要分布式同步的操作的協調器。集群拓撲的記錄系統5.分區(Partitioning)集群配置了一個固定的max_hash_value（設置為一個相當大的值，如1000）N. 每個

13、文檔的hash計算為：hash = hash_function(doc.getKey() % Nhash值按范圍(range)分配到各partions，并存儲到Zookeeper.例如我們有一個range到partition的映射如下range : partition- -0 - 99 : 1100-199: 2200-299: 3這個hash值被作為一個索引字段添加并且是不可變的，這也以用在索引split中。Hash函數是可插入的。它可以接收一個文檔并返回一致的正整數hash值。系統提供一個默認的hash函數，使用一個配置的、必要且不可變域（默認是unique_key域）的值來計算hash值

14、。使用全部的hash范圍 (Using full hash range)或者，不需要任何max_hash_value 因為不管怎樣每個shard將有一個范圍的hash值，可以使用全部的32位hash值。避免可配置的max_hash_value使客戶端更容易得到相互之間的hash值。例如，在一個郵件搜索應用中，可能如下構造hashcode：(hash(user_id)8)Hashcode的高8位從user_id生成，確保了任何的用戶郵件都在集群的相同的第256部分（注：被256整除）。在搜索時，這個信息只能用于搜索集群的那一部分。為了表達超出的范圍（跨越最大值和最小值）我們可能也會將hash空間

15、視為一個環（類似于consistent hasing）。shard命名 (shard naming)當根據hash code來做分區(partitioning)時，與其單獨維護一個shard到hash范圍的映射，不如讓shard名成為hash范圍（即，shard”1-1000”將包含hashcode為1到1000的文檔集）。當前solr-core的命名約定是它匹配集合名（假定solr服務中一個集合對應一個core）。當一個集合有多個cores時，我們還需要一個好的命名模式。6. Shard分配 (Shard Assignment)只有當一個節點獲得Zookeeper中的Cluster Lock

16、時，才能改變node - partition的映射。因此當一個節點加入進來，它首先嘗試去獲取cluster lock，等到獲得鎖然后確定它可以訂閱到哪一個partition.節點到shard的分配 (Node to a shard assignment)一個嘗試發現新節點的節點應該先獲得cluster lock。shard的leader首先被確定。在所有可用的節點中，擁有最小shard數目的節點被選擇。如果有多個，最小shard數的leader被選擇。如果還有多個，隨機選擇一個節點。7.啟動引導 (Boot Strapping)集群啟動一個節點啟動時指向一個Zookeeper主機和端口。集群中

17、的第一個節點可能以集群配置和集群的schema/config文件啟動。第一個節點將上傳配置到Zookeeper并且引導集群啟動。集群被視為”引導”(”bootstrap”)狀態，此狀態下，node - partition 映射不被計算并且集群不接受任何讀/寫請求，除了clusteradmin命令。在初始節點集啟動以后，管理員發出一個clusteradmin命令(TBD description). 這個命令接收一個整型”partitions”參數，并按下面的步驟進行：1.獲得Cluster Lock2.分配”partitions”數3.為每個partition獲得nodes4.更新ZooKeep

18、er中的node-partition映射。5.釋放Cluster Lock6.通知所有節點強制從ZooKeeper更新它們自己的node-partition映射。節點啟動節點啟動時，檢查ZooKeeper看它是否是已經存在的shard的一個部分。如果ZooKeeper沒有關于這個節點的記錄或這個節點不是任何shard的一部分，按步驟啟動，否則按的步驟。新節點新節點是從未加入過集群的節點，被新加入以增加集群的容量。如果”auto_add_new_nodes”這個集群屬性是false，新節點在ZooKeeper中注冊為”idle”，并且等到其他節點喚醒它加入。否則，如下處理：1. 獲取Cluste

19、r Lock2. 選擇一個合適的源組(node,partition):2.1 掃描可用的partitions列表，找到節點數少于”replication_factor”的partition. 如果找到多個，最少節點的nodes被選擇。依然有多個，則隨機選擇。2.2 如果所有的partitions都有足夠的replicas,掃描節點，找到包含最多partitions的節點。如果有多個，有最多文檔的節點被選擇。如果還有多個，選擇隨機partition上的隨機節點。2.3 如果為當前node選擇(node，partition)組，會降低集群的最大數目的partition:node比率，此選擇被返回。

20、否則，沒有選擇并且算法終止。2.4 在ZooKeeper中更新node-partition映射3. 這個節點在ZooKeeper中的狀態被更新為”recovery”4. 釋放Cluster Lock5. 被選擇partition的節點leader被初始化為“recovery”6. 在recovery完成以后，ClusterLock被獲得7. 在ZooKeeper中的源(node,partition)被移除8. Cluster Lock被釋放9. 源節點被指示強制從ZooKeeper更新node-parition10. Goto 第1步節點重啟一個節點重啟，意味著下列事件之一：。JVM崩潰并且被

21、手動或自動重啟。節點在臨時網絡中斷時，在一段時間內，或不能訪問ZooKeeper（被認為dead），或不能接收來自Leader的更新，節點在節點失敗時重啟。一個寫操作的生命周期在這個場景意味著網絡的移除。一個硬件失敗或維護窗口導致節點從集群移除，并且節點又被啟動來重新加入集群。節點讀取它所在的partitions，對每個partition，分別從每個partition的leader啟動一個recovery處理。然后，節點按新節點啟動步驟，而不檢查auto_add_new_nodes屬性。這確保了集群從由客戶端的寫操作帶來的不平衡狀態中以Solr標準更新格式恢復。一個寫操作可以被發送到集群的任何

22、節點。節點使用hash_function,和rang-partition映射來定位文檔屬于哪個partition。通過一個ZooKeeper查詢定位到shard的leader，并且將操作傳遞過去。對SolrJ的改進可能使它能直接發送到leader。Leader節點為操作分配一個Partition版本，并且將操作寫到事務日志，并且將document + version + hash傳遞到屬于這個shard的其他節點。這些節點將document+hash寫到索引，并且將操作記錄到事務日志。如果至少min_writes數目的節點返回”OK”, leader節點返回”OK”.集群屬性的min_writ

23、es可以被請求中指定的參數覆蓋。云模式不會提供任何顯示commit或rollback操作。Commits操作由leader在間隔時間（commit_within）通過auto-commits來管理，并且在shard所有成員上觸發一個commit.節點最近的可用版本在commit時被記錄。8.事務日志(Transaction Log)。事務日志記錄了commits之間在索引上的所有操作。每個commit發起一個新的事務日志，因為一個commit確保之前操作的持久性。同步是可調的，例如flush vs fsync 默認下可以進行JVM崩潰保護，但不能斷電保護并且更快9.恢復(Recovery)恢復

24、在下列情形觸發：。啟動引導。Partition切分。Cluster負載均衡節點從設置狀態為recovering開始。在這期間，節點不會接收任何讀請求，但會接收所有應該被寫入獨立事務日志的新的寫請求。節點查看索引版本，并且從leader查詢最近的partition版本。Leader響應并返回需要在節點與shard內其他節點同步前進行的操作的集合。這可能涉及到根據節點位置先拷貝索引并重演事務日志，這是最新的技術。如果索引拷貝被請求了，索引文件先被復制到本地索引，然后按事務日志（記錄的操作）重新操作。事務日志重演不過是一系列常規的寫請求。在這期間，節點可能已經積累了一些新的應對索引進行的寫操作。在到

25、達最近的commit點的時刻，它使自身成為ready。在這個點，節點可以處理讀請求。處理節點失敗節點之間或節點和ZooKeeper之間可能存在網絡臨時中斷。集群在均衡數據之前應該等待一段時間。Leader節點失敗任何shard的leader失敗，其他節點成員會發起一個leader選舉處理。在新leader選舉出來之前，這個partition的寫操作不被接受。然后按非leader節點失敗步驟處理。非leader節點失敗Leader在確定一個新節點是shard的一部分之前會等待min_reaction_time的時間。Leader獲得ClusterLock，并且使用node-shard分配算法來確

26、定一個節點為本shard的新成員。Node-partition映射在ZooKeeper中被更新，再釋放cluster lock. 新節點被強制從ZooKeeper更新node-partition映射表。10.切分分區（Splitting partitions）分區切分可以由顯示的cluster admin命令或由Solr的切分策略自動地進行。一個顯示的切分命令可能給出指定分區用于切分。假定hash范圍100-199的分區X，被確定為分成X(100-149)和一個新partition Y(150,199). X的leader會在ZooKeeper中記錄此切分行為，及X和Y要求的范圍值。這個行為或

27、新分區的存在不會通知到任何節點。1. X的leader，獲取集群鎖并且確認可以被分配到Y的節點（算法待定），并告知它們新的分區并且更新partition-node映射。X的leader等待節點回應，一旦檢查到新分區已準備好接收命令，進行如下處理：2. X的leader在切分完成前掛起所有commits3. X的leader在最近commit點（稱為版本V）打開IndexReader，并通知peer節點做同樣的事情4. X的leader開始傳輸版本V后hash范圍為150-199的事務日志到Y的leader5. Y的leader僅僅在它的事務日志中記錄所有在#2發送的請求，即不在索引上操作6.

28、X的leader在第2步后打開的IndexReader上發起一個索引切分7. 第5步創建的索引被發送到Y的leader，并被安裝8. Y的leader通知它的peer節點開始recovery處理. 同時，在索引上開始按事務日志操作a. 一旦Y分區的所有成員到達版本V(進行如下操作):b. Y的leader通知X的leader在#2創建的Reader上準備一個FilterIndexReader，它包含所有屬于100-149范圍的文檔。c. 一旦X的leader確認完成了#8a的請求，Y的leader獲取集群鎖并修改range-partition映射，以開始接受來自整個集群的search/writ

29、e請求d. Y的leader要求X的leader開始使用#8a創建的FilteredIndexReader用于搜索請求e. Y的leader要求X的leader強制從ZooKeeper更新range-partition映射。此處，確保#3發起的事務日志傳輸將停止9. X的leader將刪除所有hash值不屬于它的partition的文檔，commit并在最近的commit點打開searcher10. 此時，分區被認為已完成，并且X的leader根據commit_within參數重新開始commit。注意：。被切分的分區在切分操作完成前，不被設置commit_within參數。在#8b開始到#8

30、c結束之間進行的分布式搜索操作，可能返回不一致的結果，即返回的搜索結果數可能出錯11.集群均衡（Cluster Re-balancing）集群可以通過一個顯示的集群管理命令被重新平衡。TBD (To Be Determined)12.監控（Monitoring）TBD13.配置solr_perties這是常規Solr配置外的屬性集合，可適用于集群所有節點：replication_factor：集群一個文檔的復制數min_writes：一個寫操作被為成功前的最少（節點）寫成功數。這可能基于每次的寫操作被覆蓋commit_within：寫操作可被搜索的最長時間hash_fun

31、ction:計算給定文檔hash值的算法max_hash_value:hash_function輸出的最大值。理論上，這也是集群可以擁有的最大partitions數min_reaction_time:一個節點加入和離開后，開始重新分配/切分的時間（秒）min_replica_for_reaction:如果replica節點數小于這個閥值，即便min_reaction_time時間未到也會觸發切分操作auto_add_new_nodes:布爾標識。True，新節點自動作為讀復制加入已經存在的分區，否則，除非集群需要新節點狀態為idle14.集群管理命令所有集群管理命令在所有節點上以給定path運

32、行（如/cluster_admin）. 所有節點都能接收相同的命令并且進行相同的行為。這里是所有用戶可以用來管理集群的公開命令：init_cluster:(params:partition) 這個命令在初始節點集啟動后被發出。在這條命令被發出前，集群不會接收任何讀/寫命令split_partition:(params:partition 可選) 這個分區被切分成兩半。如果partition參數未提供，有最多文檔的partition被候選add_idle_nodes:如果auto_add_new_nodes=false這個參數可用，觸發所有idle的節點加入到集群move_partition:(

33、params: partition, from, to).將partition從一個節點到另一個節點command_status:(params: completion_id 可選).上面所有的命令都是異步的并且返回一個completion_id.此命令可用于查看指定或全部當前運行命令的狀態status:(params:partition 可選) 顯示所有或各partition的如下信息：。leadernode。nodeslist。doccount。averagereads/sec。averagewrites/sec。averagetime/read。averagetime/write15.從Solr遷移到SolrCloud當遷移到cloud后少數功能可能變得多余或不被支持。我們應繼續支持包含所有已存功能的非cloud版本。Replication 這個功能不再需要了。CoreAdmin 命令，對cores的顯示操作不被允許。因此cores可能存在在內部并且被隱式管理。Multiple schema 支持？我們應該從1.0版本簡單的刪除？。solr.xml. 在cloud模式還有任何必要嗎？16.集群鎖的代替（Alternative to a