一. Elasticsearch架构原理
1、Elasticsearch的节点类型
在Elasticsearch主要分成两类节点，一类是Master，一类是DataNode。
1.1 Master节点
在Elasticsearch启动时，会选举出来一个Master节点。当某个节点启动后，然后使用Zen Discovery机制找到集群中的其他节点，建立连接，并从候选主节点中选举出一个主节点。 Master节点主要负责：
处理创建，删除索引等请求，负责索引的创建与删除决定分片被分配到哪个节点维护并且更新Cluster State
Master Node的最佳实践
Master节点非常重要，在部署上需要考虑解决单点的问题为一个集群设置多个Master节点，每个节点只承担Master 的单一角色
选主的过程
互相Ping对方，Node ld 低的会成为被选举的节点其他节点会加入集群，但是不承担Master节点的角色。一旦发现被选中的主节点丢失，就会选举出新的Master节点
1.2 DataNode节点
在Elasticsearch集群中，会有N个DataNode节点。DataNode节点主要负责：数据写入、数据检索，大部分Elasticsearch的压力都在DataNode节点上在生产环境中，内存最好配置大一些。 可以保存数据的节点，叫做Data Node，负责保存分片数据。在数据扩展上起到了至关重要的作用。 节点启动后，默认就是数据节点，可以设置node.data: false 禁止。 由Master Node决定如何把分片分发到数据节点上，通过增加数据节点可以解决数据水平扩展和解决数据单点问题。
1.3 Coordinating Node
负责接受Client的请求， 将请求分发到合适的节点，最终把结果汇集到一起。每个节点默认都起到了Coordinating Node的职责。
1.4 其他节点
Master eligible nodes：可以参与选举的合格节点 Master eligible nodes和Master Node 每个节点启动后，默认就是一个Master eligible节点 ○ 可以设置 node.master: false禁止Master-eligible节点可以参加选主流程，成为Master节点 当第一个节点启动时候，它会将自己选举成Master节点 每个节点上都保存了集群的状态，只有Master节点才能修改集群的状态信息 ○ 集群状态(Cluster State) ，维护了一个集群中，必要的信息 ■ 所有的节点信息 ■ 所有的索引和其相关的Mapping与Setting信息 ■ 分片的路由信息Hot & Warm Node ○ 不同硬件配置 的Data Node,用来实现Hot & Warm架构，降低集群部署的成本Ingest Node ○ 数据前置处理转换节点，支持pipeline管道设置，可以使用ingest对数据进行过滤、转换等操作Machine Learning Node ○ 负责跑机器学习的Job，用来做异常检测Tribe Node ○ Tribe Node连接到不同的Elasticsearch集群，并且支持将这些集群当成一个单独的集群处理
二 、分片和副本机制
2.1 分片（Primary Shard & Replica Shard）
Elasticsearch是一个分布式的搜索引擎，索引的数据也是分成若干部分，分布在不同的服务器节点中。分布在不同服务器节点中的索引数据，就是分片（Shard）。Elasticsearch会自动管理分片，如果发现分片分布不均衡，就会自动迁移一个索引（index）由多个shard（分片）组成，而分片是分布在不同的服务器上的
2.1.1 主分片（Primary Shard）
用以解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内的所有节点之上一个分片是一个运行的Lucene的实例主分片数在索引创建时指定，后续不允许修改，除非Reindex
2.1.2 副本分片（Replica Shard）
用以解决数据高可用的问题。 副本分片是主分片的拷贝副本分片数，可以动态调整增加副本数，还可以在一定程度上提高服务的可用性(读取的吞吐) 分片的设定
对于生产环境中分片的设定，需要提前做好容量规划
2.1.3 分片数设置过小
导致后续无法增加节点实现水平扩展单个分片的数据量太大，导致数据重新分配耗时
2.1.4 分片数设置过大，
7.0 开始，默认主分片设置成1，解决了over-sharding（分片过度）的问题
影响搜索结果的相关性打分，影响统计结果的准确性单个节点上过多的分片，会导致资源浪费，同时也会影响性能
指定索引的主分片和副本分片数
PUT /blogs
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1 // 0或1
}
}
#查看集群的健康状况 GET _cluster/health
2.2 副本
为了对Elasticsearch的分片进行容错，假设某个节点不可用，会导致整个索引库都将不可用。所以，需要对分片进行副本容错。每一个分片都会有对应的副本。在Elasticsearch中，默认创建的索引为1个分片、每个分片有1个主分片和1个副本分片。每个分片都会有一个Primary Shard（主分片），也会有若干个Replica Shard（副本分片） Primary Shard和Replica Shard不在同一个节点上
2.3 指定分片、副本数量
// 创建指定分片数量、副本数量的索引
2.4 集群status
● Green: 主分片与副本都正常分配 ● Yellow: 主分片全部正常分配，有副本分片未能正常分配 ● Red: 有主分片未能分配。例如，当服务器的磁盘容量超过85%时,去创建了一个新的索引 CAT API查看集群信息：
GET /_cat/nodes?v #查看节点信息
GET /_cat/health?v #查看集群当前状态：红、黄、绿
GET /_cat/shards?v #查看各shard的详细情况
GET /_cat/shards/{index}?v #查看指定分片的详细情况
GET /_cat/master?v #查看master节点信息
GET /_cat/indices?v #查看集群中所有index的详细信息
GET /_cat/indices/{index}?v #查看集群中指定index的详细信息
三、Elasticsearch重要工作流程
3.1 Elasticsearch文档写入原理
1.选择任意一个DataNode发送请求，例如：node2。此时，node2就成为一个coordinating node（协调节点） 2.计算得到文档要写入的分片 shard = hash(routing) % number_of_primary_shards routing 是一个可变值，默认是文档的 _id 3.coordinating node会进行路由，将请求转发给对应的primary shard所在的DataNode（假设primary shard在node1、replica shard在node2） 4.node1节点上的Primary Shard处理请求，写入数据到索引库中，并将数据同步到Replica shard 5.Primary Shard和Replica Shard都保存好了文档，返回client.
注意：es路由分片规则是 shard = hash(routing) % number_of_primary_shards，其中number_of_primary_shards为分片数。
3.2 Elasticsearch检索原理
client发起查询请求，某个DataNode接收到请求，该DataNode就会成为协调节点（Coordinating Node） 2.协调节点（Coordinating Node）将查询请求广播到每一个数据节点，这些数据节点的分片会处理该查询请求 3.每个分片进行数据查询，将符合条件的数据放在一个优先队列中，并将这些数据的文档ID、节点信息、分片信息返回给协调节点 协调节点将所有的结果进行汇总，并进行全局排序 4.协调节点向包含这些文档ID的分片发送get请求，对应的分片将文档数据返回给协调节点，最后协调节点将数据返回给客户端
如何对集群的容量进行规划
一个集群总共需要多少个节点?一个索引需要设置几个分片？规划上需要保持一定的余量，当负载出现波动，节点出现丢失时，还能正常运行。 做容量规划时，一些需要考虑的因素： ● 机器的软硬件配置 ● 单条文档的大小│文档的总数据量│索引的总数据量（(Time base数据保留的时间)|副本分片数 ● 文档是如何写入的(Bulk的大小) ● 文档的复杂度，文档是如何进行读取的(怎么样的查询和聚合)
评估业务的性能需求： ● 数据吞吐及性能需求 ○ 数据写入的吞吐量，每秒要求写入多少数据? ○ 查询的吞吐量? ○ 单条查询可接受的最大返回时间? ● 了解你的数据 ○ 数据的格式和数据的Mapping ○ 实际的查询和聚合长的是什么样的
ES集群常见应用场景： ● 搜索: 固定大小的数据集 ○ 搜索的数据集增长相对比较缓慢 ● 日志: 基于时间序列的数据 ○ 使用ES存放日志与性能指标。数据每天不断写入，增长速度较快 ○ 结合Warm Node 做数据的老化处理
硬件配置： ● 选择合理的硬件，数据节点尽可能使用SSD ● 搜索等性能要求高的场景，建议SSD ○ 按照1∶10的比例配置内存和硬盘 ● 日志类和查询并发低的场景，可以考虑使用机械硬盘存储 ○ 按照1:50的比例配置内存和硬盘 ● 单节点数据建议控制在2TB以内，最大不建议超过5TB ● JVM配置机器内存的一半，JVM内存配置不建议超过32G ● 不建议在一台服务器上运行多个节点
内存大小要根据Node 需要存储的数据来进行估算 ● 搜索类的比例建议: 1:16 ● 日志类: 1:48——1:96之间 假设总数据量1T，设置一个副本就是2T总数据量 ● 如果搜索类的项目，每个节点3116 = 496 G，加上预留空间。所以每个节点最多400G数据，至少需要5个数据节点 ● 如果是日志类项目，每个节点3150= 1550 GB，2个数据节点即可
好文推荐
您阅读本篇文章共花了：
发表评论