solrcloud集群部署二

约定不等于承诺〃 2022-04-13 07:42 289阅读 0赞

# 四、SolrCloud概述 #

### 1、单点问题总结 ###

单点的Solr服务缺点：

A：能存储的数据量有限，如果是海量数据，无法存储，
    
    B：容易出现单点故障
    
    C：对高并发的处理能力差

### 2、单点Solr问题解决 ###

1.	把原始的Solr的一个逻辑核心（collection），拆分成多个Shard(分片)，每个分片存储原始总数据的部分数据

### ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70][] ###

2.	拆分后新的问题：
    原始数据切分为多个分片之后，当SolrJ(客户端)来访问时，具体访问哪台机器上的数据分片呢？
    如果当SolrJ来访问时，填写具体的IP，那么当分片足够多的时候显然是不可能的，
    所以我们引入一个管家，zookeeper，我们通过它来提供信息，以便于我们访问这些分布式分片

### ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 1][] ###

### 3、分布式方案问题 ###

多个数据分片组成了一个逻辑的collection，但由于多个分片存储在多个机器上，如果某台机器宕机，
    那么势必会造成数据的不完整，从整体逻辑来说这是不允许的，所以我们对每个分片进行集群，
    在不添加机器的前提下，数据存储选择交叉存储，每台机器存储数据分片的一个或者多个副本（replica）。
    这样就形成了SolrCloud的雏形：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 2][]

### 说明： ###

1，	数据量太大，一台机器放不下，一台机器的性能不行 
    2，	如何分？分原始的collection(核心)，分成一个个shard，只要shard>1就是分布式
    3，	由于存在单点故障，所以要对分片shard做集群操作。只要副本数量>1就是 集群(多个副本不在同一台机器)
    4，	Collection是逻辑的，由多个shard组成，
    5，	Replica副本，可以有多个，只要副本>1并且没有存储在同一台机器就是集群

### 4、SolrCloud逻辑结构详解 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 3][]

说明：

为了实现海量数据的存储，我们会把索引进行分片（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，分片最好不要超过三个

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 4][]

# 五、Zookeeper分布式协调服务 #

### 1、Zookeeper概述 ###

Zookeeper是集群分布式系统中大管家
    
    分布式集群系统比较复杂，子模块很多，但是子模块往往不是孤立存在的，它们彼此之间需要协作和交互，
    各个子系统就好比动物园里的动物，为了使各个子系统能正常为用户提供统一的服务，必须需要一种机制来进行协调 —— 这就是ZooKeeper
    
    Zookeeper 是为分布式应用程序提供高性能协调服务的工具集合，
    也是Google的Chubby一个开源的实现，是Hadoop 的分布式协调服务

### 2、Zookeeper集群结构 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 5][]

在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的多个副本之间选主)

不可逆：所有操作都是不可逆的

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70]: /images/20220413/8f9f6a4896c147e1aec844305c431e51.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 1]: /images/20220413/8421498b109044b1aef5ddee3d7729b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 2]: /images/20220413/7bd5e22787394da19739c625ad352b63.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 3]: /images/20220413/6af661bc139e4f8fa2ab30d6d68baa0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 4]: /images/20220413/b98fa41e5a4a408795e21ae3449d77e8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 5]: /images/20220413/e0f98448bb5a44e4abd312c3bab3da1d.png