Elasticsearch集群

　　名词解释：
　　分片：分片就是对数据切分成了多个部分，Elasticsearch 默认会把一个索引分成五个分片，
　　数据保存在分片内，分片又被分配到集群内的各个节点里
　　副本：副本就是对原分片的复制，和原分片的内容是一样的，Elasticsearch 默认会生成一份副本，所以相当于是五个原分片和五个分片副本，相当于一份数据存了两份，并分了十个分片
　　主节点：即 Master 节点。主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。虽然主节点也可以协调节点，路由搜索和从客户端新增数据到数据节点，但最好不要使用这些专用的主节点。一个重要的原则是，尽可能做尽量少的工作。
　　数据节点：即 Data 节点。数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。数据节点对 CPU、内存、IO 要求较高，在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。
　　负载均衡节点：也称作 Client 节点，也称作客户端节点。当一个节点既不配置为主节点，也不配置为数据节点时，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。
　　预处理节点：也称作 Ingest 节点，在索引数据之前可以先对数据做预处理操作，所有节点其实默认都是支持 Ingest 操作的，也可以专门将某个节点配置为 Ingest 节点。 ES的节点类型
　　1.Master：主节点，每个集群都有且只有一个
　　尽量避免Master节点又是数据节点： node.data   true
　　主节点的主要职责是负责集群层面的相关操作，管理集群变更，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。
　　2.Voting：投票节点
　　node.voting_only = true（仅投票节点，即使配置了data.master = true，也不会参选, 但是仍然可以作为数据节点）。
　　3.Coordinating：协调节点
　　每一个节点都隐式的是一个协调节点，如果同时设置了data.master = false和data.data=false，那么此节点将成为仅协调节点。
　　4.Master-eligible node（候选节点）
　　可以通过选举成为Master的节点
　　5.Data node（数据节点）
　　主要负责数据存储和查询服务
　　配置：node.master = true node.data = true
　　这是ES节点默认配置，既作为候选节点又作为数据节点，这样的节点一旦被选举为Master，压力是比较大的，通常来说Master节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。node.master = true node.data = false
　　只作为候选节点，不作为数据节点，可参选Master节点，当选后成为真正的Master节点。node.master = false node.data = false
　　既不当候选节点，也不作为数据节点，那就是仅协调节点，负责负载均衡node.master=false node.data=true
　　不作为候选节点，但是作为数据节点，这样的节点主要负责数据存储和查询服务。
　　协调节点是如何工作的，他是怎么找到对应的节点的?
　　每个节点都保存了集群的状态,只有Master节点才能修改集群的状态信息
　　集群状态(Cluster Starte),维护了一个集群中,必要的信息
　　所有的节点信息
　　所有的索引和其相关的Mapping与Setting信息
　　分片的路由信息
　　协调节点作为es节点中的一个节点，默认情况下es集群中所有的节点都能当协调节点，主要作用于请求转发，请求响应处理等轻量级操作。
　　这意味着如果它们接收到用户请求，它们就可以处理用户请求 集群健康状态GET /_cluster/health
　　status   字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：
　　green  所有的主分片和副本分片都正常运行。
　　yellow  所有的主分片都正常运行，但不是所有的副本分片都正常运行。
　　red  有主分片没能正常运行
　　路由一个文档到一个分片中
　　当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片  1   还是分片 2   中呢？
　　首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的： shard = hash(routing) % number_of_primary_shards
　　routing   是一个可变值，默认是文档的 _id   ，也可以设置成一个自定义的值。 routing   通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards   （主分片的数量）后得到 余数 。这个分布在 0   到 number_of_primary_shards-1   之间的余数，就是我们所寻求的文档所在分片的位置。主分片和副本分片如何交互
　　我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将所有的请求发送到  Node 1   ，我们将其称为  协调节点(coordinating node)   。 新建、索引和删除文档
　　以下是在主副分片和任何副本分片上面 成功新建，索引和删除文档所需要的步骤顺序： 客户端向  Node 1   发送新建、索引或者删除请求。节点使用文档的  _id   确定文档属于分片 0 。请求会被转发到 Node 3  ，因为分片 0 的主分片目前被分配在 Node 3   上。Node 3   在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1   和 Node 2   的副本分片上。一旦所有的副本分片都报告成功, Node 3   将向协调节点报告成功，协调节点向客户端报告成功
　　consistency 一直性：参数的值可以设为  one   （只要主分片状态 ok 就允许执行_写_操作）, all  （必须要主分片和所有副本分片的状态没问题才允许执行_写_操作）, 或  quorum   。默认值为  quorum   , 即大多数的分片副本状态没问题就允许执行_写_操作。 int( (primary + number_of_replicas) / 2 ) + 1es怎么实现master选举
　　master选举当然是由master-eligible节点发起 没有master节点；脑裂 产生2个master节点
　　深入理解 Elasticsearch 7.x 新的集群协调层：
　　https://easyice.cn/archives/332
　　Elasticsearch的选举机制
　　https://www.jianshu.com/p/bba684897544
　　elasticsearch 选主流程
　　https://www.easyice.cn/archives/164
　　elasticsearch的master选举机制
　　https://www.cnblogs.com/jelly12345/p/15319549.html
　　https://blog.csdn.net/ailiandeziwei/article/details/87856210
　　ES写入数据的过程客户端选择一个node发送请求过去，这个node就是coordinating node (协调节点)coordinating node，对document进行路由，将请求转发给对应的node实际上的node上的primary shard处理请求，然后将数据同步到replica nodecoordinating node，如果发现primary node和所有的replica node都搞定之后，就会返回请求到客户端
　　shard_num = hash(_routing) % num_primary_shards
　　其中  _routing 是一个可变值，默认是文档的  _id  的值 ，也可以设置成一个自定义的值。 _routing 通过 hash 函数生成一个数字，然后这个数字再除以 num_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。 这就解释了为什么我们要在创建索引的时候就确定好主分片的数量   并且永远不会改变这个数量 ：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。 写入数据底层原理
　　数据先写入到buffer里面，在buffer里面的数据时搜索不到的，同时将数据写入到translog日志文件之中；如果buffer快满了，或是一段时间之后(定时)，就会将buffer数据refresh到一个新的OS cache之中，然后每隔1秒，就会将OS cache的数据写入到segment file之中，但是如果每一秒钟没有新的数据到buffer之中，就会创建一个新的空的segment file，只要buffer中的数据被refresh到OS cache之中，就代表这个数据可以被搜索到了。当然可以通过restful api 和Java api，手动的执行一次refresh操作，就是手动的将buffer中的数据刷入到OS cache之中，让数据立马搜索到，只要数据被输入到OS cache之中，buffer的内容就会被清空了。同时进行的是，数据到shard之后，就会将数据写入到translog之中，每隔5秒将translog之中的数据持久化到磁盘之中重复以上的操作，每次一条数据写入buffer，同时会写入一条日志到translog日志文件之中去，这个translog文件会不断的变大，当达到一定的程度之后，就会触发commit操作。将一个commit point写入到磁盘文件，里面标识着这个commit point 对应的所有segment file强行将OS cache 之中的数据都fsync到磁盘文件中去。
　　解释：translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志问价之中，一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件的数据，恢复到内存buffer和OS cache之中。
　　将现有的translog文件进行清空，然后在重新启动一个translog，此时commit就算是成功了，默认的是每隔30分钟进行一次commit，但是如果translog的文件过大，也会触发commit，整个commit过程就叫做一个flush操作，我们也可以通过ES API,手动执行flush操作，手动将OS cache 的数据fsync到磁盘上面去，记录一个commit point，清空translog文件
　　补充：其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差。
　　如果时删除操作，commit的时候会产生一个.del文件，里面讲某个doc标记为delete状态，那么搜索的时候，会根据.del文件的状态，就知道那个文件被删除了。
　　如果时更新操作，就是讲原来的doc标识为delete状态，然后重新写入一条数据即可。
　　buffer每次更新一次，就会产生一个segment file 文件，所以在默认情况之下，就会产生很多的segment file 文件，将会定期执行merge操作
　　每次merge的时候，就会将多个segment file 文件进行合并为一个，同时将标记为delete的文件进行删除，然后将新的segment file 文件写入到磁盘，这里会写一个commit point，标识所有的新的segment file，然后打开新的segment file供搜索使用。删除和更新
　　段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。 取而代之的是，每个提交点会包含一个  .del   文件，文件中会列出这些被删除文档的段信息。
　　当一个文档被 ＂删除＂ 时，它实际上只是在  .del   文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
　　文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。 段合并
　　由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。
　　Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。
　　段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。
　　合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然 有足够的资源很好地执行 Elasticsearch-head 图形化界面的安装
　　https://blog.csdn.net/qq_21299835/article/details/106534644http.cors.enabled: true http.cors.allow-origin: ＂*＂ # 统一的集群名 cluster.name: my-es #当前节点名 node.name: node-1 #对外暴露端口使外网访问 network.host: 127.0.0.1 #对外暴露端口 http.port: 9201 #集群间通讯端口号 transport.tcp.port: 9301 #集群的ip集合 discovery.zen.ping.unicast.hosts: [＂127.0.0.1:9301＂,＂127.0.0.1:9302＂,＂127.0.0.1:9303＂]   http.cors.enabled: true http.cors.allow-origin: ＂*＂ # 统一的集群名 cluster.name: my-es #当前节点名 node.name: node-2 #对外暴露端口使外网访问 network.host: 127.0.0.1 #对外暴露端口 http.port: 9202 #集群间通讯端口号 transport.tcp.port: 9302 #集群的ip集合 discovery.zen.ping.unicast.hosts: [＂127.0.0.1:9301＂,＂127.0.0.1:9302＂,＂127.0.0.1:9303＂]  http.cors.enabled: true http.cors.allow-origin: ＂*＂ # 统一的集群名 cluster.name: my-es #当前节点名 node.name: node-3 #对外暴露端口使外网访问 network.host: 127.0.0.1 #对外暴露端口 http.port: 9203 #集群间通讯端口号 transport.tcp.port: 9303 #集群的ip集合 discovery.zen.ping.unicast.hosts: [＂127.0.0.1:9301＂,＂127.0.0.1:9302＂,＂127.0.0.1:9303＂]