【SolrCloud原理】分布式搜索引擎

SolrCloud作为分布式搜索引擎，具备以下几个特质：

可拓展性

可扩展性就是指可以通过扩大集群的规模来实现性能的提升。有两种方式来实现可扩展性，一种是纵向扩展，可以理解为增强外部硬件环境对集群的支撑，比如加快CPU速度，增加内存，提升磁盘I/O性能等，另一种是横向扩展，就是分布式系统中使用的通过增加节点来扩大集群规模。
SolrCloud采用的时横向扩展，可以通过两个方式来实现扩展，一种是增加shard，它实现的是将大数据量的index切分成多个小的index，这种方式是从将每个shard的数据量的角度来提升SolrCloud的性能的；另一种是增加replica，即增加shard的备份的数量，这种方式的优点是增加SolrCloud的并发查询能力以及容灾能力。一般来说，SolrCloud的查询能力随着资源(即shard)的增加成正比。

高可用性

高可用性主要是指SolrCloud的容灾能力，SolrCloud使用leader和replica以及交叉备份的方式实现数据的冗余以实现很好的容灾性能，leader和replica是同一shard的相同数据，一般存放在不同的主机上。当某台主机宕机时，该主机的副本数据在另外的主机上具有备份，这样就确保了数据不会丢失。同时SolrCloud在进行查询的时候是只对认准shard而不区分leader和replica，所以即使有一台主机宕机了也不会影响SolrCloud的查询结果，它只是稍微影响了查询性能。能够容纳多少台主机同时宕机而不影响查询业务，就要根据具体的副本策略来分析了。

一致性

对于一个分布式搜索引擎来说，一致性，性能，以及分割容差是三个主要指标，其中一致性与读写性能是个矛盾的指标，以SolrCloud为例，SolrCloud选择了一致性而适当放弃了写的性能。SolrCloud具有replica时，当有数据建立索引，SolrCloud首先将数据update至leader shard，然后leadershard再将数据进行分发至各个replica shard，leader shard进行分发是个同步的过程，也就是说它会一直等到所以replica shard的数据update成功才会返回成功，中间一旦出现错误就视为失败，这样就充分保证了leader和replica的数据一致性，当然这也就降低了写的速度。这里需要说明的是，当replica是不上线状态时候，SolrCloud的leader是不会分发至这个replica shard的。至于为什么SolrCloud对弱一致性的零容忍态度，主要是避免索引的部分成功以及多个shard查询结果的不同。
举个栗子，Kafka也有一个类似功能的参数request.required.ack，也是用来控制数据写入策略的。
Kafka Producer的ack有3中机制，初始化Producer时可以通过配置request.required.acks不同的值来实现。
0：这意味着生产者producer不等待来自broker同步完成的确认继续发送下一条（批）消息，相当于异步发送。此选项提供最低的延迟但最弱的耐久性保证（当服务器发生故障时某些数据会丢失，如leader已死，但producer并不知情，发出去的信息broker就收不到）。
1：这意味着producer在leader已成功收到的数据并得到确认后发送下一条message。此选项提供了更好的耐久性为客户等待服务器确认请求成功（被写入死亡leader但尚未复制将失去了唯一的消息）。
-1：这意味着producer在follower副本确认接收到数据后才算一次发送完成。
此选项提供最好的耐久性，我们保证没有信息将丢失，只要至少一个同步副本保持存活。
三种机制，性能依次递减 (producer吞吐量降低)，数据健壮性则依次递增。舍得舍得，有舍才有得！

简单性

当有主机recovering失败了，当我们处理完失败的原因后将该主机上线，SolrCloud会自动从leader那进行数据同步。

伸缩性

SolrCloud支持将一份shard分成两份小的shard。

Reference
https://www.cnblogs.com/rcfeng/p/4077663.html