73 lines
3.6 KiB
Markdown
73 lines
3.6 KiB
Markdown
# ES简介
|
||
|
||
Elasticsearch 是一个非常强大的搜索引擎。它目前被广泛地使用于各个IT公司。Elasticsearch 是由 Elastic 公司创建并开源维护的。[代码库](https://github.com/elastic/elasticsearch)<br>
|
||
|
||
同时，Elastic 公司也拥有 Logstash 及 Kibana 开源项目。这个三个开源项目组合在一起，就形成了 ELK 软件栈。
|
||
|
||
他们三个共同形成了一个强大的生态圈。简单地说，Logstash 负责数据的采集，处理（丰富数据，数据转型等），Kibana 负责数据展，分析及管理。
|
||
|
||
Elasticsearch 处于最核心的位置，它可以帮我们对数据进行快速地搜索及分析。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
# ES集群
|
||
|
||
|
||
Elasticsearch 的节点的分类如下：
|
||
|
||
1. 主节点（Master Node）：也叫作主节点，主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch 中的主节点的工作量相对较轻。
|
||
|
||
用户的请求可以发往任何一个节点，并由该节点负责分发请求、收集结果等操作，而并不需要经过主节点转发。
|
||
|
||
通过在配置文件中设置 node.master=true 来设置该节点成为候选主节点（但该节点不一定是主节点，主节点是集群在候选节点中选举出来的），在 Elasticsearch 集群中只有候选节点才有选举权和被选举权。其他节点是不参与选举工作的。
|
||
|
||
2. 数据节点（Data Node）：数据节点，负责数据的存储和相关具体操作，比如索引数据的创建、修改、删除、搜索、聚合。
|
||
|
||
所以，数据节点对机器配置要求比较高，首先需要有足够的磁盘空间来存储数据，其次数据操作对系统 CPU、Memory 和 I/O 的性能消耗都很大。
|
||
|
||
通常随着集群的扩大，需要增加更多的数据节点来提高可用性。通过在配置文件中设置 node.data=true 来设置该节点成为数据节点。
|
||
|
||
3. 客户端节点（Client Node）：就是既不做候选主节点也不做数据节点的节点，只负责请求的分发、汇总等，也就是下面要说到的协调节点的角色。
|
||
|
||
其实任何一个节点都可以完成这样的工作，单独增加这样的节点更多地是为了提高并发性。
|
||
|
||
```shell
|
||
node.master=falsenode.data=false
|
||
```
|
||
|
||
4. 协调节点（Coordinating Node）：协调节点，是一种角色，而不是真实的 Elasticsearch 的节点，我们没有办法通过配置项来配置哪个节点为协调节点。集群中的任何节点都可以充当协调节点的角色。
|
||
|
||
|
||
当一个节点 A 收到用户的查询请求后，会把查询语句分发到其他的节点，然后合并各个节点返回的查询结果，最好返回一个完整的数据集给用户。
|
||
|
||
在这个过程中，节点 A 扮演的就是协调节点的角色。由此可见，协调节点会对 CPU、Memory 和 I/O 要求比较高。
|
||
|
||
|
||
|
||
## 集群健康
|
||
|
||
集群的状态有 Green、Yellow 和 Red 三种，如下所述：
|
||
|
||
Green：绿色，健康。所有的主分片和副本分片都可正常工作，集群 100% 健康。
|
||
|
||
Yellow：黄色，预警。所有的主分片都可以正常工作，但至少有一个副本分片是不能正常工作的。此时集群可以正常工作，但是集群的高可用性在某种程度上被弱化。
|
||
|
||
Red：红色，集群不可正常使用。集群中至少有一个分片的主分片及它的全部副本分片都不可正常工作。
|
||
|
||
这时虽然集群的查询操作还可以进行，但是也只能返回部分数据（其他正常分片的数据可以返回），而分配到这个分片上的写入请求将会报错，最终会导致数据的丢失。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|