首页  思维导图  详情

ES源码解析与优化实践

2021-12-05 21:39:34   0  举报





AI智能生成

为你推荐

查看更多



spring整套源码系列之【SQLSessionFactory与集成事务源码分析】

spring整套源码系列之【springboot自动装配源码分析】

es 写入、删除数据

需求管理【方法与实践】

spring整套源码系列之【spring声明式事务源码】

ES源码解析与优化实战，版本基于6.X。

作者其他创作

大纲/内容

有时候，业务上对数据可靠性和搜索实时性要求并不高，反而对写入速度要求很高，此时可以调整一些策略，最大化写入速度。

提升写入速度可以从以下几方面入手：

1. 加大 translog flush 间隔，目的是降低iops、writelock。

2. 加大 index refresh 间隔，除了降低I/O，更重要的是降低了 segment merge 频率。

3. 调整 bulk 请求。

4. 优化磁盘间的任务均匀情况，将 shard 尽量均匀分布到物理主机的各个磁盘。

5. 优化节点间的任务分布，将任务尽量均匀地发送到各节点。

6. 优化 Lucene 层建立索引的过程，目的是降低CPU占用率及I/O，例如：禁用_all字段。

ES的默认设置是综合考虑数据可靠性、搜索实时性、写入速度等因素的。

ES默认设置，translog的持久化策略为：每个请求都“flush”。对应配置项如下：index.translog.durability：request。这是影响ES写入写入的最大因素。但是只有这样，写操作才有可能是可靠的。

如果系统可以接受一定概率的数据丢失，则调整 translog 持久化策略为周期性和一定大小的时候“flush”。例如：index.translog.durability：async，设置为async表示translog的刷盘策略按sync_interval配置指定的时间周期进行。index.translog.sync_interval：120s。加大translog刷盘间隔时间。默认为 5s，不可低于100ms。

index.translog.flush_threshold_size：1024mb。超过这个大小会导致refresh操作，产生新的Lucene分段，默认值为512MB。

1. translog flush 间隔调整

默认情况下索引的 refresh_interval 为1s，这意味着数据写1s后就可以被搜索到，每次索引的refresh会产生一个新的Lucene段，这会导致频繁的 segment merge 行为，如果不需要这么高的搜索实时性，应该降低索引 refresh 周期，例如：index.refresh_interval：120s

2. 索引刷新间隔 refresh_interval

merge 策略 index.merge.policy 有三种：tiered（默认策略）；log_byete_size；log_doc

索引创建合并策略就已确定，不能更改，但是可以动态更新策略参数，可以不做此项调整。如果堆栈经常有很多 merge，则可以调整以下策略配置：index.merge.policy.segments_per_tier。该属性指定了每层分段的数量，取值越小则最终segment越少，因此需要 merge 的操作更多，可以考虑适当增加此值。默认为10，其应该大于等于 index.merge.policy.max_merge_at_once。

index.merge.policy.max_merged_segment，指定了单个 segment 的最大容量，默认为 5GB，可以考虑适当降低此值。

3. 段合并优化

indexing buffer在为doc建立索引时使用，当缓冲满时会刷入磁盘，生成一个新的segment，这是除 refresh_interval 刷新索引外，另一个生成新segment的机会。每个shard有自己的indexing buffer。

indices.memory.index_buffer_size：这个buffer大小的配置需要除以这个节点上所有shard的数量。默认为堆空间的10%

indices.memory.min_index_buffer_size：默认为48MB

indices.memory.max_index_buffer_size：默认无限制。

在执行大量的索引操作时，indices.memory.index_buffer_size的默认值可能不够，这和可用堆内存、单节点上的shard数量相关，可以考虑适当增大该值。

4. Indexing buffer

批量写比一个索引请求只写单个文档的效率要高得多，但是要注意bulk请求的整体字节数不要太大，太大的请求可能会给集群带来内存压力，因此每个请求最好避免超过几十兆字节，即使较大的请求看上去执行得更好。

1. bulk线程池和队列

建立索引的过程属于计算密集型任务，应该使用固定大小的线程池配置，来不及处理的任务放入队列。线程池最大线程数量应配置为CPU核心数+1，可以避免过多的上下文切换。队列大小可以适当增加，但一定要严格控制大小，过大的队列导致较高的GC压力，并可能导致FGC频繁发生。

2. 并发执行bulk请求

bulk是个长任务，为了给系统增加足够的写入压力，写入过程应该多个客户端、多线程并行执行，如果要验证系统的极限写入能力，那么目标就是把CPU压满。如果CPU没有压满，则应该提高写入端的并发数量。但是要注意bulk线程池队列的reject情况，出现reject代表ES的bulk队列已满，客户端请求被拒绝，此时客户端会收到429错误，客户端对此的处理策略应该是延迟重试，应该避免产生reject。

5. 使用bulk请求

如果部署方案是为 path.data 配置多个路径来使用多块磁盘，则ES在分配shard时，落到各磁盘上的shard可能并不均匀，这种不均匀可能会导致某些磁盘繁忙，利用零在较长时间内持续达到100%。这种不均匀达到一定程度会对写入性能产生负面影响。

ES在处理多路径时，优先将shard分配到可用空间百分比最多的磁盘上，因此短时间内创建的shard可能被集中分配到这个磁盘上。

从可用空间减去预估大小：这种机制只存在于一次索引创建的过程中，下一次的索引创建，磁盘可用空间并不是上次做完减法以后的结果。

ES增加了两种策略：1.简单轮询：在系统初始阶段，简单轮询的效果是最均匀的。2.基于可用空间的动态加权轮询：以可用空间作为权重，在磁盘之间加权轮询。

6. 磁盘间的任务均衡

1. 为了节点间的任务尽量均衡，数据写入客户端应该把bulk请求轮询发送到各个节点。

2. 当使用Java API或REST API的bulk接口发送数据时，客户端将会轮询发送到集群节点。

3. 观察bulk请求在不同节点间的均衡性，可以通过cat接口观察bulk线程池和队列情况，_cat/thread_pool

7. 节点间的任务均衡

1. 自动生成doc ID：写入doc时如果外部指定了id，则ES会先尝试读取原来doc的版本号，来判断是否需要更新。这会涉及一次读取磁盘操作，通过自动生成doc ID可以避免这个环节。

2. 调整字段Mappings：（1）减少字段的数量，对于不需要建立索引的字段，不写入ES。（2）将不需要建立索引的字段index属性设置为not_analyzed或no。对字段不分词，或者不索引，可以减少很多运算操作，降低CPU占用。尤其是binary类型，默认情况下占用CPU非常高，而这种类型进行分词通常没有什么意义。（3）减少字段内容长度。如果原始数据的大段内容无需全部建立索引时，则可以尽量减少不必要的内容。（4）使用不同的分析器。不同的分析器在索引过程中运算复杂度，也有较大的差异。

3. 调整_source字段：_source字段用于存储doc原始数据，对于部分不需要存储的字段，可以通过includes/excludes过滤，或者将_source禁用，一般用于索引和数据分离。这样可以降低I/O压力，不过实际场景中大多不会禁用_source，而即使过滤掉某些字段，对于写入速度的提升作用也不大。

4. 禁用_all字段：默认不启用。_all字段中包含所有字段分词后的关键词，作用是可以在搜索的时候不指定特定字段，从所有字段中检索。_all字段占用非常大的空间，_all字段有自己的分析器，在进行某些查询时，结果不符合预期，因为没有匹配同一个分析器；由于数据重复引起的额外建立索引的开销；有些用户甚至不知道存在这个字段，导致查询混乱。禁用_all字段可以明显降低对CPU和I/O的压力。

5. 对Analyzed的字段禁用Norms。Norms用于在搜索时计算doc的评分，如果不需要评分，则可以将其禁用。

6. index_options设置。用于控制在建立倒排索引过程中，哪些内容会被添加到倒排索引，例如：doc数量、词频、positioins、offsets等信息，优化这些设置可以一定程度降低索引过程中的运算任务，节省CPU占用率。

8. 索引过程调整和优化

写入速度优化

一般情况下，应用程序的读写都会被操作系统“cache”，cache保存在系统物理内存中，命中cache可以降低对磁盘的直接访问频率。搜索很依赖对系统cache的命中，如果某个请求需要从磁盘读取数据，则一定会产生相对较高的延迟。应该至少为系统cache预留一半的可用物理内存，更大的内存有更高的cache命中率。

1. 为文件系统cache预留足够的内存。

写入性能对CPU的性能更敏感，而搜索性能在一半情况下更多的是在于I/O能力，使用SSD会比旋转类存储介质好得多。尽量避免使用NFS等远程文件系统，如果NFS比本地存储慢3倍，则搜索响应速度可能慢10倍。可能是因为搜索请求有更多的随机访问。

2.使用更快的硬件。

为了让搜索时的成本更低，文档应该合理建模。特别是应该避免join操作，嵌套会使查询慢几倍，父子关系可能使查询慢数百倍，因此，如果可以通过非规范化文档来回答相同的问题，则可以显著地提高搜索速度。

3.文档模型

针对某些查询的模式来优化数据的索引方式。例如：如果所有文档都有一个price字段，并且大多数查询在一个固定的范围上运行RANGE聚合，那么可以通过将范围“pre-indexing”到索引中并使用terms聚合来加快聚合速度。

4.预索引数据

有些字段的内容是数值，但并不意味着其总是应该被映射为数值类型，例如，一些标识符，将它们映射为keyword可能会比integer或long更好，

5.字段映射

一般来说，应该避免使用脚本。如果一定要用，则应该考虑painless和expressions。

6.避免使用脚本

在使用日期范围检索时，使用now的查询通常不能缓存，因为匹配到的范围一直在变化。但是切换到一个完整的日期通常是可以接受的，这样可以更好地利用查询缓存。

7.优化日期搜索

为不再更新的只读索引执行force merge，将Lucene索引合并为单个分段，可以提升查询速度。当一个Lucene索引存在多个分段时，每个分段会单独执行搜索再将结果合并，将只读索引强制合并为一个Lucene分段不仅可以优化搜索过程，对索引恢复速度也有好处。

基于日期进行轮询的索引的旧数据一般都不会再更新。应该按照一定的策略，例如：每天生成一个新的索引，然后用别名关联，或者用索引通配符。这样，可以每天选一个时间点对昨天的索引执行force-merge、shrink等操作。

8.为只读索引执行force-merge

全局序号是一种数据结构，用于在keyword字段上运行terms聚合。它用一个数值来代表字段中的字符串值，然后为每一数值分配一个bucket。这需要一个对global ordinals和bucket的构建过程。默认情况下，它们被延迟构建，因为ES不知道哪些字段将用于terms聚合，哪些字段不会。可以通过配置映射在刷新（refresh）时告诉ES预先加载全局序数。

9.预热全局序号（global ordinals）

terms聚合有两种不同的机制：1.通过直接使用字段值来聚合每个桶的数据（map）。2.通过使用字段的全局序号并为每个全局序号分配一个bucket（global_ordinals）。

ES使用global_ordinals作为keywords字段的默认选项，它使用全局序号动态地分配bucket，因此内存使用与聚合结果中的字段数量是线性关系。在大部分的情况下，这种方式的速度很快。

当查询只会匹配少量文档时，可以考虑使用map。默认情况下，map只在脚本上运行聚合时使用，因为它们没有序数。

10.execution hint

如果ES主机重启，则文件系统缓存将为空，此时搜索会比较满。可以使用 index.store.preload 设置，通过指定文件扩展名，显示地告诉操作系统应该将哪些文件加载到内存中。

如果文件系统缓存不够大，则无法保存所有数据，那么为太多文件预加载数据到文件系统缓存中会使搜索速度变慢，应谨慎使用。

11.预热文件系统cache

在组合查询中可以通过 bool 过滤器进行 and、or 和 not 的多个逻辑组合检索，这种组合查询中的表达式在下面的情况下可以做等价转换：（A|B）&（C|D）==》（A&C）|（A&D）|（B&C）|（B&D）

12.转换查询表达式

该字段是搜索请求中的一个参数。默认情况下，聚合操作在协调节点需要等所有的分片都取回后才执行，使用batched_reduce_size参数可以不等待全部分片返回结果，而是在指定数量的分片返回结果之后就可以先处理一部分（reduce）。这样可以避免协调节点在等待全部结果的过程中占用大量内存，避免极端情况下可能导致的OOM。

13.调节搜索请求中的batched_reduce_size

近似聚合以牺牲少量的精确度为代价，大幅度提高了执行效率，降低了内存使用。

14.使用近似聚合

ES有两种不同的聚合方式：深度优先和广度优先。深度优先是默认设置，先构建完整的树，然后修剪无用节点。大多数情况下深度聚合都能正常工作，但是有些特殊的场景更适合广度优先，先执行第一层聚合，再继续下一层聚合之前会先做修剪。

15.深度优先还是广度优先

一个搜索请求设计的分片数量越多，协调节点的CPU和内存压力就越大。默认情况下，ES会拒绝超过1000个分片的搜索请求。如果想调节这个值，通过action.search.shard_count配置项进行修改。

虽然限制搜索的分片数不能直接提升单个搜索请求的速度，但协调节点的压力会间接影响搜索速度。例如：占用更多内存会产生更多的 GC 压力，可能导致更多的 stop-the-world 时间等，因此间接影响了协调节点的性能。

16.限制搜索请求的分片数

为了充分利用计算资源和负载均衡，协调节点将搜索请求轮询转发到分片的每个副本，轮询策略是负载均衡过程中最简单的策略，任何一个负载均衡器都具备这种基础的策略，缺点是不考虑后端实际系统压力和健康水平。

ES的ARS实现基于这样一个公式：对每个搜索请求，将分片的每个副本进行排序，以确定哪个最可能是转发请求的“最佳”副本。与轮询方式向分片的每个副本发送请求不同，ES选择“最佳”副本并将请求路由到那里。

ES6.1 默认关闭。ES7.0，默认开启。cluster.routing.use_adaptive_replica_selection:true

17.利用自适应副本选择（ARS）提升ES响应速度

搜索速度优化

优化磁盘使用量与建立索引时的映射参数和索引元数据字段密切相关。

每个文档都有与其相关的元数据，比如_id。当创建映射类型时，可以定制其中一些元数据字段。1. _source：原始JSON文档数据。2. _all：索引所有其他字段值的一种通用字段，这个字段中包含了所有其他字段的值。允许在搜索的时候不指定特定的字段名，意味着“从全部字段中搜索”。

_all字段是一个全文字段，有自己的分析器。ES6.0之后该字段被禁用。

1.元数据字段

索引创建时可以设置很多映射参数。1.index：控制字段值是否被索引。未被索引的字段不会被查询到，但是可以聚合。

2.doc values：默认情况下，大多数字段都被索引，这使得它们可以搜索。倒排索引根据term找到文档列表，然后获取文档原始内容。但是排序和聚合，以及从脚本中访问某个字段值，需要不同的数据访问模式，它们不仅需要根据term找到文档，还要获取文档中字段的值。这些值需要单独存储。

doc_values就是用来存储这些字段值的。它是一种存储在磁盘上的列式存储，在文档索引时创建，这使得上述数据访问模式成为可能。它们以面向列的方式存储与_source相同的值，使得排序和聚合效率更高。几乎所有字段类型都支持doc_values，但被分析的字符串除外。doc_values默认启用。

3. store：默认情况下，字段值会被索引使他们能搜索，但它们不会被存储（stored）。意味着可以通过这个字段查询，但不能取回它的原始值。

在某些情况下，存储字段是有意义的。例如：如果有一个包含标题、日期和非常多的内容字段的文档，则可能希望只检索标题和日期，而不需要从大型_source字段中提取这些字段。

doc_values和存储字段都属于正排内容。

stored fields被设计为优化存储，doc_values被设计为快速访问字段值。搜索可能会访问很多doc values中的字段，所以比必须能够快速访问，我们将doc_values用于聚合、排序，以及脚本中。

另一方面，存储字段仅用于返回前几个最匹配文档的字段值，默认情况下ES只将其用于这种情况，解压存储字段，将其发送给客户端。为少量文档获取存储字段还好。它不能再查询的时候使用，否则会让查询变得非常慢。

2.索引映射参数

默认情况下，ES为大多数的字段建立索引，并添加到doc_values，以便可以被搜索和聚合。但有时候不需要通过某些字段过滤，可以添加\"index\": false参数

text类型的字段会在索引中存储归一因子，以便对文档进行评分。如果只需在文本字段上进行匹配，而不关心生成的得分，则可以配置ES不讲norms写入索引。（\"norms\"：false）

text类型的字段默认情况下也在索引中存储频率和位置。频率用于计算得分，位置用于执行短语（phrase）查询。如果不需要运行短语查询：（\"index_options\": \"freqs\"）

在text类型的字段上，index_options的默认值为positions。index_options参数用于控制添加到倒排索引中的信息。

freqs文档编号和词频被索引，词频用于为搜索评分，重复出现的词条比只出现一次的词条评分更高。position文档编号、词频和位置被索引。位置被用于邻近查询和短语查询。

如果也不关心评分，则可以将ES配置为只为每个term索引匹配的文档。仍然可以在这个字段上搜索，但是短语查询会出现错误，评分将假定在每个文档中只出现一次词汇。（\"norms\

禁用对你来说不需要的特性

所有支持dov values的字段都默认启用了doc value。如果确定不需要对字段进行排序或聚合，或者从脚本访问字段值，则可以禁用doc value以节省磁盘空间。（\"doc_values\"：false）

禁用doc values

默认的动态字符串映射会把字符串类型的字段同时索引为text和keyword。通常，id字段只需作为keyword类型进行索引。要禁用默认的动态字符串映射，则可以显示地指定字段类型，在动态模板中指定将字符串映射为text或keyword。

不要使用默认的动态字符串映射

较大的分片可以更有效地存储数据。缺点：较长的索引恢复时间。

观察分片大小

_source字段存储文档的原始内容，如果不需要访问它，则可以将其禁用。

禁用_source

_source和设置为\"store\"：true的字段占用磁盘空间都比较多。默认情况下，它们都是被压缩存储的，默认的压缩算法为LZ4，可以通过使用best_compression来执行压缩比更高的算法：DEFLATE。但这会占用更多的CPU资源。

使用best_compression

较大的Lucene分段可以更有效地存储数据。使用_forcemerge API来对分段执行合并操作，通常，我们将分段合并为一个单个的分段：max_num_segments = 1

Fource Merge

Shrink API允许减少索引的分片数量，结合上面的Force Merge API，可以显著减少索引的分片和Lucene分段数量。

Shrink Index

为数值类型选择的字段类型也可能会对磁盘使用空间产生较大影响。

数值类型长度够用就好

当ES存储_source时，它同时压缩多个文档以提高整体压缩比。例如：文档共享相同的字段名，或者它们共享一些字段值，特别是在具有低基数或zipfian分布的字段上。

默认情况下，文档按照添加到索引中的顺序压缩在一起。如果启用了索引排序，那么它们将按排序顺序压缩。对具有相似结构、字段和值的文档进行排序可以提高压缩比。

使用索引排序来排列类似的文档

由于多个文档被压缩成块，如果字段总是以相同的顺序出现，那么在这些_source文档中可以找到更长的重复字符串的可能性更大。

在文档中以相同的顺序放置字段

1.禁用_source，空间占用量下降30%左右。2.禁用doc values，空间占用量下降10%左右；3.压缩算法将LZ4改为Deflate，空间占用量可以下降15%~25%。

测试数据

3.优化措施

磁盘使用量优化

在部署一个新集群时，应该根据多方面的情况评估需要多大的集群规模来支撑业务。

根据具体业务情况来评估初始集群大小。包括：数据总量，每天的增量；查询类型和搜索开发，QPS；SLA级别。

控制最大集群规模和数据总量。1. 节点总数不应该太多，最大集群规模最好控制在100个节点左右。2. 单个分片不要超过50GB，最大集群分片总数控制在几十万的级别。太多分片同样增加了主节点的管理负担，而且集群重启恢复时间会很长。

建议单个点是数据总量不超过5TB。这是为了让JVM使用率及GC时间保持在一个合理水平。一般数据样本中1TB索引的FST要占用2GB的JVM内存。5TB索引就占用10GB内存。如果节点长时间GC，会导致一个简单的请求都很慢，且主节点发布集群状态也会因为这个节点而长时间等待，因此控制GC时长很重要。

可以使用冷冻索引来节约内存占用。未来的Lucene版本中考虑将倒排索引放到堆外加载，值得期待。

1.规划集群规模

ES不建议为JVM配置超过32GB的内存。超过32GB时，Java内存指针压缩失效，比较安全的是设置为30GB。可以在JVM参数中添加”-XX：+UnlockDiagnosticVMOptions -XX：+PrintCompressedOoopsMode“来确认，如果输出信息包含”zero based Compressed Oops“字样，则代表指针压缩生效。

当物理主机内存在64GB以上，并且拥有多个数据盘，不做raid的情况下，部署ES节点有两点建议：1. 部署单个节点，JVM内存配置不超过32GB，配置全部数据盘。这种部署模式的缺点是多余的物理内存只能被cache使用，而且只要存在一个坏盘，节点重启就会无法启动。2.使用内存大小除以64GB来确定要部署的节点数，每个节点配置一部分数据盘，优点是利用率高，缺点是部署复杂。

目前ES对于磁盘管理方面有待改进，坏盘不会从系统中排除出去，导致节点无法启动，并且部分场景下可能会产生热点数据集中在少数磁盘的情况，如果这些问题很严重，也可以考虑一些raid方案。

2.单节点还是多节点部署

当由于坏盘、维护等故障需要下线一个节点时，我们需要先将节点的数据迁移，这可以通过分配过滤器实现。

当执行完下线命令后，分片开始迁移，可以通过_cat/shard API来查看该节点的分片是否迁移完毕。当节点维护完毕，重新上线之后，需要取消排除设置，以便后续的分片可以分配到node-1节点上。

3.移除节点

将主节点和数据节点分离部署最大的好处是Master切换过程可以迅速完成，有机会跳过gateway和分片重新分配的过程。

例如：有3台具备Master资格的节点独立部署，然后关闭当前活跃的主节点，新主当选后由于内存中持有最新的集群状态，因此可以跳过gateway的恢复过程，并且由于主节点没有存储数据，所以旧的Master离线不会产生未分配状态的分片。新主当选后集群状态可以迅速变为Green。

4.独立部署节点

集群层

不要为bulk和search分配过大的队列，队列并非越大越好，队列缓存的数据越多，GC压力越大，默认的队列大小基本够用了。

如果每个请求的数据量都非常小，可能需要增加队列大小。但是推荐写数据时组合较大的bulk请求。

1.控制线程池的队列大小

搜索操作很依赖于系统cache的命中，标准的建议是把50%的可用内存作为ES的堆内存，为Lucene保留剩下的50%，用作系统cache。

2. 为系统cache保留一半物理内存

节点层

个人PC上，交换分区或许有用，如果物理内存不够，则交换分区可以让系统缓存运行。但是在服务器系统上，无论物理内存多么小，哪怕只有1GB，都应该关闭交换分区。

当服务程序在交换分区上缓慢运行时，往往会产生更多不可预期的错误，因此当一个申请内存的操作如果真的遇到物理内存不足时，宁可让它直接失败。

一般在安装操作系统的时候直接关闭交换分区，或者通过swapoff命令来关闭。

1.关闭swap

OOM并非JVM的OOM，而是Linux操作系统的OOM。在Linux下，进程申请的内存并不会立刻为进程分配真实大小的内存，因为进程申请的内存不一定全部使用，内核在利用这些空闲内存时采取过度分配的策略，假如物理内存为 1GB，则两个进程都可以申请1GB的内存，这超过了系统的实际内存大小。当应用程序实际消耗完内存的时候，系统需要”杀掉“一些进程来保障系统正常运行。这就出发了 Linux OOM Killer。

如果ES与其他服务混合部署，当系统产生OOM的时候，ES有可能会无辜被”杀“。为了避免这种情况，可以在用户态调节一些进程参数来让某些进程不容易被OOM Killer”杀掉“。如果不希望被杀，设置进程的oom_score_adj。

2.配置Linux OOM Killer

在生产环境上，我们可以根据自己的场景调节内核参数，让搜索服务更有效率地运行。Linux默认的TCP选项不一定完全合适，因为它需要考虑在互联网上传输时可能出现的更大的延迟和丢包率。因此可以调节一些TCP选项，让TCP协议在局域网上更高效。调节内核参数可以通过两种方式：1.临时设置，系统重启后失效。通过sysctl -w来设置。2.永久设置，将参数写入配置文件/etc/sysctl.conf，然后执行 sysctl -p使其生效。

net.ipv.tcp_syn_retries：默认为6，参考值为2。主机作为客户端，对外发起TCP连接时，即三次握手的第一步，内核发送SYN报文的重试次数，超过这个次数后放弃连接。

net.ipv.tcp_synack_retries：默认5，参考值2。主机作为服务端，接受TCP连接时，在三次握手的第二步，向客户端发送SYN+ACK报文的重试次数，超过这个次数后放弃连接。

net.ipv.tcp_timestamps：默认1，参考值1。是否开启时间戳，开启后可以更精准地计算RTT，一些特性也依赖时间戳字段。

net.ipv.tcp_tw_reuse：默认0，建议1。是否允许将处于TIME_WAIT状态的socket用于新的TCP连接。这对于降低TIME_WAIT数据很有效。该参数只有在开启tcp_timestamps的情况下才会生效。

net.ipv.tcp_syn_recycle：默认0，参考值0。是否开启TIME_WAIT套接字的快速回收，这势必tcp_tw_reuse更激进的一种方式，它同样依赖tcp_timestamps选项。强烈建议不要开启tcp_tw_recycle。原因：1.TIME_WAIT是十分必要的状态，避免关闭中的连接与新建连接之间的数据混淆；2.tcp_tw_recycle选项在NAT环境下会导致一些二新建连接被拒绝，因为NAT下每个主机存在时差，这体现在套接字中的时间戳字段，服务端会发现某个IP上的本应递增的时间戳出现降低的情况，时间戳相对降低的报文将被丢弃。

net.core.somaxconn：默认128，参考2048。定义了系统中每一个端口上最大的监听队列的长度。当服务器监听了某个端口时，操作系统内部完成对客户端连接请求的三次握手。这些已建立的连接存储在一个队列中，等待accept调用取走。本选项就是定义这个队列的长度。该队列实际大小取决于listen调用传入的第二个参数：backlog和本选项的最小值：min（backlog，somaxconn）。ES需要建立许多连接，当集群节点数比较大，集群完全重启时可能会在瞬间建立大量连接，默认的连接队列长度可能不够用，因此适当提高此值。

net.ipv.tcp_max_syn_backlog：默认128，参考值8192。内核会为服务端的连接建立两个队列：1. 已完成三次握手，连接建立，等待accept的队列，全局长度由somaxconn定义。2. 三次握手执行到第二步，等待客户端返回ACK，这些未完成的连接单独放到一个队列中，由tcp_max_syn_backlog定义队列大小。由于可能会有较多的连接数，我们适度增加”未完成连接“的队列大小。

net.ipv.tcp_max_tw_buckets：默认4096，参考值180000。定义系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数，则TIME_WAIT套接字将立刻被清除并打印警告信息。如果系统被TIME_WAIT过多问题困扰，则可以调节tcp_max_tw_buckets、tcp_t_reuse、tcp_timestamps三个选项来缓解。TIME_WAIT状态产生在TCP会话关闭时主动关闭的一端，如果向从根本上解决问题，则让客户端主动关闭连接，而非服务端。

net.ipv.tcp_max_orphans：默认4096，参考值262144。定义最大孤儿套节字（未附加到任何用户文件句柄的套接字）数量。如果孤儿套接字超过此值，则这些连接立即”reset“，并显示警告信息。该值可以简单地抵御DOS攻击，但不能通过降低此值来抵御DOS。为了应对高负载，应该提高此值。

1.TCP相关参数

TCP采用两个基本原则决定何时发送及发送多少数据：流量控制：为了确保接收者可以接收数据。拥塞控制：为了管理网络带宽。

流量控制通过在接收方指定接收窗口大小来实现。接收窗口用于接收端告诉发送端，自己还有多大的缓冲区可以接收数据。发送端参考这个值来发送数据，就不会导致客户端处理不过来。

接收窗口的大小可以通过内核参数来调整，其理想值时BDP：服务端可以发出的未被客户端确认的数据量，也就是在网络上缓存的数据量。

网络连接通常以管道为模型，BDP是带宽与RTT的乘积，表示需要多少数据填充管道。BDP = TX ✖ RTT。例如：在千兆的网络上，RTT为10ms，那么BDP = （1000/8）✖ 0.01s = 1.25MB。

net.ipv4.tcp_rmem = <MIN><DEFAULT><MAX>：调整RWND设置。

默认情况下，系统会在最大值和最小值之间自动调整缓冲区大小，是否自动调整通过tcp_moderate_rcvbuf选项来决定。在开启缓冲自动调整的情况下，可以把最大值设置为BDP。

TCP使用2个字节记录窗口大小，因此最大值为64KB，如果超过这个值，则需要使用tcp_window_scaling机制，通过设置开启。net.ipv4.tcp_window_scaling = 1

RWND和CWND可能是让系统达到最大吞吐量的两个限制因素。

2. TCP的接受窗口（RWND）

TCP的滑动窗口机制依据接收端的能力来进行流控，并不能感知网络延迟等网络因素。拥塞控制机制会评估网络能承受的符合，避免过量数据发送到网络中，拥塞程度会涉及主机、路由器等网络中的所有因素。

拥塞控制由发送方实现，发送方会将它传输的数据流量限制为CWND和RWND的最小值。CWND会随着时间和对端的ACK增长，如果检测到网络拥塞，则缩小CWND。拥塞控制主要有4种算法：慢启动、拥塞避免、快速重传和快速恢复。

慢启动：对于刚建立的连接，开始发送数据时，一点点提速，而不是一下子使用很大的带宽。慢启动时指数上升的过程，直到CWND>=ssthresh，进入拥塞避免算法。

调节初始拥塞窗口（INTCWND）的大小。适度增加INTCWND可以降低HTTP响应延迟。

例如：HTTP要返回的内容为20K，MSS（最大报文段长度）的大小为1460，整个内容需要传送15个MSS。当INTCWND为3时，服务端先发送3个MSS，1460×3=4380字节，待客户端ACK后，根据指数增加算法。第二次发送9个MSS，1460×9=13140字节，第三次发送3个MSS的剩余字节。整个传输过程经过了3次RTT。如果INTCWND设置为15，则只需要一次RTT就可以完成传输。

如果系统上的INTCWND低于10，可以使用ip命令调整。

3. TCP的拥塞窗口（CWND）

文件的读和写操作都会经过操作系统的cache，读缓存时比较简单的，写缓存相对复杂。一般情况下，写文件的数据先到系统缓存（page cache），再由系统定期异步地刷入磁盘，这些存储与page cache中尚未刷盘的数据成为脏数据（脏页，dirty page）。写缓存可以提升I/O速度，但存在数据丢失的风险。例如：尚未刷盘的时候主机断电。

从page cache刷到磁盘有以下三种时机：1，可用物理内存低于特定阈值时，为了给系统腾出空闲内存；2.脏页驻留书简超过特定阈值时，为了避免脏页无限期驻留内存；3.被用户的sync()或fsync()触发。

由系统执行的刷盘有两种写入策略：1.异步执行刷盘，不阻塞用户I/O；2. 同步执行刷盘，用户I/O被阻塞，直到脏页低于某个阈值。一般情况下，系统先执行第一种策略，当脏页数据量过大，异步执行来不及完成刷盘时，切换到同步方式。我们可以通过内核参数调整脏数据的刷盘阈值：1. vm.dirty_background_rtio，默认10。定义了一个百分比。当内存中的参数超过这个百分比后，系统使用异步方式刷盘。2. vm.dirty_ratio，默认30。定义了一个百分比，当内存中的脏数据超过这个百分比后，系统使用同步方式刷盘，写请求被阻塞，直到脏数据低于dirty_ration。如果还高于dirty_background_ratio，则切换到异步方式刷盘。因此dirty_ratio应高于dirty_background_ratio。

vm.dirty_expire_centisecs：默认值3000（30s），单位为百分之1s，定义脏数据的过期时间，超过这个时间后，脏数据被异步刷盘。

vm.dirty_writeback_centisecs：默认500（5s），单位百分之1s，新系统周期性地启动线程来检查是否需要刷盘，该选项定义这个间隔时间。

如果数据安全性要求没有那么高，想要多”cache“一些数据，让读取更容易命中，则可以增加脏数据占比和过期时间：vm.dirty_background_ratio = 30；vm.dirty_ratio = 60；vm.dirty_expire_centisecs = 6000，反之则可以降低它们。如果只希望写入过程不要被系统的同步刷盘策略影响，则可以让系统多容纳脏数据，当早一些触发异步刷盘。这样也可以让I/O更平滑：vm.dirty_background_ratio = 5；vm.dirty_ratio = 60

4.vm相关参数

透明大页是Linux的一个内核特性，它通过更有效地使用过处理器的内存映射硬件来提高性能，默认情况下是启用的。透明大页能略微提升程序性能，但是也可能对程序产生负面影响，甚至是严重的内存泄露。为了避免这些问题，我们应该禁用它。

5. 禁用透明大页（Transparent Hugepages）

3.优化内核参数

系统层

从ES5.X开始，索引级别的配置需要写到模板中，而不是.yml文件，但是我们需要一些索引级别的全局设置信息，例如，translog的刷盘方式等，因此我们可以将这些设置编写到一个模板中，并让这些模板匹配全部索引”*“，这个模板我们称为全局模板。

1. 使用全局模板

如果有一个索引每天都有新增内容，那么不要让这个索引持续增大，建议使用日期等规则按一定频率生成索引。同时将索引设置写入模板，让模板匹配这一系列的索引，还可以为索引生成一个别名关联部分索引。

2. 索引轮转

默认情况下，ES的分片均衡策略是尽量保证各个节点分片数量大致相同。但是当集群扩容时，新加入集群的节点没有分片，此时新创建的索引分片会集中在新节点上，这导致新节点有太多热点数据，该节点可能会面临巨大的写入压力。因此，对于一个索引的全部分片，我们需要控制单个节点上存储的该索引的分片总数，使索引分片在节点上分布得更均匀一些。

例如：10个节点的集群，索引主分片数为5，副本数量为1，那么平均下来应该有（5×2）/10=1个分片，考虑到节点故障、分片迁移的情况，可以设置节点分片总数为2：（\"routing.allocation.total_shards_per_node\"：2）

3. 避免热索引分片不均

大部分场景下，将副本数number_of_replicas设置为1即可。如果对搜索请求的吞吐量要求较高，则可以适当增加副本数量。如果在项目初始阶段不知道多少副本数够用，则可以先设置为1，后期再动态调整。对副本数的调整只会设计数据复制和网络传输，不会重索引，因此代价较小。

4. 副本数选择

对冷索引执行Force Merge有许多好处：1. 单一的分段比众多分段占用的磁盘空间更小一些；2. 可以大幅度减少进程需要打开的文件fd；3. 可以加快搜索的过程，因为搜索需要检索全部分片；4. 单个分段加载到内存时也比多个分段更节省内存占用。可以选择在系统的空闲时间段对不再更新的只读索引执行Force Merge。

段合并命令将分段合并为单个分段，执行成功后会自行”flush“。理想情况下，Force Merge为单一的分段比较好，因为ES要为非单一分段创建全局序数，占用较多fielddata空间。如果业务低谷开始执行的Force Merge到了业务高峰期还没Merge完毕，则需要调整目标分段数量。

5. Force Merge

分片数越多集群压力越大。创建索引时，为索引分配了较多的分片，但可能实际数据量并没有多大，对这种索引可以执行Shrink操作来降低索引分片数量。

可以为Shrink Index和上一节的Force Merge编写自动运行脚本，通过crontab选择在凌晨的某个时间对索引进行优化。然后将定时任务添加到普通用户的定时任务中：crontab escron。通常会为部署集群编写部署脚本，这些工作都可以放到部署脚本中。

6. Shrink Index

如果有些索引暂时不使用，则不会再有新增数据，也不会对它的查询操作，但是可能以后会用而不能删除，那么可以把这些索引关闭，在需要时再打开。关闭的索引除存储空间外不占用其他资源。

7. close 索引

当一个节点由于某些原因离开集群时，默认情况下ES会重新确定主分片，并立即重新分配缺失的副分片。但是，一般来说，节点离线是常态，可能由于网络原因、主机断电、进程退出等因素，重新分配副分片的操作代价是很大的，该节点上存储的数据需要再集群上重新分配，赋值这些数据需要大量带宽和时间，因此我们调整节点离线后分片重新分配的延迟时间：index.unassigned.node_left.delayed_timeout：5d。

节点离线一般是暂时的，如果因为硬件故障，则修复时间是可以预期的。

8. 延迟分配分片

聚合时，ES通过doc_values获取字段值，但是text类型不支持doc_values。当在text字段上聚合时，就会依赖fielddata数据结构，但fielddata默认关闭。因为它会消耗很多堆空间，并且再text类型字段上聚合通常没有什么意义。

doc_values在索引文档时就会创建，而fielddata是在聚合、排序，或者脚本中根据需要动态创建的。其读取每个分段中的整个倒排索引，反转term和doc的关系，将结果存储到JVM堆空间，这是非常昂贵的过程，会让用户感到明显的延迟。

fielddata所占用的大小默认没有上限，可以通过indices.fielddata.cache.size来控制，该选项设置一个堆内存的百分比，超过这个百分比后，使用LRU算法将老数据淘汰。

9. 小心地使用fielddata

索引层

Java API将在未来的版本中废弃，客户端最好选择REST API作为客户端。

1. 使用REST API而非 Java API

bulk请求被放入ES队列，当队列满时，新请求被拒绝，并给客户端返回429的状态码。客户端需要处理这个状态码，并在稍后重发请求。此刻客户端需要处理bulk请求中部分成功、部分失败的情况。

这种情况产生在协调节点转发基于分片的请求到数据节点时，有可能因为对方的bulk队列满而拒绝写操作，而其他数据节点正常处理，于是客户端的bulk请求部分写入成功、部分写入失败。客户端需要将返回429的对应数据重试写入，而不是全部数据，否则写入的内容就会存在重启。

产生429错误是因为ES来不及处理，一般是由于写入端的并发过大导致的，建议适当降低写入并发。

2. 注意429状态码

curl -X HEAD只是将HTTP头部的方法设置为HEAD，还会等待服务器返回body，所以现象就是curl命令阻塞在那里，正确的方式应该是使用-I参数curl -H \" \"。使用-I参数会将HTTP方法设置为HEAD，并在收到服务器返回的HTTP头部信息后关闭TCP连接。

3. curl的HEAD请求

只有了解搜索指令的执行代价，才能更好地使用ES进行搜索。例如：尽量让少的分片参与工作，如果要检索当天的内容，则只搜索当天的索引即可。除了认为评估查询语句，还可以使用Profile API分析会命中哪些分片，每个分片执行的查询时间等细节。

4. 了解你的搜索计划

读写操作都有可能是比较长的操作，例如：写一个比较大的bulk数据，或者执行较大范围的聚合。此时客户端应该为请求设置的超时时间应该尽量长，因为即使客户端断开连接，ES仍然会在后台将请求处理完，如果超时设置比较短，则在密集的请求时会对ES造成非常大的压力。

5. 为读写请求设置比较长的超时时间

客户端

由于协调节点的合并压力，所有的搜索系统都会限制返回的结果集大小，如果确实需要很大的结果集，则应该使用Scroll API。

1. 避免搜索操作返回巨大的结果集

http.max_context_length的默认值为100MB，ES会拒绝索引超过此大小的文档，可以增加这个值，但Lucene仍然大约有2GB的限制。大型文档给网络、内存和磁盘造成了更大的压力。

例如：想要为一本书建立索引使之可以被搜索，这并不意味着把整本书的内容作为单个文档进行索引。最好使用章节或段落作为文档，然后在文档中加一个属性标识它们属于哪本书。这样避免了大文档的问题。

2. 避免索引巨大的文档

_type本来是用于区分存储到同一个索引中的不同格式的数据，但是实际上面这种情况应该用不同的索引解决，而不是在一同一个索引中使用不同的_type。

3. 避免使用多个_type

默认禁用。此类需求可以通过mapping中的copy_to参数创建自定义的_all字段。

4. 避免使用_all字段

无论索引文档还是执行搜索请求，客户端都应该避免将请求发送到固定的某个或少数几个节点，因为少数几个协调节点作为整个集群对外的读写节点的情况下，它们很可能承受不了那么多的客户端请求。尤其是搜索请求，协调节点的合并及排序会占用比较高的内存和CPU，聚合会占用更多内存。因此会导致给客户端的返回慢，甚至导致节点OOM。

正确的做法是将请求轮询发送到集群所有节点，如果使用REST API，则可以在构建客户端的客户端对象时传入全部节点列表。

如果在前端或脚本中访问ES集群，则可以部署LVS，客户端使用虚IP，或者部署Nginx使用反向代理。

5. 避免将请求发送到同一个协调节点

读写

通过Painless脚本控制搜索评分。

ES有多种方式控制对搜索结果的评分，如果常规方式无法得到想要的评分结果，则可以通过脚本的方式完全自己实现评分算法，以得到预期的评分结果。ES自己实现的专用语言：Painless。Painless是内置支持的，脚本内容通过REST接口传递给ES，ES将其保存在集群状态中。6.X版本只能通过REST接口写入。

控制相关度

综合应用实战

Profile API返回所有分片的详细信息。

1.Query：Query段由构成Query的元素以及它们的时间信息组成。

2. Rewrite Time：由于多个关键字会分解以创建个别查询，所以在这个过程中肯定会花费一些时间。将查询重写一个或多个组合查询的时间被称为”重写时间“。

3. Collectors：在Lucene中，收集器负责收集原始结果，并对它们进行组合、过滤、排序等处理。

使用Profile API定位慢查询

一个ES索引由多个分片组成，由于某些原因，某些分片可能会处于未分配状态，导致集群健康处Yellow或Red状态。导致分片处于未分配的原因可能是节点离线、分片数量设置错误等原因。

Explain API可以分析出当前的分片分配情况。这个API主要解决了下面两个问题：1. 对于未分配的分片，给出为什么没有分配的具体原因；2. 对于已分配的分片，给出为什么将分片分配给特定节点的理由。

诊断未分配的主分片

诊断未分配的副分片

如果想将分片手工迁移到某个节点，但是出于某些原因分片没有迁移。

诊断已分配的分片

使用Explain API分析未分配的分片

节点占用CPU很高，想知道CPU正在运行什么任务，一般通过线程堆栈来看。

两种方式查看哪些线程CPU占用率比较高。1. 使用hot_threads API；2. 使用top+jstack，top获取线程级CPU占用率，再根据线程ID，配合jstack定位CPU占用率在特定比例上的线程堆栈。

节点CPU使用率高

节点内存使用率高，我们想知道内存是被哪些数据结构占据的，通用方式是用jmap导一个堆出来，加载到MAT中进行分析，可以精准定位数据结构占用内存大小，以及被哪些对象引用。

jmap导出的堆可能非常大，操作比较花时间，ES中有几个占用内存比较大的数据结构，有些数据结构无法看到其当前的实际大小，只能通过设置的上限粗略评估。

bulk队列。可以通过_cat API查看bulk队列中当前的使用量，任务总数乘以bulk请求的大小就是占用内存的大小。如果队列设置很大，则在写入压力大的时候就会导致比较高的内存占用。默认值为200，一般情况下都够用了。

Netty缓冲。在一些特别的情况下，Netty的内存池也可能会占用比较高的内存。Netty收到一个客户端请求时，为连接分配内存池，客户端发送的数据存储到Netty的内存池中，直到ES层处理完上层逻辑，回复客户端时，才释放内存。

当ES收到客户端请求时，如果在处理完毕之前客户端关闭连接，则ES依然会把这个请求处理完，只是最后才出现回复客户端失败。这个过程可能会导致内存累积。例如：执行bulk请求时，客户端发送完毕，不等ES返回响应就关闭连接，然后立即发起下一个请求，结果这些请求实际上都在等待处理，就可能占用非常多的内存。所以客户端的请求超时时间应该尽量设置得长一些，建议设置为分钟级。

Indexing buffer。索引写入缓冲用于存储索引好的文档数据，当缓冲满时，生成一个新的Lucene段。在一个节点上，该节点的全部分片共享indexing buffer。该缓冲默认大小为堆内存10%，加大该缓冲需要考虑到对GC的压力。

超大数据集的聚合。协调节点对检索结果进行汇总和聚合，当聚合设计的数据量很大时，协调节点需要拉取非常多的内容，大范围的聚合是导致节点OOM的常见原因之一。

分段内存。一个Lucene分段就是一个完整的倒排索引，倒排索引由单词词典和倒排列表组成。在Lucene中，单词词典中的FST结构会被加载到内存。因此每个分段都会占用一定的内存空间。（API：查看每个节点上的所有分段占用的内存总量；单独查看每个分段的内存占用量。）

Fielddata cache。在text类型字段上进行过聚合和排序时会用到Fielddata，默认是关闭的。

Shard request cache。分片级别的请求缓存。每个分片独立地缓存查询结果。该缓冲默认是开启的，默认为堆大小的1%。（可以通过 indices.request.cache.size 调整。）其使用LRU淘汰策略。默认情况下，只会缓存 size = 0 的请求，它并不缓存命中结果（hits），但是会缓存 hits.total、aggregations和suggestions。

Node Query Cache。节点查询缓存由节点上的所有分片共享，也是一个LRU缓存，用于缓存查询结果，只缓存在过滤器上下文中使用的查询。该缓存默认开启，大小为堆大小的10%。（indices.queries.cache.size可以配置大小；index.queries.cache.enabled在索引级启用或禁用该缓存；）

ES进程的内存使用量与Lucene以mmap方式加载段文件相关。mmap加载的文件会被分配进程地址空间，因此它们同样算作ES占用的内存，可以通过mmap命令查看进程都有哪些文件被映射进来。通过mmap系统调用映射进来的段文件数据量通常都比较大，如果mmap带的来难以控制的内存占用对系统来说是个麻烦。

节点内存使用率高

当遇到查询慢的时候，想知道对方的查询语句是什么，在日志记录所有查询语句可能会导致日志量太大，因此ES允许只将执行慢的请求记录日志，”慢“的程度可以自己定义。

ES记录了两种类型的慢日志。

慢搜索日志。用来记录哪些查询比较慢，”慢“的程度由程序自己定义，每个节点可以设置不同的阈值。ES的搜索由两个阶段组成：查询和取回。慢搜索日志给出了每个阶段所花费的时间，以及整个查询内容本身。慢搜索日志可以为查询和取回阶段单独设置以时间为单位的阈值，如果设置为0，则输出全部搜索日志。在定义好每个级别的时间后，通过level决定输出哪个级别的日志。

慢索引日志。用来记录哪些索引操作比较慢，其记录了哪些索引操作耗时比较长，阈值可以设置。与慢搜索不同，索引内容可能非常大，因此默认记录源文档内容的前1000行。可以设置为捕获整个文档，或者不记录原始文档本身。

Slow Logs

iostat。iostat是用来分析I/O状态的常用工具，其输出结果是以/proc/diskstats为基础计算的。iops：r/s，w/s。await：平均I/O等待时间。%util：设备的繁忙比，是设备执行的I/O时间与所经过的时间百分比。

进程级I/O状态。iostat提供磁盘级的I/O状态，可以使用blktrace来分析I/O请求的各个环节。如果想看哪些进程的I/O最高，则可以使用pidstat或iotop两个工具。它们可以动态给出每个进程的读写速度。

1. I/O信息

top、free、vmstat等工具可以帮助我们看到基础的内存信息。当系统物理内存不足时，系统回收内存的效率如何。sar -B观察内存分页的统计信息。当一个进程需要更多内存而实际空间不足时，就会发生页面扫描。

sar -W。在开启了交换分区的系统上，查看页面交换情况。发生页面交换会导致服务器性能严重下降，我们应该在生产环境关闭交换分区。

2. 内存

基本信息。vmstat输出用户级（us）和内核级（sy）的CPU占用百分比，以及采样周期内的上下文切换次数。mpstat除了获取用户级（usr）和内核级（sys）的CPU占用百分比，还可以输出采样周期内的软中断（soft）、硬中断（hard）占用时间的百分比。

诊断导致CPU高的系统调用。正常情况下应用程序占用用户态CPU时间，如果进程暂用sys比较高，则表示程序执行在内核态的操作非常耗费CPU。

3. CPU信息

sar。sar是用来查看网卡流量的常用方式，它以字节为单位输出网络传入和传出流量。

netstat。netstat -anp可以列出连接的详细信息，并且可以将连接、监听的端口对应到进程。其中Recv-Q和Send-Q代表该连接在内核中等待发送和接收的数据长度，单位为字节。例如：发送数据时，send调用将数据从用户态复制到内核态后返回，TCP协议栈负责将数据发送出去，Send-Q代表了尚未发送出去的数据量。在未发送完之前，这些数据停留在内核缓冲，原因可能是网络延时，或者对端的滑动窗口限制。Recv-Q则代表协议栈已完成接收，但尚未被应用层的read调用从内核态赋值到用户态的数据长度。

ss与netstat类似，适合处理海量连接。

ifconfig。留意其中的RX/TX errors、dropped、overruns信息，大部分情况下没什么问题，但是当网卡流量跑满的时候可能会出现意外。

sysdig。可以分析系统级和进程级许多方面的情况。例如：系统调用、网络统计、文件I/O等，用它捕获某个进程到某个IP的网络流量。

4. 网络连接和流量

分析工具

5.X 重大变化。string类型被text/keyword两个类型取代。索引级的设置不再写入.yml文件，需要为每个索引单独设置。添加了Profile API、Shrink API、Rollover API、Reindex API。添加了Plainless脚本。增加了Task Manager，重建索引等任务被Task Manager管理。评分算法使用BM25代替TF/IDF。

6.X 变化。每个索引支持一个_type。默认禁用_all。优化了doc values，占用磁盘空间少，读写速度更快。增加了序列ID，加快索引恢复速度。查询语法变多。

重大版本变化

故障诊断

ES是实时的分布式搜索引擎，新增到ES的数据1s后就可以被检索到。什么是全文？对全部的文本内容进行分析，建立索引，使之可以被搜索。

在创建索引时，定义字段的数据类型，指定不同的分析器。

搜索是基于索引为单位的，而不是基于文档的。

索引结构：JSON作为文档的序列化格式。

增加系统可用性，读操作可以并发执行，分担集群压力。

带来一致性问题：部分副本写成功，部分副本写失败。

应对并发更新问题，ES将数据副本分为主分片、副本分片。写过程先写主分片，成功后再写副分片，恢复阶段以主分片为主。

分片的目的是分割巨大索引，让读写可以并行操作。

一个索引包含多个分片，一个分片是一个Lucene索引，Lucene索引又有很多分段组成，每一个分段都是一个倒排索引。ES每次“refresh”时都会生成一个新的分段。

ES index —> Lucene索引 —> segment段 —> Field字段

1.巨大的索引在数据老化后难以删除，以_id为单位删除文档不会立刻释放空间，删除的doc只在Lucene分段合并时才会真正从磁盘中删除。

2. 手工触发分段合并，仍然可能会引起较高的I/O压力，并且可能因为分段巨大导致在合并过程中磁盘空间不足（分段大小大于磁盘可用空间的一半）。

实际应用中，不应该向单个索引持续写数据。

分片

倒排索引一旦被写入就具有不变性。

好处：对文件的访问不需要加锁，读取索引时可以被文件系统缓存等。

新增内容并写入到一个新的倒排索引中，查询时，每个倒排索引都被轮流查询，查询完再对结果进行合并。

由于分段的不变性，更新、删除等操作实际上是将数据标记为删除。因此删除部分数据不会释放磁盘空间。

动态更新索引

ES每秒产生一个新分段，新段先写入文件系统缓存(该数据已经对读取可见)，但稍后再执行flush刷盘操作，写操作很快会执行完，一旦写入成功，就可以像其他文件一样被打开和读取了。

由于系统先缓存一段数据才写，且新段不会立即刷入磁盘，这两个过程中如果出现意外情况，则存在数据丢失的风险。通用做法是记录事务日志。

近实时搜索

refresh：在ES中，每秒清空一次写缓冲，将这些数据写入文件，这个过程成为refresh，每次refresh都会创建一个新的Lucene段。

每个搜索请求都需要轮流检查每个段，查询完再对结果进行合并。所以段越多，搜索也就越慢。

小段合并为大段策略：选择大小相似的段分段进行合并。合并过程中，标记为删除的数据不会写入新分段，当合并过程结果，旧的分段数据被删除，标记删除的数据才从磁盘删除。

当持续地向一个表中写数据，如果段文件大小没有上限，当巨大的段达到磁盘空间一半时，剩余空间不足以进行新的段合并过程。如果段文件设置一定上限不再合并，则对表中部分数据无法实现真正的物理删除。

段合并

基本概念和原理

分布式系统的集群方式大致可以分为主从模式和无主模式。

主节点也可以作为数据节点，生产环境给应尽量分离节点和数据节点，创建独立节点配置：node.master=true; node.data=false

为了防止数据丢失，每个主节点都应该知道有资格成为主节点的数量，默认为1。为了避免网络分区时出现多主的情况，配置discovery.zen.minimum_master_nodes原则上最小值应该是：（master_eligible_nodes / 2）+ 1

主节点：负责集群层面的相关操作，管理集群变更。全局唯一。

数据节点配置：node.master:false; node.data:true; node.ignest: false

数据节点：负责保存数据、执行数据相关操作：CRUD、搜索、聚合等。数据节点只与数据节点打交道。

预处理操作允许在索引文档之前，即写入数据之前，通过事先定义好的一系列的processors（处理器）和pipeline（管道），对数据进行某种转换、富化。

processors呵呵pipeline拦截bulk和index请求，在应用相关操作后将文档传回给index或bulk API。

默认情况下，在所有节点上启用ignest。node.ignest: true

预处理节点

客户端请求可以发送到集群的任何节点，每个节点都知道任意文档所处的位置，然后转发这些请求，收集数据并返回给客户端。

node.master: false node.data: false node.ignest:false

协调节点：处理客户端请求的节点。

部落节点：部落功能允许部落节点在多个集群之前充当联合客户端。

集群的节点管理

集群健康状态

集群状态

当集群扩容、添加节点时，分片会均衡地分配到集群的各个节点，从而对索引和搜索过程进行负载均衡，这些都是系统自动完成的。

分片副本实现了数据冗余，防止硬件故障导致数据丢失。

分片过程中除了让节点间均匀存储，还要保证不把主分片和副分片分配到同一节点，避免单个节点故障引起数据丢失。

分布式系统中，当节点异常时，ES会自动处理节点异常。当主节点异常时，集群会重新选举主节点。当某个主分片异常时，会将副分片提升为主分片。

集群扩容

集群内部原理

客户端API

Cluster模块是主节点执行集群管理的封装实现，管理集群状态，维护集群层面的配置信息。

管理集群状态，将新生成的集群状态发布到集群所有节点。

在集群各节点中直接迁移分片，保持数据平衡。

Cluster

封装分片相关的功能和策略，包括主分片的分配和副分片的分配，由主节点调用。

allocation

发现模块负责发现集群中的节点，以及选举节点。

发现模块类似Zookeeper的作用，选主并管理集群拓扑。

Discovery

负责对收到Master广播下来的集群状态数据的持久化存储，并在集群完全重启时恢复它们。

gateway

索引模块管理全局级的索引设置，不包括索引级的。

集群启动阶段需要的主分片恢复和副分片恢复就是在这个模块中实现的。

Indices

HTTP模块本质上是完全异步的，没有阻塞线程等待响应。使用异步线程进行HTTP好处是解决了C10k问题（10k量级的并发连接）

部分场景下，使用HTTP keepalive提升性能。不要在客户端使用HTTP chunking

HTTP

传输模块用于集群内节点之间的内部通信。从一个节点到另一个节点的每个请求都是使用传输模块。

传输模块本质上是完全异步的。

传输模块使用TCP通信，每个节点都与其他节点维持若干TCP长连接。

Transport

封装了对Lucene操作及translog的调用，它是对一个分片读写操作的最终提供者。

ES使用Guice框架进行模块化管理。

Engine

主要模块简介

ES基本概念

Discovery模块负责发现集群中的节点，以及选择主节点。ES内置的实现称为Zen Discovery。

设计思想：所有分布式系统都需要以某种方式处理不一致问题。一般情况下，可以将策略分为两组：试图避免不一致以及发生不一致之后如何协调他们。

ES的典型场景中的另一个简化是集群中没有那么多节点。通常，节点的数量远远小于单个节点能够维护的连接数，并且网络环境不必经常处理节点的加入和离开。

这就是为什么主从模式能适合ES

为什么使用主从模式？

假定所有节点都有一个唯一的ID，使用该ID对节点进行排序。任何时候的当前Leader都是参与集群的最高ID节点。但是当拥有最大ID的节点处于不稳定状态的场景下会有问题。例如：Master负载过重而假死，集群拥有第二大ID节点被选为新主，这时原来的Master恢复，再次被选为新主，然后又假死....

ES通过推迟选举，直到当前的Master失效来解决上述问题，只要当前节点不挂掉，就不重新选主。但是容易产生脑裂（双主），为此，再通过“法定得票人数过半”解决脑裂问题。

Bully算法

Paxos在进行选举方面的灵活性比简单的Bully算法有很大的优势，因为在现实生活中，存在比网络连接异常更多的故障模式。

Paxos实现起来非常复杂。

Paxos算法

选举算法

discovery.zen.minimum_master_nodes：最小主节点数，这是防止脑裂、防止数据丢失的及其重要的参数。

为了避免脑裂，这个值因该是半数以上。（master_eligible_nodes / 2） + 1

discovery.zen.ping.unicast.hosts: 集群的种子节点列表，构建集群时本节点会尝试连接这个节点列表，那么列表中的主机会看到整个集群中都有哪些主机。

discovery.zen.ping.unicast.hosts.resolve_timeout：DNS解析超时时间，默认为5秒。

discovery.zen.join_timeout：节点加入现有集群时的超时时间，默认为ping_timeout的20倍。

discovery.zen.join_retry_attempts join_timeout：超时之后的重试次数，默认为3次。

discovery.zen.join_retry_delay join_timeout：超时之后，重试前的延迟时间，默认100ms。

discovery.zen.master_election.ignore_non_master_pings：设置为true时，选主阶段将忽略来自不具备Master资格节点（node.master: false）的ping请求，默认为false。

discovery.zen.fd.ping_interval：故障检测间隔周期，默认为1s。

discovery.zen.fd.ping_timeout：故障检测请求超时时间，默认为30s。

discovery.zen.fd.ping_retries：故障检测超时后的重试次数，默认为3次。