es集群red状态 es 集群

前面几篇分别对es整体做了介绍、同时解释了一些基本概念，以及一些常用插件的安装。本篇就终点讲解下我对es集群的研究。

高可用方案的依据

• es的节点角色划分

节点类型	参数配置
主节点	node.master: ture(默认)
数据节点	node.data: ture(默认)
协调节点	node.master: false node.data: false
摄入节点	node.ingest: true(默认)

• es的数据处理特点：1️⃣对于写请求协调节点根据负载均衡，转发给主分片节点，主分片同步复制给从节点，主从节点都写入完成返回客户端请求成功。2️⃣对于读请求，协调负载到任意节点数据节点，数据节点把各自符合要求的数据汇反馈给协调节点，协调节点做最后的数据整合，最终反馈给客户端。

• 查询效率的提高尽量让数据从内存执行读取。你往 es 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。

总结：

•  集群的设计都是基于以上特性。引入不用的节点角色，产生不同的集群
• 从数据节点处理数据的流程看，es天生具有读写分离的特性。这么说的原因是写都是从主节点开始，读从任意节点。这一点同学们要理解一下，不是严格的读写分离（写主，读从）。
• es 的搜索引擎严重依赖于底层的 filesystem cache ，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。

根据以上特性，我们来看看进群的演进过程

• 首先人们想到的要排除单点故障，而es从出生就支持集群，所以大家首先想到的解决方案就是搭建一个三个节点的集群。

 

总结：

•  三个节点没有做角色的划分，既是主节点又是数据节点。
• 优点：搭建简单，开箱即用
• 缺点：也很明显，三台机器的极限很容易随着业务量的增长很容易触达。

•  集群中的node赋予不同的角色，一般情况会把数据和主节点分开。

总结：

•  该集群方案，数据节点和主节点做了分离，整体性能大幅提升。
• 优点：主节点和候选主节点构成主节点集群（暂且这么叫），是集群管理与数据操作完全隔离；数据节点和主节点可以选取不同的机器配置；单点故障进一步降低；
• 缺点：数据节点上承受压力过大，既要承受写，又要承受读，随着业务增长容易突破性能上线。

•  为了解决数据节点读写压力，集群引入协调节点，集群变成如下形式

总结：

•  该集群方案，增加了协调节点，隐藏了主节点和数据节点，对于开发者来讲只暴露协调节点。
• 优点：通过水平伸缩协调节点，极大的提高了集群的吞吐量；同时解放了数据节点，让其更专注数据本身
• 缺点：所有数据集中到一起，不经常访问的数据严重影响热数据的操作效率。

• 由此引入了冷热集群的划分，形式如下 ：

总结：

•  该集群方案，增加了冷热分区，让热的数据更热，查询效率更高。
• 冷热分离，可以根据不同区域的数据单独做策略，比如热区配置SSD、冷区HDD等

•  集群还可以进一步扩展和复杂。比如：跨不同的set、添加摄入节点（对导入的数据做预处理）、驾驶LB负载均衡、协调节点进一步划分读写角色（一部分负责读，一部分负责写）、严格控制主从分片的分布等等这里就不在列举。
• 如果业务量么有那么大，完全可以没必要搞的这么复杂，从解决成本的角度考虑，可以根据业务量的增长，逐渐调整集群的方式和规模。
• 划重点，暴露给开发者的节点是协调节点（或者是反向代理节点），主节点和数据节点不暴露。
•