Solr 叢集類型

SolrCloud 模式（也稱為 "SolrCloud"）使用 Apache ZooKeeper 提供集中化的叢集管理，這是其主要特色。ZooKeeper 追蹤叢集的每個節點以及每個節點上每個核心的狀態。

在此模式下，組態檔案儲存在 ZooKeeper 中，而不是每個節點的檔案系統上。當組態變更時，必須將它們上傳到 ZooKeeper，然後 ZooKeeper 會確保每個節點都知道已進行變更。

SolrCloud 引入了一個額外的概念，即集合。一個集合是代表一個索引的整個核心組：邏輯分片和每個分片的物理副本。集合都共享相同的組態（schema、solrconfig.xml 等）。這是叢集管理的另一個集中化，因為可以一次對整個集合執行操作。

當組態發生變更時，重新載入集合的單一命令將自動重新載入該集合中每個個別的核心成員。

分片是自動處理的，只需在建立集合時告訴 Solr 您希望該集合擁有多少個分片即可。索引更新通常會在每個分片之間自動平衡。如果需要，也可以在某種程度上控制哪些文件儲存在哪些分片中。

ZooKeeper 還處理負載平衡和容錯移轉。傳入的請求，無論是索引文件的請求還是使用者查詢的請求，都可以傳送到叢集的任何節點，而 ZooKeeper 會將請求路由到每個分片的適當副本。

在 SolrCloud 中，領導者是靈活的，具有內建的自動領導者選舉機制，以防領導者發生故障。這表示另一個核心可以成為領導者，並且從那時起，它將成為所有副本的事實來源。

只要每個相關分片的一個副本可用，當在 SolrCloud 模式下執行時，使用者查詢或索引請求仍然可以滿足。

Solr 的使用者管理模式要求 SolrCloud 通常使用 ZooKeeper 進行的叢集協調活動，必須以手動方式或使用本機腳本來執行。

如果文件語料庫對於單一分片索引來說太大了，則建立分片的邏輯完全留給使用者。Solr 沒有在索引編制期間建立分片的自動化或程式化方法。

將文件路由到分片是手動處理的，可以使用簡單的雜湊系統或將每個文件傳送到不同分片的簡單輪循分片列表。文件更新必須傳送到正確的分片，否則可能會導致重複的文件。

在使用者管理模式下，領導者和追隨者的概念至關重要。識別哪個節點將託管領導者副本，以及哪個（哪些）主機會是副本，會決定如何組態每個節點。在此模式下，所有索引更新都僅傳送到領導者。一旦領導者完成索引編制，副本將請求索引更新並從領導者複製它們。

負載平衡是使用外部工具或程序實現的，除非請求流量可以單獨由領導者或其副本之一管理。

如果領導者發生故障，則沒有內建的容錯移轉機制。如果查詢專門針對副本，則副本可以繼續為查詢提供服務。將副本變更為作為領導者，將需要在所有副本上變更 solrconfig.xml 組態，並重新載入每個核心。

使用者管理模式沒有集合的概念，因此無論如何，每個 Solr 節點都與其他節點不同。只有一些組態參數可以防止每個節點像獨立的實體一樣運作。