时隔3年重新开源，这些 ElasticSearch 应用技能运维必会？

一、ES 的基本使用

安装使用

下载和解压Elasticsearch，解压后即可用:

安装目录下运行 bin/elasticsearch 来启动 ES。
默认在 9200 端口运行，请求 curl http://localhost:9200/ 或者浏览器输入 http://localhost:9200，得到一个 JSON 对象，其中包含当前节点、集群、版本等信息。

{"name" : "U7fp3O9","cluster_name" : "elasticsearch","cluster_uuid" : "-Rj8jGQvRIelGd9ckicUOA","version" : {"number" : "6.8.1","build_flavor" : "default","build_type" : "zip","build_hash" : "1fad4e1","build_date" : "2019-06-18T13:16:52.517138Z","build_snapshot" : false,"lucene_version" : "7.7.0","minimum_wire_compatibility_version" : "5.6.0","minimum_index_compatibility_version" : "5.0.0"},"tagline" : "You Know, for Search"}

集群健康状态

{"cluster_name" : "lzj","status" : "yellow","timed_out" : false,"number_of_nodes" : 1,"number_of_data_nodes" : 1,"active_primary_shards" : 9,"active_shards" : 9,"relocating_shards" : 0,"initializing_shards" : 0,"unassigned_shards" : 5,"delayed_unassigned_shards" : 0,"number_of_pending_tasks" : 0,"number_of_in_flight_fetch" : 0,"task_max_waiting_in_queue_millis" : 0,"active_shards_percent_as_number" : 64.28571428571429}

集群状态通过 绿，黄，红 来标识：

• 绿色：集群健康完好，一切功能齐全正常，所有分片和副本都可以正常工作。
• 黄色：预警状态，所有主分片功能正常，但至少有一个副本是不能正常工作的。此时集群是可以正常工作的，但是高可用性在某种程度上会受影响。
• 红色：集群不可正常使用。某个或某些分片及其副本异常不可用，这时集群的查询操作还能执行，但是返回的结果会不准确。对于分配到这个分片的写入请求将会报错，最终会导致数据的丢失。当集群状态为红色时，它将会继续从可用的分片提供搜索请求服务，但是你需要尽快修复那些未分配的分片。

二、ES 机制原理

ES的基本概念和基本操作介绍完了之后，我们可能还有很多疑惑

• 它们内部是如何运行的？

• 主分片和副本分片是如何同步的？

• 创建索引的流程是什么样的？

• ES如何将索引数据分配到不同的分片上的？

  以及索引数据是如何存储的？

• 为什么说ES是近实时搜索引擎而文档的CRUD(创建-读取-更新-删除) 操作是实时的？

• 以及ES是怎样保证更新被持久化在断电时也不丢失数据？

• 为什么删除文档不会立刻释放空间？

带着这些疑问我们进入接下来的内容。

写索引原理

下图描述了3个节点的集群，共拥有12个分片，其中有4个主分片（S0、S1、S2、S3和8个副本分片（R0、R1、R2、R3），每个主分片对应两个副本分片，节点1是主节点（Master节点）负责整个集群的状态。

写索引是只能写在主分片上，然后同步到副本分片。这里有四个主分片，一条数据 ES 是根据什么规则写到特定分片上的呢？

首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。

实际上，这个过程和之前写的Hash分片的路由方法，实际根据下面这个公式决定的：

shard = hash(routing) % number_of_primary_shards

Routing是一个可变值，默认是文档的_id，也可以设置成一个自定义的值。Routing通过Hash函数生成一个数字，然后这个数字再除以number_of_primary_shards（主分片的数量）后得到余数。

这个在0到number_of_primary_shards-1之间的余数，就是我们所寻求的文档所在分片的位置。

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

由于在 ES 集群中每个节点通过上面的计算公式都知道集群中的文档的存放位置，所以每个节点都有处理读写请求的能力。

在一个写请求被发送到某个节点后，该节点即为前面说过的协调节点，协调节点会根据路由公式计算出需要写到哪个分片上，再将请求转发到该分片的主分片节点上。

1. 客户端向 ES1 节点（协调节点）发送写请求，通过路由计算公式得到值为 0，则当前数据应被写到主分片 S0 上。
2. ES1 节点将请求转发到 S0 主分片所在的节点 ES3，ES3 接受请求并写入到磁盘。
3. 并发将数据复制到两个副本分片 R0 上，其中通过乐观并发控制数据的冲突。
   一旦所有的副本分片都报告成功，则节点 ES3 将向协调节点报告成功，协调节点向客户端报告成功。

存储原理

path.data: /path/to/data//索引数据path.logs: /path/to/logs//日志记录

分段存储

索引文档以段的形式存储在磁盘上，何为段？索引文件被拆分为多个子文件，则每个子文件叫作段，每一个段本身都是一个倒排索引，并且段具有不变性，一旦索引的数据被写入硬盘，就不可再修改。

在底层采用了分段的存储模式，使它在读写时几乎完全避免了锁的出现，大大提升了读写性能。

段被写入到磁盘后会生成一个提交点，提交点是一个用来记录所有提交后段信息的文件。

一个段一旦拥有了提交点，就说明这个段只有读的权限，失去了写的权限。相反，当段在内存中时，就只有写的权限，而不具备读数据的权限，意味着不能被检索。

如果索引有更新，就需要重新全量创建一个索引来替换原来的索引。这种方式在数据量很大时效率很低，并且由于创建一次索引的成本很高，所以对数据的更新不能过于频繁，也就不能保证时效性。

索引文件分段存储并且不可修改，那么新增、更新和删除如何处理呢？

• 新增

很好处理，由于数据是新的，所以只需要对当前文档新增一个段就可以。

• 删除

由于不可修改，所以对于删除操作，不会把文档从旧的段中移除而是通过新增一个 .del 文件，文件中会列出这些被删除文档的段信息。这个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。

• 更新

不能修改旧的段来进行反映文档的更新，其实更新相当于是删除和新增这两个动作组成。会将旧的文档在.del文件中标记删除，然后文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就会被移除。

段被设定为不可修改具有一定的优势也有一定的缺点，优势主要表现在：不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。

一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。

其它缓存(像Filter缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。

写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和需要被缓存到内存的索引的使用量。

段的不变性的缺点如下：

• 当对旧数据进行删除时，旧数据不会马上被删除，而是在.del文件中被标记为删除。
  而旧数据只能等到段更新时才能被移除，这样会造成大量的空间浪费。
• 若有一条数据频繁的更新，每次更新都是新增新的标记旧的，则会有大量的空间浪费。
• 每次新增数据时都需要新增一个段来存储数据。
  当段的数量太多时，对服务器的资源例如文件句柄的消耗会非常大。
• 在查询的结果中包含所有的结果集，需要排除被标记删除的旧数据，这增加了查询的负担。

延迟写策略

介绍完了存储的形式，那么索引写入到磁盘的过程是怎样的？是否是直接调 Fsync物理性地写入磁盘？

答案是显而易见的，如果是直接写入到磁盘上，磁盘的 I/O 消耗上会严重影响性能。那么当写数据量大的时候会造成 ES 停顿卡死，查询也无法做到快速响应。如果真是这样 ES 也就不会称之为近实时全文搜索引擎了。

为了提升写的性能，ES并没有每新增一条数据就增加一个段到磁盘上，而是采用延迟写的策略。每当有新增的数据时，就将其先写入到内存中，在内存和磁盘之间是文件系统缓存。

当达到默认的时间（1 秒钟）或者内存的数据达到一定量时，会触发一次刷新（Refresh），将内存中的数据生成到一个新的段上并缓存到文件缓存系统上，稍后再被刷新到磁盘中并生成提交点。

这里的内存使用的是ES的JVM内存，而文件缓存系统使用的是操作系统的内存。

新的数据会继续的被写入内存，但内存中的数据并不是以段的形式存储的，因此不能提供检索功能。

由内存刷新到文件缓存系统的时候会生成新的段，并将段打开以供搜索使用，而不需要等到被刷新到磁盘。

在Elasticsearch中，写入和打开一个新段的轻量的过程叫做 Refresh（即内存刷新到文件缓存系统）。

默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说Elasticsearch 是近实时搜索，因为文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

我们也可以手动触发 Refresh：

POST/_refresh //刷新所有索引POST/nba/_refresh //刷新指定的索引

Tips：尽管刷新是比提交轻量很多的操作，它还是会有性能开销。当写测试的时候，手动刷新很有用，但是不要在生产>环境下每次索引一个文档都去手动刷新。而且并不是所有的情况都需要每秒刷新。

索引写流程

segment合并

六、ES 的性能优化

存储设备

磁盘在现代服务器上通常都是瓶颈。Elasticsearch重度使用磁盘，你的磁盘能处理的吞吐量越大，你的节点就越稳定。这里有一些优化磁盘 I/O 的技巧：

• 使用SSD。就像其他地方提过的，他们比机械磁盘优秀多了。

• 使用RAID10/RAID5。条带化RAID会提高磁盘I/O，同时增加数据可靠性

• 使用多块硬盘，并允许Elasticsearch通过多个 path.data目录配置把数据条带化分配到它们上面。

• 不要使用远程挂载的存储，比如NFS或者SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰的。

• 如果你用的是 EC2，当心EBS。即便是基于SSD的EBS，通常也比本地实例的存储要慢。

内部索引优化

索引优化

调整配置参数

调整配置参数建议如下：

• 给每个文档指定有序的具有压缩良好的序列模式ID，避免随机的UUID-4 这样的ID，这样的ID压缩比很低，会明显拖慢Lucene。

• 对于那些不需要聚合和排序的索引字段禁用Doc values。

  Doc Values 是有序的、基于document=>field value的映射列表。

• 不需要做模糊检索的字段使用Keyword类型代替Text类型，这样可以避免在建立索引前对这些文本进行分词。

• 如果你的搜索结果不需要近实时的准确度，考虑把每个索引的index.refresh_interval改到30s。

• 如果你是在做大批量导入，导入期间你可以通过设置这个值为-1 关掉刷新，还可以通过设置 index.number_of_replicas: 0 关闭副本。别忘记在完工的时候重新开启它。

• 避免深度分页查询建议使用Scroll进行分页查询。普通分页查询时，会创建一个from+size的空优先队列，每个分片会返回from+size条数据，默认只包含文档ID和得分Score给协调节点。

• 如果有N个分片，则协调节点再对（from+size）×n条数据进行二次排序，然后选择需要被取回的文档。当from很大时，排序过程会变得很沉重，占用CPU资源严重。减少映射字段，只提供需要检索，聚合或排序的字段。其他字段可存在其他存储设备上，例如HBase，在ES中得到结果后再去HBase 查询这些字段。

• 创建索引和查询时指定路由Routing值，这样可以精确到具体的分片查询，提升查询效率。路由的选择需要注意数据的分布均衡。

JVM 调优