Solr分布式請求

所選擇的副本充當(dāng)聚合器：它創(chuàng)建內(nèi)部請求以隨機(jī)選擇集合中每個分片的副本，協(xié)調(diào)響應(yīng)，根據(jù)需要發(fā)出任何后續(xù)內(nèi)部請求（例如，改進(jìn)facet值或請求額外存儲的字段），并為客戶構(gòu)建最終響應(yīng)。

限制查詢的碎片

雖然使用SolrCloud的優(yōu)點(diǎn)之一是能夠查詢分布在各種碎片中的非常大的集合，但在某些情況下，您可能會知道您只對碎片的一部分結(jié)果感興趣。您可以選擇搜索所有數(shù)據(jù)或僅搜索部分?jǐn)?shù)據(jù)。

查詢集合的所有碎片應(yīng)該看起來很熟悉；就好像SolrCloud甚至沒有發(fā)揮作用：

http://localhost:8983/solr/gettingstarted/select?q=*:*

另一方面，如果您只想搜索一個分片，則可以通過其邏輯ID指定該分片，如下所示：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=shard1

如果您想搜索一組分片id，您可以一起指定它們：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=shard1,shard2

在上面的兩個例子中，分片Id（s）將被用來挑選該分片的隨機(jī)副本。

或者，您可以指定您希望使用的顯式副本來代替分片ID：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=localhost:7574/solr/gettingstarted,localhost:8983/solr/gettingstarted

或者，您可以通過使用管道符號（|）來指定一個副本列表，以便為單個分片選擇（用于負(fù)載平衡）：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=localhost:7574/solr/gettingstarted|localhost:7500/solr/gettingstarted

當(dāng)然，您可以指定一個由一系列副本（由管道“|”分隔）定義的分片列表（用逗號“，”分隔）。在這個例子中，查詢了2個分片，第一個是來自shard1的隨機(jī)副本，第二個是顯式管道分隔列表中的隨機(jī)副本：

http://localhost:8983/solr/gettingstarted/select?q=*:*&shards=shard1,localhost:7574/solr/gettingstarted|localhost:7500/solr/gettingstarted

配置ShardHandlerFactory

您可以直接配置在Solr中的分布式搜索中使用的并發(fā)和線程池的各個方面。這允許更精細(xì)的粒度的控制，您可以調(diào)整它以滿足您自己的具體要求。默認(rèn)配置有利于吞吐量超過延遲。

要配置標(biāo)準(zhǔn)搜索處理程序，請在solrconfig.xml中提供類似如下的配置：

<requestHandler name="/select" class="solr.SearchHandler">
  <!-- other params go here -->
  <shardHandler class="HttpShardHandlerFactory">
    <int name="socketTimeOut">1000</int>
    <int name="connTimeOut">5000</int>
  </shardHandler>
</requestHandler>

可以指定的參數(shù)如下：

socketTimeout

允許套接字等待的時間（以毫秒為單位）。默認(rèn)情況下為0，將使用操作系統(tǒng)的默認(rèn)值。

connTimeout

用于綁定/連接套接字的時間（以毫秒為單位）。默認(rèn)情況下為0，將使用操作系統(tǒng)的默認(rèn)值。

maxConnectionsPerHost

在分布式搜索中對每個獨(dú)立分片進(jìn)行的最大并發(fā)連接數(shù)。默認(rèn)是20。

maxConnections

分布式搜索中的最大并發(fā)連接數(shù)。默認(rèn)是10000

corePoolSize

在協(xié)調(diào)分布式搜索中使用的線程數(shù)保持最低限制。默認(rèn)是0。

maximumPoolSize

用于協(xié)調(diào)分布式搜索的最大線程數(shù)。默認(rèn)是Integer.MAX_VALUE。

maxThreadIdleTime

在線程被縮減以響應(yīng)減少的負(fù)載之前等待的時間量（秒）。默認(rèn)是5。

sizeOfQueue

如果指定，則線程池將使用后備隊列，而不是直接的越區(qū)切換緩沖區(qū)。高吞吐量的系統(tǒng)將希望將其配置為直接手動關(guān)閉（使用-1）。渴望更好的延遲的系統(tǒng)將希望配置合理的隊列大小來處理請求中的變化。默認(rèn)是-1。

fairnessPolicy

選擇處理公平策略隊列的JVM細(xì)節(jié)，如果啟用，分布式搜索將以先進(jìn)先出的方式進(jìn)行處理，其代價是吞吐量。如果禁用的吞吐量將優(yōu)先于滯后時間。默認(rèn)是false。

配置statsCache（分布式IDF）

需要文檔和術(shù)語統(tǒng)計來計算相關(guān)性。當(dāng)涉及到文檔統(tǒng)計計算時，Solr提供了四種實(shí)現(xiàn)方式：

• LocalStatsCache：這只使用本地術(shù)語和文檔統(tǒng)計信息來計算相關(guān)性。在統(tǒng)一分布在分片上的情況下，這種方式工作得很好。如果沒有配置<statsCache>，則這個選項是默認(rèn)的。
• ExactStatsCache：此實(shí)現(xiàn)使用文檔頻率的全局值（在集合中）。
• ExactSharedStatsCache：這與其功能中的確切統(tǒng)計高速緩存完全相同，但是全局統(tǒng)計信息被重復(fù)用于具有相同條件的后續(xù)請求。
• LRUStatsCache：這個實(shí)現(xiàn)使用一個LRU緩存來保存在請求之間共享的全局統(tǒng)計信息。

可以通過在 solrconfig. xml 中設(shè)置 <statsCache> 來選擇實(shí)現(xiàn)。例如，以下行使Solr使用ExactStatsCache實(shí)現(xiàn)：

<statsCache class="org.apache.solr.search.stats.ExactStatsCache"/>

避免分布式死鎖

每個分片服務(wù)于top-level查詢請求，然后向所有其他分片發(fā)出子請求。應(yīng)該注意確保服務(wù)于HTTP請求的線程的最大數(shù)量大于來自top-level客戶機(jī)和其他分片的可能數(shù)量的請求。如果不是這種情況，則配置可能會導(dǎo)致分布式死鎖。

例如，在兩個分片的情況下可能發(fā)生死鎖，每個分片只有一個線程來處理HTTP請求。兩個線程都可以同時接收top-level請求，并相互發(fā)送子請求。由于沒有剩余的線程來處理請求，傳入的請求將被阻塞，直到其他待處理的請求完成，但是由于它們正在等待子請求，所以它們不會完成。通過確保Solr被配置為處理足夠數(shù)量的線程，可以避免像這樣的死鎖情況。

preferLocalShards參數(shù)

Solr允許您傳遞一個名為preferLocalShards的可選布爾參數(shù)，以指示分布式查詢在可用時應(yīng)首選分片的本地副本。換句話說，如果查詢包含preferLocalShards=true，那么查詢控制器將查找本地副本來為查詢服務(wù)，而不是從整個集群中隨機(jī)選擇副本。當(dāng)查詢請求每個文檔返回許多字段或大字段時，這非常有用，因?yàn)樗苊饬嗽诒镜乜捎脮r通過網(wǎng)絡(luò)傳輸大量數(shù)據(jù)。此外，此功能可用于最大限度地降低性能下降的問題副本的影響，因?yàn)樗档土私导壍母北緦⒈黄渌】蹈北久械目赡苄浴?br>

最后，隨著集合中分片數(shù)量的增加，這個特性的值會減少，因?yàn)椴樵兛刂破鲗⒉坏貌粚⒉樵冎赶虼蟛糠址制姆潜镜馗北尽Q句話說，這個特性對于優(yōu)化針對具有少量分片和多個副本的集合的查詢是非常有用的。此外，只有在負(fù)責(zé)所有正在查詢的集合的副本的節(jié)點(diǎn)間進(jìn)行負(fù)載平衡請求時，才應(yīng)使用此選項，因?yàn)镾olr的CloudSolrClient將執(zhí)行此操作。如果不是負(fù)載均衡，則此功能會在群集中引入熱點(diǎn)，因?yàn)椴樵儾粫谌杭芯鶆蚍植肌?/p>