solr的基本概念

前面简单的学习了一下solr的基本操作，但是自己在看文档的时候对一些基本概念还是有一点迷惑，所以觉得有必要记录一下，便于自己的理解。
上次学习solr的时候提到了一个概念就是"core"，core表示的一个完整的索引，可以近似的看作一个数据库。core里面可以存放很多份数据，而且一个solr实例可以有多个core。
而solrcloud集群模式下，有一些逻辑概念，这些逻辑概念在一些物理概念上。
首先就是collection，这个我觉得可以理解为一个逻辑上的core，一个集群可以有多个collection，每一个collection都是一个逻辑上完整的文档索引。
shard，翻译成中文就是分片，它也是一个抽象的概念，一个collection可以分割成多个分片，每个分片包含的内容都是这个collection文档的子集，也就是说所有分片的内容加在一起就是完整的collection的文档。
此外，一个shard可以有一个或多个副本（solr不是主从模式），即replica，副本的内容和其对应的shard内容是一致的。cloud模式下，系统会从每个shard的的副本(只是副本，并不包括shard自身)中选择一个replica作为这个shard所有副本的leader，其他作为备份以提高可用性。而每个副本会存放到不同的节点上，这样一旦leader出现问题，会从剩下的副本中选择出一个新的leader。每个副本使用的是相同的配置文件。
node-节点，一个集群由多个节点组成，一个节点可以有一个或多个core，这个core就是shard逻辑概念的物理体现。我觉得cloud模式下，core理解为副本，即replica更合适一点。
solrcloud模式下，逻辑概念和物理概念之间的联系是通过副本完成的，具体应该说是副本的leader完成的。solrcloud模式下，solrcloud收到一个document索引请求后，会先判断这个document所属的shard，然后定位到这个shard的副本中leader所在的节点，然后这个document被发送给leader完成索引，最后leader将更新转发给其他副本，以保证数据的一致性。
副本类型：
理论上，shard的所有副本都有机会成为leader，如果当前的leader挂掉了，那么剩下的副本都有可能成为新的leader，这样就邀保证，leader和其他副本的数据在任何时候都必须保持一致，一旦leader更新了文档内容，必须同时将更新内容发送给其他副本，然后其他副本提交更新。加入非leader副本挂掉，而这个期间如果有大量新的数据写入，等该副本重新加入到集群，它的恢复过程可能就会比较慢。
为了解决这个问题，solr提供了几种副本的类型供用户选择，以便解决上面说到的问题

1、NRT

NearRealTime，这个是默认的，根据名字理解就是接近实时，但是并不完全保证leader和副本数据是实时同步的。NRT维护一个事务日志并将新文档写入本地索引。任何此类复制品都有资格成为leader。

2、TLOG

这个类型的副本维护事务日志，但不会索引文档更改。 此类型有助于加快索引速度，因为副本中不需要提交任何提交。 当这种类型的副本需要更新其索引时，它通过从领导者复制索引来实现。 这种类型的复制品也有资格成为碎片领导者; 它会通过首先处理其事务日志来实现。 如果它确实成为领导者，它的行为将与NRT类型的副本相同。

3、PULL

这类副本不会在本地维护事务日志或索引文档更改。它只从副本的leader复制索引。它没有资格副本领袖，也不会参加副本的leader选举，也就是说它只能作为副本的备份存在。