1.与集群有关的一些概念
数据分片：
数据分片（shard），单台服务器的存储容量是有限的，把一份数据切分成很多份，每一份存储到不同的节点上去，从而减少单台的压力。
数据副本:
数据副本（replica），在分布式集群中，如果不做备份，单点故障会硬气数据丢失，应对办法是将一份数据复制成很多份，一份就是一个副本，将副本存储到不同的节点上去。
es在创建索引的时候会指定每个索引的数据分片喝数据副本各自的数量：
put /yx { "settings":{ "number_of_shards": 3,//分片数 "numbser_of_replicas": 1//副本数 } }
2.集群搭建
集群规划：
cluster name，集群名称，同一集群下，所有node的cluster name要相同。
| Node Name | cluster name | ip | http | tcp |
| node-01 | yx-elastic | 127.0.0.1 | 9201 | 9301 |
| node-02 | yx-elastic | 127.0.0.1 | 9202 | 9302 |
| node-03 | yx-elastic | 127.0.0.1 | 9203 | 9303 |
3.集群搭建
elasticsearch.yml:
三个节点的区别只在于node.name、数据路径、日志路径、http端口、tcp端口不同，其它都相同，此处以node-01为例。
#允许跨名访问 http.cors.enabled: true #当设置允许跨域，默认为， 表示支持所有域名 http.cors.allow-origin: "*" #允许所有节点访问 network.host: 0.0.0.0 #集群的名称，同一个集群下所有节点的集群名称应该一致 cluster.name: yx-elasticsearch #当前节点名称 每个节点不一样 node.name: node-01 #数据的存放路径，每个节点不一样，不同es 服务器对应的data和log存储的路径不能一样 path.data: D:\es\elasticsearch-9301\data #日志的存放路径 path.logs: D:\es\elasticsearch-9301\logs #HTTP协议的对外端口，每个节点不一样，默认: 9200 http.port: 9201 #TCP协议对外端口 每个节点不一样，默认: 9300 transport.tcp.port: 9301 #三个节点相互发现，包含自己，使用TCP协议的端口号 discovery.zen.ping.unicast.hosts: ["127.0.0.1:9301","127.0.0.1:9302","127.0.0.1:9303"] #声明大于几个的投票主节点有效，设置为(nodes / 2) + 1 discovery.zen.minimum_master_nodes: 2 #是否为主节点 node.master: true
4.kibana链接集群
kibana.yml:
elasticsearch.hosts: ["http://localhost:9201"]
5.选举流程
Zen Discovery 进程：ES的每个节点都有一个Zen Discovery 组件，这个组件会启动一个Zen Discovery 进程，这个组件是集成在ES中的代码逻辑，它用于记录全局节点的信息，管理集群中节点的发现、加入、离开，以及主节点选举。也就是说每个ES节点上都存着一份全局节点的信息。
启动阶段： 当一个节点（Node）启动时，它会加入集群，并尝试与其他节点建立连接。这个节点会发送一个 "join" 请求，广播给当前集群中的所有节点。这个请求包含了节点的信息，比如节点的ID、地址和端口等。
选举过程：
首先是master节点的候选资格：
在 Elasticsearch 集群中，有一些节点被标记为 "master-eligible" 节点，这表示它们有资格成为主节点。这些节点在配置文件中的 node.master 属性为 true。
接下来是选举过程：
一旦有足够的主节点候选节点发现彼此并形成了一个集群，它们就会开始主节点选举的过程。这个过程需要多数（大多数）的主节点候选节点在线并参与选举，这也被称为“法定人数”（Quorum）。“法定人数”是为了避免脑裂（split-brain）情况，Elasticsearch要求一个法定人数的同意才能选举出一个新的主节点。在旧版本中（如7.x及以前），这是通过discovery.zen.minimum_master_nodes设置来配置的，它通常设置为(master-eligible nodes / 2) + 1。在更高版本中，这个设置已经被内置的选举机制替代，不需要手动配置。选举过程中采用节点之间相互投票的机制，选举出主节点来， 节点在决定给哪个节点投票时会考虑多个因素，包括节点的健康状况、网络稳定性、集群状态的完整性，以及节点的历史记录等。
故障检测： Zen Discovery 使用故障检测机制来确定节点是否可用。节点之间相互发送 Ping 和 Pong 消息以检测对方的状态。如果一个节点在一定时间内没有响应，它被认为是不可用的。一旦出现master节点不可用的状态，集群将会开启重新选举。需要进行重新选举的时候要是发现集群存货人数已经不及法定人数，那么集群将会对外拒绝服务。
持久化： 主节点的信息会被持久化存储，以便在节点重启后，集群能够快速地恢复到之前的状态。
6.请求流程
写请求处理流程（如索引或更新文档）：
- 接收请求： 写请求可以发送到集群中的任何节点。该节点成为请求的协调节点。
- 确定主分片： 协调节点根据文档的ID和索引元数据来决定哪个主分片负责处理该文档。这通常是通过哈希文档ID来完成的。
- 转发请求： 协调节点将请求转发到托管该主分片的节点。
- 处理和复制： 主分片节点处理写请求（如索引或更新文档），然后将相同的操作复制到所有对应的副本分片。
- 确认和响应： 一旦主分片和所有必要的副本分片成功处理了请求，协调节点向客户端发送成功响应。
读请求处理流程（如搜索或获取文档）：
- 接收请求： 读请求可以发送到集群中的任何节点。该节点成为请求的协调节点。
- 确定分片位置： 对于文档获取请求，协调节点会计算出哪个主分片或副本分片拥有该文档。对于搜索请求，协调节点确定要查询的所有相关分片。
- 查询分片： 协调节点并行地向那些托管相关分片的节点发送请求。读请求可以由主分片或任何副本分片来处理。
- 汇总结果： 对于搜索请求，协调节点从所有查询的分片收集结果，合并成一个全局的搜索结果。
- 响应客户端： 最终的结果被发送回给客户端。
7.master的作用
在Elasticsearch中，每个节点都维护着关于集群状态的本地副本，这包括了分片的分配和位置信息。这意味着协调节点通常能够独立地确定请求应该路由到哪个节点上，而不需要每次都查询主节点。那主节点的作用是什么喃？
主节点（Master Node）在Elasticsearch集群中扮演着关键的管理和协调角色。以下是主节点在集群中的主要职责和功能：
集群管理： 主节点负责整个集群的管理任务。这包括集群的创建、配置、状态监控以及集群范围内的一些操作。
节点协调： 主节点负责协调集群中的所有节点。它会与其他节点通信，确保集群中的每个节点都处于活动状态，同时负责监控节点的健康状况。
分片分配： 主节点负责决定每个分片（Shard）应该分配到集群中的哪个节点上。它会在节点加入或离开集群时重新分配分片，以保持集群的均衡和高可用性。
主节点选举： 如果当前的主节点出现故障或不可用，集群中的其他节点会通过选举机制选择一个新的主节点。主节点选举确保了即使主节点出现问题，集群也能够继续正常运行。
索引创建和删除： 主节点负责处理索引的创建和删除请求。当索引被创建时，主节点会决定每个分片应该在哪个节点上创建。
集群状态维护： 主节点维护着关于整个集群的状态信息，包括节点的健康状况、集群设置、索引元数据等。这些信息对于集群的正常运行非常重要。
路由请求： 主节点在协助客户端请求路由时发挥作用。虽然数据的实际读写操作是在数据节点上进行的，但主节点负责确定数据分布和分片的位置，从而协助请求的有效路由。
集群级别的操作： 主节点可以执行一些集群级别的操作，例如创建和删除索引、更新集群的设置、执行全局搜索等。
