前言

在上篇的es基本知识中我们简单的介绍了es的基本概念和常用的API，本文我们着重介绍ES的鉴权和集群下的分片控制

环境如下：
centos 7.6
elasticsearch-7.9.3
kibana-7.9.3

ElasticSearch的鉴权

安装完es和kibana

可以参考前言的连接地址，进行安装

es的密码设置

修改es的配置文件

vim config/elasticsearch.yml
#es的安全配置
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true

启动脚本，为以下用户设置密码

bin/elasticsearch-setup-passwords interactive

访问es测试

测试结果如下，提示输入密码

kibana密码设置

修改kibana的配置文件

vim config/kibana.yml
elasticsearch.username: "elastic"
elasticsearch.password: "123456"

重启kibana

nohup ./kibana &

登录测试

自定义用户和授权

我们也可以在kibana中直接新增用户，并授予对应的权限，这里不做过多讨论

集群介绍

单机节点

我们首先创建一个单机版集群，定义一个index为user，主分区3个，副本1个

PUT user 
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}

当前节点分布为：

表示当前集群的全部主分片都正常运行，但是副本分片没有全部处在正常状态
3个副本分片都是 Unassigned —— 它们都没有被分配到任何节点。在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。

集群扩容

单节点集群有个很明显的缺点，那就是单点故障。但是幸运的是，我们只需要在启动一个节点就可以防止数据的丢失。我们只需要在启动一个es，并且指定相同的cluster.name，它就会发现集群并自动加入其中，当然这个操作只能在统一机器上运行才会生效。如果要在不同机器上组成集群，我们还需要指定可连接的主机列表discovery.seed_hosts: ["xxx:9300", "xxx:9300"]，来配置可以加入的节点。

当我们启动第二个节点Node2后：

当第二个节点加入到集群后，3个副本分片将会分配到这个节点上——每个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。

当我们启动第三个节点Node3后：

当存在两个节点的时候，我们的集群已经没有了单点故障。但是怎样为我们的正在增长中的应用程序按需扩容呢？这时我们启动第三个节点，我们的集群将会拥有三个节点的集群 : 集群为了分散负载而对分片进行重新分配

Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有2个分片，而不是之前的3个。这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片的性能将会得到提升。

分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。我们这个拥有6个分片（3个主分片和3个副本分片）的索引可以最大扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源，可以提供系统的吞吐量。

产生故障

我们手动关闭第一个节点：

我们关闭的节点是一个主节点node1。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node 3 。在我们关闭 Node 1 的同时也失去了主分片 0 和 2 ，并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。

如果我们重新启动 Node 1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将恢复成之前的状态。如果 Node 1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。和之前的集群相比，只是Master节点切换了。

路由规则

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

 shard = hash(routing) % number_of_primary_shards

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

ElasticSearch鉴权和集群介绍

前言