當(dāng)您的集合對于一個節(jié)點來說太大時，您可以通過創(chuàng)建多個分片將其分解并分段存儲。

碎片是集合的邏輯分區(qū)，包含集合中的文檔的子集，使集合中的每個文檔都包含在一個碎片中。哪個碎片包含集合中的每個文檔取決于該集合的整體“碎片”策略。

例如，您可能有一個集合，其中每個文檔的“國家/地區(qū)”字段確定它屬于哪個分片，因此來自同一個國家/地區(qū)的文檔位于同一位置。不同的集合可以簡單地在每個文檔的uniqueKey上使用“哈?！眮泶_定其碎片。

在SolrCloud之前，Solr支持分布式搜索，它允許在多個分片上執(zhí)行一個查詢，因此查詢是針對整個Solr索引執(zhí)行的，搜索結(jié)果中不會有任何文檔被遺漏。所以在一個碎片上分割一個索引并不完全是一個SolrCloud的概念。然而，分布式方法存在幾個問題，需要使用SolrCloud進(jìn)行改進(jìn)：

1. 將索引分割成碎片是有點手動的。
2. 沒有支持分布式索引，這意味著您需要明確地發(fā)送文件到一個特定的碎片；Solr無法自行找出發(fā)送文件的碎片。
3. 沒有負(fù)載平衡或故障轉(zhuǎn)移，所以如果您有大量的查詢，您需要找出發(fā)送它們的位置，如果一個碎片死了，它就消失了。

SolrCloud解決了這些限制。支持自動分配索引進(jìn)程和查詢，并且ZooKeeper提供故障轉(zhuǎn)移和負(fù)載平衡。另外，每個碎片都可以有多個復(fù)制副本，以增強(qiáng)可靠性。

Leader和副本

在SolrCloud中沒有主人或奴隸。相反，每個碎片至少包含一個物理副本，其中一個是Leader。Leader自動當(dāng)選，最初是先到先得，然后根據(jù)http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection上描述的ZooKeeper流程。

如果一個Leader失敗了，其他副本中的一個會自動選為新的Leader。

當(dāng)文檔被發(fā)送到Solr節(jié)點進(jìn)行索引時，系統(tǒng)首先確定該文檔屬于哪個碎片，然后確定哪個節(jié)點當(dāng)前正在主管該碎片的Leader。然后將文檔轉(zhuǎn)發(fā)給當(dāng)前Leader進(jìn)行索引，并且Leader將更新轉(zhuǎn)發(fā)給所有其他副本。

副本的類型

默認(rèn)情況下，如果leader失敗，所有副本都有資格成為leader。但是，這是有要求的：如果所有副本都可以在任何時候成為leader，那么每個副本都必須始終與其leader保持同步。添加到leader的新文檔必須路由到副本，每個副本必須提交。如果副本發(fā)生故障或暫時不可用，然后重新加入群集，則恢復(fù)可能會很慢，因為它錯過了大量的更新。

這些問題對于大多數(shù)用戶來說不是問題。但是，如果副本的表現(xiàn)更像前一種模式，則某些用例會更好一些，或者不是實時同步，或者根本就沒有資格成為leader。

Solr通過允許您在創(chuàng)建新集合或添加副本時設(shè)置副本類型來完成此操作?？捎玫念愋褪牵?/p>

• NRT：這是默認(rèn)的設(shè)置。NRT副本（NRT = NearRealTime）維護(hù)事務(wù)日志，并將新文檔寫入本地索引。任何這種類型的副本都有資格成為leader。傳統(tǒng)上，這是Solr唯一支持的類型。
• TLOG：這種類型的副本維護(hù)事務(wù)日志，但不會在本地索引文檔更改。這種類型有助于加快索引，因為副本中不需要發(fā)生任何提交。當(dāng)這種類型的副本需要更新其索引時，通過復(fù)制leader的索引來實現(xiàn)。這種類型的復(fù)制品也有資格成為碎片的leader；它會通過首先處理它的事務(wù)日志來做到這一點。如果它確實成為leader，它將表現(xiàn)得如同它是NRT類型的復(fù)制品一樣。
• PULL：這種類型的副本不會維護(hù)事務(wù)日志，也不會在本地修改索引文檔。它只復(fù)制碎片leader的索引。沒有資格成為碎片leader，根本不參加碎片leader候選。

如果在創(chuàng)建時未指定副本的類型，則將是NRT類型。

組合群集中的副本類型

有三種推薦的副本類型的組合：

• 所有NRT副本
• 所有TLOG副本
• 帶有PULL副本的TLOG副本

所有NRT副本

將其用于小型到中型的群集，甚至是更新（索引）吞吐量不太高的大型群集。NRT是唯一支持soft-commits的副本，所以在需要NearRealTime時也可以使用這種組合。

所有TLOG副本

如果不需要NearRealTime，并且每個碎片的副本數(shù)量很高，則使用此組合，但是您仍然希望所有副本能夠處理更新請求。

TLOG副本加上PULL副本

如果不需要NearRealTime，則每個分片的副本數(shù)很高，并且希望通過文檔更新提高搜索查詢的可用性，即使這意味著暫時服務(wù)過時的結(jié)果，也可以使用此組合。

副本類型的其他組合

不推薦其他副本類型的組合。如果碎片中的多個副本正在寫入自己的索引，而不是從NRT副本中復(fù)制，則leader選舉可能導(dǎo)致碎片的所有副本與leader不同步，并且所有副本都必須復(fù)制完整索引。

使用PULL副本恢復(fù)

如果PULL副本下降或離開群集，則需要考慮幾個方案。

如果PULL副本由于leader關(guān)閉而無法同步到leader，則不會發(fā)生復(fù)制。但是，它將繼續(xù)提供查詢服務(wù)。一旦它可以再次連接到leader，副本將恢復(fù)。

如果PULL副本無法連接到ZooKeeper，它將從群集中刪除，查詢將不會從群集路由到它。

如果PULL副本因任何其他原因死亡或無法訪問，將無法進(jìn)行查詢。當(dāng)它重新加入集群時，它將從leader復(fù)制，當(dāng)完成時，它將準(zhǔn)備再次提供查詢服務(wù)。

文檔路由

Solr提供了在創(chuàng)建集合時通過指定router.name參數(shù)來指定集合使用的路由器實現(xiàn)的功能。

如果使用compositeId路由器（默認(rèn)），則可以在文檔ID中使用前綴發(fā)送文檔，該文檔ID將用于計算哈希Solr用于確定文檔發(fā)送到索引的碎片。前綴可以是您想要的任何東西（例如，它不一定是分片名稱），但它必須是一致的，所以Solr的行為一致。

例如，如果要為客戶共同定位文檔，則可以使用客戶名稱或ID作為前綴。如果您的客戶是“IBM”，例如，ID為“12345”的文檔，則可以在文檔ID字段中插入前綴“IBM！12345”。感嘆號（'！'）在這里至關(guān)重要，因為它區(qū)分了用于確定哪個分片用于指引文檔的前綴。

然后在查詢時，用_route_參數(shù)（即，q=solr&_route_=IBM!）將查詢前綴（es）包含到查詢中，以將查詢引導(dǎo)到特定的碎片。在某些情況下，這可能會提高查詢性能，因為它在查詢所有碎片時克服了網(wǎng)絡(luò)延遲。

該compositeId路由器支持含有最多2級路由的前綴。例如：首先按地區(qū)進(jìn)行前綴路由，然后由客戶：“USA！IBM！12345”

另一個用例可能是：客戶“IBM”擁有大量文檔，并且希望將其分散到多個碎片中。這種用例的語法是：shard_key/num!document_id；其中 /num是從復(fù)合哈希中使用的分片密鑰中的比特數(shù)。

所以IBM/3!12345將從分片密鑰中獲取3位，從獨特的文檔ID中獲取29位，在集合中傳播占用超過1/8的碎片。同樣，如果num值是2，則會將文檔分散到碎片數(shù)量的1/4。在查詢時，您可以使用_route_參數(shù)（即q=solr&_route_=IBM/3!）將查詢的前綴（es）和位數(shù)包含到查詢中，以將查詢定向到特定的分片。

如果您不想影響文檔的存儲方式，則不需要在文檔ID中指定前綴。

如果創(chuàng)建了集合并在創(chuàng)建時定義了“隱式”路由器，則還可以定義一個router.field參數(shù)，以使用每個文檔中的字段標(biāo)識文檔所屬的分片。如果指定的字段在文檔中缺失，則該文檔將被拒絕。您也可以使用該_route_參數(shù)來命名特定的分片。

碎片分割

當(dāng)您在SolrCloud中創(chuàng)建一個集合時，您決定要使用的初始數(shù)字碎片。但是事先很難知道您需要的碎片的數(shù)量，特別是當(dāng)組織需求在可以隨時改變的時候，以及稍后發(fā)現(xiàn)您選擇錯誤的成本可能很高，包括創(chuàng)建新的內(nèi)核和重新索引您的所有數(shù)據(jù)。

分割碎片的能力在Collections API中。目前它允許將碎片分成兩部分?，F(xiàn)有的分片保持原樣，所以拆分操作有效地將數(shù)據(jù)的兩個副本作為新的分片。準(zhǔn)備就緒后，您可以稍后刪除舊的碎片。

有關(guān)如何使用碎片分割的更多詳細(xì)信息，請參考“Collection API SPLITSHARD命令”部分。

在SolrCloud中忽略來自客戶端應(yīng)用程序的提交

在大多數(shù)情況下，在SolrCloud模式下運行時，索引客戶端應(yīng)用程序不應(yīng)該發(fā)送顯式提交請求。相反，您應(yīng)該使用openSearcher=false和自動soft-commits配置自動提交以使最近的更新在搜索請求中可見。這可以確保在集群中定期執(zhí)行自動提交。

為了強(qiáng)制客戶端應(yīng)用程序不應(yīng)該發(fā)送顯式提交的策略，您應(yīng)該更新將數(shù)據(jù)索引到SolrCloud的所有客戶端應(yīng)用程序。然而，這并不總是可行的，所以Solr提供了IgnoreCommitOptimizeUpdateProcessorFactory，它允許您忽略顯式的提交或優(yōu)化來自客戶應(yīng)用程序的請求，而不用重構(gòu)您的客戶應(yīng)用程序代碼。

要激活這個請求處理器，您需要將以下內(nèi)容添加到您的solrconfig.xml中：

<updateRequestProcessorChain name="ignore-commit-from-client" default="true">
  <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
    <int name="statusCode">200</int>
  </processor>
  <processor class="solr.LogUpdateProcessorFactory" />
  <processor class="solr.DistributedUpdateProcessorFactory" />
  <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>

如上面的示例所示，處理器將返回200給客戶端，但會忽略“提交/優(yōu)化”請求。請注意，您還需要連接SolrCloud所需的隱式處理器，因為此自定義鏈代替了默認(rèn)鏈。

在下面的示例中，處理器將使用帶有自定義錯誤消息的403代碼引發(fā)異常：

<updateRequestProcessorChain name="ignore-commit-from-client" default="true">
  <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
    <int name="statusCode">403</int>
    <str name="responseMessage">Thou shall not issue a commit!</str>
  </processor>
  <processor class="solr.LogUpdateProcessorFactory" />
  <processor class="solr.DistributedUpdateProcessorFactory" />
  <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>

最后，您還可以將其配置為只忽略優(yōu)化，并讓提交通過執(zhí)行：

<updateRequestProcessorChain name="ignore-optimize-only-from-client-403">
  <processor class="solr.IgnoreCommitOptimizeUpdateProcessorFactory">
    <str name="responseMessage">Thou shall not issue an optimize, but commits are OK!</str>
    <bool name="ignoreOptimizeOnly">true</bool>
  </processor>
  <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>