ElasticSearch 集群管理

集群介绍

集群：多个人做一样的事
分布式：多个人做不一样的事

为什么要集群，原来的项目都是单体架构，一旦机器挂了，那就不能进行工作了。若是我们用了三台机器，都存储一样的东西，这三个同时对外提供服务，一旦有一个挂了还不影响，这就是集群来解决高可用。集群还可以解决负载均衡的问题。

集群总结下：集群解决的问题就是：1、让系统高可用。2、分担请求压力。

但是以后业务数据越来越多，每个机器已经无法存储了，那怎么办？
不能是买个更好的机器吧，那也太土豪了吧，那我们就用很多个机器来存储数据，那么就变成了集群分布式架构。集群分布式架构就是原来每个机器都存一样的数据，现在A、B两台机器合在一起存一整个ES数据，C、D一起存一整个ES数据。
分布式解决的问题：1、分担存储和计算的压力，提速。2、解耦。

ElasticSearch 集群特点

1、ElasticSearch天然支持分布式，不用引用第三方的插件、组件。
2、ElasticSearch的设计隐藏了分布式本身的复杂性。ES把分布式设计的复杂性隐藏了，让用户少量的配置就可以完成分布式的搭建。你就搭建好集群就行，内部ES如何操作我们不用担心。

ElasticSearch集群分布式架构相关概念

1、集群(cluster)：一组拥有共同的cluster name的节点，节点就是ES的一个实例。

2、节点(node)：集群中的一个ElasticSearch实例。
3、索引(index)：es存储数据的地方，相当于关系数据库中的database概念。
4、分片(shard)：索引可以被拆分为不同的部分进行存储，成为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中。

一个索引被分片成了 0、1、2，分别存在了三个节点中。他们就是拥有共同名称的节点，作为一个集群。但是不能遇到故障，万一ES-node-1挂掉了，那就完蛋了。接下来引入下面的概念。
5、主分片(Primary shard)：相对于副本分片的定义。
6、副本分片(Replica shard)：每个主分片可以有一个或多个副本，数据和主分片一样。
但是每个节点都是自己的主分片和副本分片，机器一旦挂了还是完蛋了，那就让副本分片存在其他节点中。不要把鸡蛋放在一个篮子里，以上说的是实现过程，ES都帮我们处理了，不需要我们操心了。

搭建集群

前提：ES可是个吃货，配置一定要调高。建议2核2G。

Linux操作如下：

Linux操作如下：

node.master: true，nide.data: true 这两个都有true就是证明他都有竞争主节点的资格。

Linux操作如下：
若之前配置过单节点，那就把原来的删除掉。

配置第二台

Linux操作如下：

配置第三台：

Linux操作如下：

最后对日志文件进行授权

启动前要配置JVM的内存大小，不然就会报下方的错误。建议将三台的配置都改了，不然3G弄满了。

修改为256M

Linux操作如下：

启动三个服务 ./elasticsearch 一定不要用root权限启动。

访问下，访问不到就是防火墙的事了，那就切回root权限，关闭防火墙即可。命令：systemctl stop firewalld

这时候我们访问集群，在路径后面加 /_cat/health?v，这个时候应该是不成功的

报了主节点没发现的异常。
这时我们启动第二台的elasticsearch，再次访问

若在启动第三台，他就不会选举了，一号还是主节点。

使用Kibana配置和管理集群

Kibana配置就是把ES集群的地址配置到Kibana上。

Linux操作如下：

然后去bin目录，启动

打开浏览器访问下

点击stack monitoring

刚开始是关着的，给他打开

点击node

JAVAAPI访问集群

创建个索引

添加数据

创建实体，里面有三个ES的host、port。并创建get、set、toString方法。

application.yml

配置Client

通过集群的方式访问ES

以上代码跟之前学习的没有区别，集群就是把多台机器配置即可，那数据存到哪里了？分片呢？我们往下接着学习

集群原理

分片配置

在创建索引时，如果不设置指定的分片配置，默认主分片为1片，副本分片为1片。

之前我们创建的索引，在主节点上有数据，子节点也有数据，下图可以看到，主分片在2节点上，副本分片在主节点上。

那如何设置分片呢？

生成完一共6个节点，每个节点存的都不一样，任何一个挂了都不影响其他，这就是ES帮我们处理的。

现在模拟把第三台服务器挂掉

我们再查询下数据，也是可以访问的

回到kibana，3号已经挂掉了。

我们刷下页面，ES他会重新分配分片。

他又重新分配了，这就是节点的自平衡。不得不说这操作太嚣张了！！！！！
若你再把3号启动了，他又给你处理了，嚣张，嚣张。
知识点：分片与自平衡：当节点挂掉后，挂掉的节点分片会自平衡到其他节点中。
在ElasticSearch中，每个查询在每个分片的单个线程中执行，但是，可以并行处理多个分片。分片数量一旦确定好，不能修改。
那问题又来了，设置多少个分片合适呢？
索引分片推荐配置方案：
1、每个分片推荐大小10G~30G之间
2、分片数量推荐 = 节点数量 * 1~3倍比如你3个节点，推荐分片就是3~9个
思考：比如有1000GB的数据，应该有多少个分片？多少个节点？
40个分片 20个节点 1000除以 25G等于40 40除以2等于20节点

路由原理

文档存入对应的分片，ES计算分片编号的过程，成为路由。
那么ES怎么知道一个文档应该存入哪个分片呢？
查询时，根据文档id查询文档，ES又该去哪个分片中查询数据呢？

由于5号文档在2号节点上，他的副本分片就对应在1号节点上。

假如我们在查id为5的文档，但是我们算完在2节点上，但是2节点挂了，那么他就会去1节点上找数据。

脑裂

我们见下图，8个节点本来1号是主节点，后来3、4、7、8不认1号为主节点，让3号为主节点，这样出现两个集群这就是脑裂。

那如何解决呢？
把服务器停掉，在修复好，再启动。这个问题既然没有好的办法去解决，那就规避脑裂出现的可能。

那什么情况下可能出现脑裂呢？
第一种：网络原因

在外网上每个节点相互通信有延迟，3号访问1，1没给响应，4，7，8也发现1没响应，他们以为1挂了，那就揭竿而起了，3当了主节点
第二种：节点负载
主节点要处理数据，他工作量太大了，假死了。3，4，7，8又访问不了他了，就又揭竿而起了。

第三种：JVM内存回收

总结：

那如何避免呢？

集群扩容

集群停了，重新搭建即可，原来3个的配置文件，改为配置4个、5个等，即可。