Solr分片机制以及Solrcloud搭建及分片操作

Solr分片描述

分片是集合的逻辑分区，包含集合中文档的子集，这样集合中的每个文档都正好包含在一个分片中。集合中包含每个文档的分片取决于集合的整体“分片”策略。
当您的集合对于一个节点来说太大时，您可以通过创建多个分片将其分解并分段存储。
例如，您可能有一个集合，其中每个文档的“country”字段确定它是哪个shard的一部分，因此来自同一国家的文档位于同一个位置。不同的集合可能只在每个文档的uniquekey上使用“hash”来确定其分片。
在solrcloud之前，solr支持分布式搜索，允许跨多个分片执行一个查询，因此查询是针对整个solr索引执行的，搜索结果中不会遗漏任何文档。因此，在分片上分割索引并不是一个单独的solrcloud概念。
Solrcloud解决了这些限制。支持自动分发索引进程和查询，ZooKeeper提供故障转移和负载平衡。此外，每个分片都可以有多个副本，以增强健壮性。
Solrcloud 没有主从之分，相反，每个分片至少由一个物理副本组成，其中一个是领导者。领导者会自动当选，最初是基于先到先得的原则，然后根据zookeeper的选举原理。

每个分片中都有一个或多个副本，副本的类型有3种：

1. NRT:

This is the default. A NRT replica (NRT = NearRealTime) maintains a transaction log and writes new documents to it’s indexes locally. Any replica of this type is eligible to become a leader. Traditionally, this was the only type supported by Solr.
NRT：这是默认设置。NRT副本（NRT=NearRealtime）维护事务日志，并在本地将新文档写入其索引。此类型的任何副本都有资格成为领导者。传统上，这是solr支持的唯一类型。

2. TLOG:

This type of replica maintains a transaction log but does not index document changes locally. This type helps speed up indexing since no commits need to occur in the replicas. When this type of replica needs to update its index, it does so by replicating the index from the leader. This type of replica is also eligible to become a shard leader; it would do so by first processing its transaction log. If it does become a leader, it will behave the same as if it was a NRT type of replica.
TLOG：这种类型的副本维护事务日志，但不索引本地文档更改。这种类型有助于加速索引，因为副本中不需要进行提交。当这种类型的副本需要更新其索引时，它通过从领队复制索引来更新索引。这种类型的副本也有资格成为一个分片领队；它可以通过首先处理其事务日志来实现这一点。如果它真的成为一个领导者，它的行为将与它是一个NRT类型的复制品一样。

3. PULL:

This type of replica does not maintain a transaction log nor index document changes locally. It only replicates the index from the shard leader. It is not eligible to become a shard leader and doesn’t participate in shard leader election at all.
PULL：这种类型的副本既不维护事务日志，也不在本地更改索引文档。它只复制分片领导者的索引。它没有资格成为一个分片领袖，根本不参加分片领袖选举。