使用者管理的分散式搜尋

當使用傳統的索引分片時，您需要考慮如何查詢您的文件。

強烈建議您在需要向上或向外擴展時使用 SolrCloud。下面描述的設定是舊版，在 SolrCloud 存在之前使用。SolrCloud 提供真正的分散式功能集，支援自動路由、領導者選舉、樂觀並行以及其他分散式系統預期的健全性檢查。

此頁面上的所有內容均特定於分散式搜尋的舊版設定。嘗試 SolrCloud 的使用者不應遵循以下任何步驟或資訊。

更新重新排序（即，副本 A 可能會先看到更新 X，然後看到 Y，而副本 B 可能會先看到更新 Y，然後看到 X）。deleteByQuery 也會以相同的方式處理重新排序，以確保副本保持一致。分片的所有副本都是一致的，即使更新在不同副本上以不同的順序到達。

跨分片分配文件

當不使用 SolrCloud 時，您有責任將所有文件索引到伺服器群組的每個分片上。Solr 僅在 SolrCloud 模式下才支援真正的分散式索引（路由）。

在舊版分散式模式中，Solr 不會計算通用的詞彙/文件頻率。對於大多數大型實作，Solr 在分片層級計算 TF/IDF 可能並不重要。但是，如果您的集合在伺服器上的分佈嚴重傾斜，您可能會在搜尋中發現誤導性的相關性結果。一般來說，最好將文件隨機分配到您的分片。

使用 shards 參數執行分散式搜尋

如果查詢請求包含 shards 參數，Solr 伺服器會將請求分散到所有列為參數引數的分片。shards 參數使用此語法

host:port/base_url,host:port/base_url*

例如，下面的 shards 參數會導致搜尋分散在兩個 Solr 伺服器：solr1 和 solr2，它們都在埠 8983 上執行

https://127.0.0.1:8983/solr/core1/select?shards=solr1:8983/solr/core1,solr2:8983/solr/core1&indent=true&q=ipod+solr

通常最好在 solrconfig.xml 的 RequestHandler 區段中將此參數設定為預設值，而不是要求使用者明確包含 shards 參數。

請勿將 shards 參數新增至標準請求處理器；這樣做可能會導致搜尋查詢進入無限迴圈。相反地，請定義一個使用 shards 參數的新請求處理器，並將分散式搜尋請求傳遞給該處理器。

在舊版模式下，只會分散查詢請求。這包括使用支援分散式搜尋的標準元件，向 SearchHandler (或任何從 org.apache.solr.handler.component.SearchHandler 擴充的處理器) 發出的請求。

如同在 SolrCloud 模式中，當 shards.info=true 時，分散式回應將包含有關分片的資訊（其中每個分片代表一個邏輯上不同的索引或實體位置）。

以下元件支援分散式搜尋

  • Query 元件，會傳回符合查詢的文件。

  • Facet 元件，處理 facet.query 和 facet.field 請求，其中 facet 會依計數排序（預設）。

  • Highlighting 元件，使 Solr 能夠在欄位值中包含「高亮顯示」的匹配項。

  • Stats 元件，傳回 DocSet 中數值欄位的簡單統計資訊。

  • Debug 元件，協助除錯。

allowUrls 參數

在 shards 參數中允許的節點可透過 solr.xml 中的 allowUrls 屬性設定。此允許清單會自動為 SolrCloud 設定，但使用者管理的叢集需要明確設定。請在設定 ShardHandlerFactory章節中閱讀更多詳細資訊。

Solr 中的分散式搜尋有以下限制

  • 每個索引的文件都必須有一個唯一的索引鍵。

  • 如果 Solr 發現重複的文件 ID，Solr 會選擇第一個文件並捨棄後續的文件。

  • 如果在分散式搜尋的第一階段和第二階段之間發生 commit，分散式搜尋的索引可能會暫時不同步。這可能會導致這樣的情況：曾經符合查詢且隨後被更改的文件可能不再符合查詢，但仍會被檢索出來。這種情況預計相當罕見，而且只可能發生在單個查詢請求中。

  • shard 的數量受到 GET 方法的 URI 允許的字元數限制；大多數 Web 伺服器通常至少支援 4000 個字元，但許多伺服器會限制 URI 長度，以降低其遭受阻斷服務（DoS）攻擊的風險。

  • 在分散式搜尋中，可以透過在搜尋請求中包含 fl=id, [shard]，來隨每個文件傳回 shard 資訊。這會傳回 shard URL。

  • 在分散式搜尋中，核心描述符中的資料目錄會覆寫 solrconfig.xml 中的任何資料目錄。

  • 更新指令可以傳送到任何正確設定分散式索引的伺服器。文件新增和刪除會根據唯一文件 ID 的雜湊值轉發到適當的伺服器/shard。 commit 指令和 deleteByQuery 指令會傳送到 shards 中列出的每個伺服器。

先前的一個限制是 TF/IDF 相關性計算只使用 shard 本機統計資料。預設情況下仍然如此。如果您的資料不是隨機分佈的，或者您想要更精確的統計資料，那麼您可以設定 ExactStatsCache。

避免分散式死鎖

如同在 SolrCloud 模式中，shard 間的請求可能會導致分散式死鎖。可以按照SolrCloud 分散式請求章節中的說明來避免。

負載平衡請求

在管理使用者管理的 Solr 叢集時，查詢請求應在每個 shard 跟隨者之間進行負載平衡。這既可以提高查詢處理能力，又可以在伺服器當機時提供容錯移轉。

由於此情境中沒有集中式叢集管理，因此此設定中的任何領導者 shard 都不知道彼此。文件會索引到每個領導者，索引會複製到每個跟隨者，然後使用每個 shard 中的一個跟隨者，將搜尋分散到這些跟隨者中。

為了實現高可用性，您應該使用負載平衡器為每個 shard 的一組跟隨者設定虛擬 IP。如果您是負載平衡的新手，HAProxy (http://haproxy.1wt.eu/) 是一個不錯的開放原始碼軟體負載平衡器。如果跟隨者伺服器當機，一個好的負載平衡器會使用某些技術（通常是心跳系統）偵測到故障，並將所有請求轉發到與故障的跟隨者一起提供服務的剩餘有效跟隨者。然後應該設定單個虛擬 IP，以便請求可以命中單個 IP，並對每個搜尋跟隨者的虛擬 IP 進行負載平衡。

透過此設定，您將擁有一個完全負載平衡、搜尋端容錯的系統。傳入的搜尋將被轉移到其中一個正常運作的跟隨者，然後跟隨者將搜尋請求分散到您設定中每個 shard 的跟隨者。跟隨者會向每個 shard 的每個虛擬 IP 發出請求，而負載平衡器會選擇一個可用的跟隨者。最後，結果將合併為單個結果集並傳回。如果任何跟隨者當機，它們將被移出輪換，並使用剩餘的跟隨者。如果 shard 領導者當機，在您解決問題並將領導者重新投入生產之前，仍然可以從跟隨者提供搜尋。