版权声明：转载请注明原始链接 https://blog.csdn.net/sswqzx/article/details/84580428
四、SolrCloud概述
1、单点问题总结
单点的Solr服务缺点：
A：能存储的数据量有限，如果是海量数据，无法存储，
B：容易出现单点故障
C：对高并发的处理能力差
2、单点Solr问题解决
1. 把原始的Solr的一个逻辑核心（collection），拆分成多个Shard(分片)，每个分片存储原始总数据的部分数据
2. 拆分后新的问题：
原始数据切分为多个分片之后，当SolrJ(客户端)来访问时，具体访问哪台机器上的数据分片呢？
如果当SolrJ来访问时，填写具体的IP，那么当分片足够多的时候显然是不可能的，
所以我们引入一个管家，zookeeper，我们通过它来提供信息，以便于我们访问这些分布式分片
3、分布式方案问题
多个数据分片组成了一个逻辑的collection，但由于多个分片存储在多个机器上，如果某台机器宕机，
那么势必会造成数据的不完整，从整体逻辑来说这是不允许的，所以我们对每个分片进行集群，
在不添加机器的前提下，数据存储选择交叉存储，每台机器存储数据分片的一个或者多个副本（replica）。
这样就形成了SolrCloud的雏形：
说明：
1， 数据量太大，一台机器放不下，一台机器的性能不行
2， 如何分？分原始的collection(核心)，分成一个个shard，只要shard>1就是分布式
3， 由于存在单点故障，所以要对分片shard做集群操作。只要副本数量>1就是 集群(多个副本不在同一台机器)
4， Collection是逻辑的，由多个shard组成，
5， Replica副本，可以有多个，只要副本>1并且没有存储在同一台机器就是集群
4、SolrCloud逻辑结构详解
说明：
为了实现海量数据的存储，我们会把索引进行分片（Shard），把分片后的数据存储到不同Solr节点。
为了保证节点数据的高可用，避免单点故障，我们又会对每一个Shard进行复制，
产生很多副本（Replicas），每一个副本对于一个Solr节点中的一个core
用户访问的时候，可以访问任何一个会被自动分配到任何一个可用副本进行查询。
Collection：在SolrCloud集群中逻辑意义上的完整的索引。一般会包含多个Shard（分片），如果大于1个分片，那么就是分布式存储。
Shard: Collection的逻辑分片。每个Shard被化成一个或者多个replicas（副本）
Replica: Shard的一个副本，存储在Solr集群的某一台机器中（就是一个节点），
对应这台Solr的一个Core，如果机器上存放了多个副本，那本机器的solr将有多个core。
Collection和Shard只是逻辑存在的 ，真实存在的只有replica，replica其实就是shard。
分片的数量不要多于机器的数量，3，分片最好不要超过三个
五、Zookeeper分布式协调服务
1、Zookeeper概述
Zookeeper是集群分布式系统中大管家
分布式集群系统比较复杂，子模块很多，但是子模块往往不是孤立存在的，它们彼此之间需要协作和交互，
各个子系统就好比动物园里的动物，为了使各个子系统能正常为用户提供统一的服务，必须需要一种机制来进行协调 —— 这就是ZooKeeper
Zookeeper 是为分布式应用程序提供高性能协调服务的工具集合，
也是Google的Chubby一个开源的实现，是Hadoop 的分布式协调服务
2、Zookeeper集群结构
在ZooKeeper集群当中，集群中的服务器角色有两种：1个Leader和多个Follower，具体功能如下：
1）领导者(leader)，负责进行投票的发起和决议，监控集群中的节点是否存活（心跳机制），进行分配资源
2）follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票
特点：
A：Zookeeper：一个leader，多个follower组成的集群
B：全局数据一致（leader主持）：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
C：数据更新原子性，一次数据更新要么成功。
D：实时性，在一定时间范围内，client能读到最新数据，
E：半数机制：整个集群中只要有一半以上存活，就可以提供服务。因此通常Zookeeper由2n+1(n>=0)台servers组成，
每个server都知道彼此的存在。每个server都维护的内存状态镜像以及持久化存储的事务日志和快照。
为了保证Leader选举能获得到多数的支持，所以ZooKeeper集群的数量一般为奇数。对于2n+1台server，
只要有n+1台（大多数）server可用，整个系统保持可用
3、Zookeeeper的leader选主机制
假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动（全新集群）
1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报文 没有任何响应,所以它的选举状态一直是LOOKING状态
2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,
所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是
3),所以服务器1,2还是继续保持LOOKING状态.
3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,
此时有三台服务器选举了它,所以它成为了这次选举的leader.
4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,
但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
5) 服务器5启动,同4一样,当小弟.
注意： 但当集群节点服务器里有数据时、就按数据最新的节点服务器做为leader
4、Zookeeper的作用
Zookeeper包含一个简单的 原语集 ，分布式应用程序可以基于它实现：命名服务、配置维护、集群选主等
命名服务：注册节点信息，形成有层次的目录结构（类似Java的包名）。配置维护：配置信息的统一管理和动态切换(solrconfig.xml,schame.xml) 集群选主：确保整个集群中只有一个主，其它为从。并且当主挂了后，可以自动选主(同一shard的多个副本之间选主)不可逆：所有操作都是不可逆的