1. Elasticsearch之分布式特性介绍

1. 分布式介绍及cerebro

es支持集群模式，是一个分布式系统，其好处主要有两个：
- 增大系统容量，如内存，磁盘，使得es集群可以支持PB级的数据
- 增大系统可用性，即使部分节点停止服务，整个集群依然可以正常服务
es集群由多个es实例组成
- 不同集群通过集群名字来区分，可通过cluster.name进行修改，默认为elasticsearch
- 每个es实例本质上是一个JVM进程，且拥有自己的名字，通过node.name进行修改

2. 构建集群

通过如下命令可以启动一个es节点实例

bin/elasticsearch -Ecluster.name=my_cluster -Epath.data=my_cluster_node1 -E node.name=node1 -Ehttp.port=5200 -d

es集群相关的数据称为cluster state，主要记录如下信息：
- 节点信息，比如节点名称，连接地址等
- 索引信息，比如索引名称，配置等
- ...
可以修改cluster state的节点称为master节点，一个集群只能有一个
cluster state存储在每个节点上，master维护最新版本并同步给其他节点
master节点是通过集群中所有节点选举产生的，可以被选举的节点称为master-eligible节点，相关配置如下：
- node.master:true
处理请求的节点即为coordinating节点，该节点为所有节点的默认角色，不能取消
- 路由请求到正确的节点处理，比如创建索引的请求到master节点
存储数据的节点即为data节点，默认节点都是data类型，相关配置如下：
- node.data:true
运行如下命令可以启动一个es节点实例

bin/elasticsearch -Ecluster.name=my_cluster -Epath.data=my_cluster_node2 -E node.name=node2 -Ehttp.port=5300 -d

3. 副本与分片

提高系统可用性

服务可用性
- 2个节点的情况下，允许其中1个节点停止服务
数据可用性
- 引入副本(Replication)解决
- 每个节点上都有完备的数据

增大系统容量

如何将数据分布于所有节点上？
- 引入分片(Shard)解决问题
分片是es支持PB级别数据的基石
- 分片存储了部分数据，可以分布于任意节点上
- 分片数据在索引创建时指定且后续不允许再更改，默认为5个
- 分片有主分片和副本分片之分，以实现数据的高可用
- 副本分片的数据由主分片同步，可以有多个，从而提高读取的吞吐量

4. 两个问题

此时增加节点是否能提高test_index的数据容量？
- 不能。因为只有三个分片，已经分布在3台节点上，新增的节点无法利用
此时增加副本数是否能提高test_index的读取吞吐量？
- 不能。因为新增的副本也是分布在这3个节点上，还是利用了同样的资源。如果要增加吞吐量，还需要新增节点
分片数的设定很重要，需要提前规划好
- 过小会导致后续无法通过增加节点实现水平扩容
- 过大会导致一个节点上分布过多分片，造成资源浪费，同时会影响查询性能

5. 集群状态

通过如下api可以查看集群健康状态，包括以下三种：
- green健康状态，指所有主副分片都正常分配
- yellow指所有主分片都正常分配，但是有副本分片为正常分配
- red有主分片为分配

GET _cluster/health

{
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 21,
  "active_shards" : 21,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 20,
  "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" : 51.21951219512195
}

6. 故障转移

集群由3个节点组成，此时集群状态是green
node1所在机器宕机导致服务终止，此时集群会如何处理？
- node2和node3发现node1无法响应一段时间后会发起master选举，比如这里选择node2为master节点，此时由于主分片P0下线，集群状态变为Red
- node2发现主分片P0未分配，将R0提升为主分片，此时由于所有主分片都正常分配，集群状态变为Yellow
- node2为P0和P1生成新的副本，集群状态变为绿色

7.文档分布式存储

文档最终会存储在分片上：
- Document1最终存储在分片P1上
Document1是如何存储到分片P1的？选择P1的依据是什么？
- 需要文档到分片的映射算法
- 目的：使得文档均匀分布在所有分片上，以充分利用资源
- 算法：
  - 随机选择或者round-robin算法？
  - 不可取，因为需要维护文档到分片的映射关系，成本巨大
  - 根据文档值实时计算对应的分片
es通过如下的公式计算文档对应的分片
- hash算法保证可以将数据均匀的分散在分片中
- routing是一个关键参数，默认是文档id，也可以自行指定
- number_of_primary_shards是主分片数

shard = hash(routing) % number_of_primary_shards

该算法与主分片数相关，这也是分片数一旦确定后便不能更改的原因

文档创建的流程

文档读取的流程

8. 脑裂问题

脑裂问题，英文为split-brain，是分布式系统中的经典网络问题
- 3个节点组成的集群，突然node1的网络和其他两个节点中断
- node2与node3会重新选举master，比如node2成为了新master，此时会更新cluster state
- node1自己组成集群后，也会更新cluster state
同一个集群有两个master，而且维护不同的cluster state，网络恢复后无法选择正确的master
解决方案为仅在可选举master-eligible大于等于quorum时才可以进行master选举
- quorum = master-eligible节点数/2 + 1，例如3个master-eligible节点时，quorum为2
- 设定discovery.zen.minimum_master_nodes为quorum即可避免脑裂

9. shard详解

倒排索引的不可更改

倒排索引一旦生成，不能更改
其好处如下：
- 不用考虑并发写文件的问题，杜绝了锁机制带来的性能问题
- 由于文件不再更改，可以充分利用文件系统缓存，只需载入一次，只要内存足够，对该文件的读取都会从内存读取，性能高
- 利于生成缓存数据
- 利于对文件进行压缩存储，节省磁盘和内存存储空间
坏处为需要写入新文档时，必须重新构建倒排索引文件，然后替换老文件后，新文档才能被检索，导致文档实时性差

文档搜索实时性

解决方案是新文档直接生成新的倒排索引文件，查询的时候同时查询所有的倒排文件，然后做结果的汇总计算即可
Lucene便是采用了这种方案，它构建的单个倒排索引称为segment，合在一起称为Index，与ES中的Index概念不同，ES中的一个Shard对应一个Lucene Index
Lucene会有一个专门的文件来记录所有的segment信息，称为commit point

文档搜索实时性 - refresh

segment写入磁盘的过程依然很耗时，可以借助文件系统缓存的特性，先将segment在缓存中创建并开放查询来进一步提升实时性，该过程在es中被称为refresh
在refresh之前文档会先存储在一个buffer中，refresh时将buffer中的所有文档清空并生成segment
es默认每1秒执行一次refresh，因此文档的实时性被提高到1秒，这也是es被称为近实时(Near Real Time)的原因
refresh发生的时机主要有如下几种情况：
- 间隔时间达到时，通过index.settings.refresh_interval来设定，默认是1秒
- index.buffer占满时，其大小通过indices.memory.index_buffer_size设置，默认为jvm heap的10%，所有shard共享
- flush发生时也会发生refresh

文档搜索实时性 - translog

如果内存中的segment还没有写入磁盘前发生了宕机，那么其中的文档就无法恢复了，如何解决这个问题？
- es引入translog机制，写入文档到buffer时，同时将该操作写入translog
- translog文件会即时写入磁盘(fsync)，6.X默认每个请求都会落盘，可以修改为每5秒写一次，这样风险便是丢失5秒的数据，相关配置为index.translog.*
- es启动时会检查translog文件，并从中恢复数据

文档搜索实时性 - flush

flush负责将内存中的segment写入磁盘，主要做如下的工作：
- 将translog写入磁盘
- 将index buffer清空，其中的文档生成一个新的segment，相当于一个refresh操作
- 更新commit point并写入磁盘
- 执行fsync操作，将内存中的segment写入磁盘
- 删除旧的translog文件
flush发生的时机主要有如下几种情况：
- 间隔时间达到时，默认是30分钟，5.X之前可以通过index.translog.flush_threshold_period控制，之后无法修改
- translog占满时，其大小可以通过index.translog.flush_threshold_size控制，默认是512mb，每个index有自己的translog

文档搜索实时性 - 删除与更新文档

segment一旦生成就不能更改，那么如果你要删除文档该如何操作？
- Lucene专门维护一个.del的文件，记录所有已经删除的文档，注意.del上记录的是文档在Lucene内部的id
- 在查询结果返回前会过滤掉.del中的所有文档
更新文档如何进行呢？
- 首先删除文档，然后再创建新文档

整体视角

Segment Merging

随着segment的增多，由于一个查询的segment数增多，查询速度会很慢
es会定时在后台进行segment merge的操作，减少segment的数量
通过force_merge api可以手动强制做segment merge的操作

2. Elasticsearch 篇之集群调优建议

1. 生产环境部署建议

遵照官方建议设置所有的系统参数
参见文档"Setup Elasticsearch -> Important System Configuration"
- Disable swapping
- Increase file descriptors
- Ensure sufficient virtual memory
- Ensure sufficient threads
- JVM DNS cache settings
- Temporary directory not mounted with noexec

ES设置尽量简洁

elasticsearch.yml中尽量只写必备的参数，其他可以通过api动态设置的参数都通过api来设定
参见文档"Setup Elasticsearch -> Important Elasticsearch Configuration"
- Path settings
- Cluster name
- Node name
- Network host
- Discovery settings
- Heap size
- Heap dump path
- GC logging
- Temp directory
随着ES的版本升级，很多网络流传的配置参数已经不再支持，因此不要随便复制别人的集群配置参数

elasticsearch.yml中建议设定的基本参数

cluster name
node name
node.master/node.data/node.ingest
network.host建议显示指定为内网ip，不要偷懒直接设定为0.0.0.0
discovery.zen.ping.unicast.host设定集群其他节点地址
discovery.zen.minimum_master_nodes一般设定为2
path.data/pata.log
处上述参数外再根据需要增加其他的静态配置参数

动态设定的基本参数

动态设定的参数有transient和persistent两种配置，前者在集群重启后会消失，后者不会，但两种设定都会覆盖elasticsearch.yml中的配置

关于JVM内存设定

不要超过31GB
预留一半内存给操作系统，用来做文件缓存
具体大小根据该node要存储的数据量来估算，为了保证性能，在内存和数据量间有一个建议的比例
- 搜索类项目的比例建议在1：16以内
- 日志类项目的比例建议在1：48 ~ 1：96
假设总数据量大小为1TB，3个node，1个副本，那么每个node要存储的数据量为2TB/3=666GB，即700GB左右，做20%的预留空间，每个node要存储大约850GB的数据
- 如果是搜索类项目，每个node内存大小为850GB/16=53GB，大于31GB。31*16=496，即每个node最多存储496GB数据，所以至少需要5个node
- 如果是日志类型项目，每个node内存大小为850GB/48=18GB，因此3个节点足够

2. 写性能优化

ES写数据过程

refresh
- segment写入磁盘的过程依然很耗时，可以借助文件系统缓存的特性，先将segment在缓存中创建并开放查询来进一步提升实时性，该过程在es中被称为refresh
- 在refresh之前文档会先存储在一个buffer中，refresh时将buffer中的所有文档清空并生成segment
- es默认每1秒执行一次refresh，因此文档的实时性被提高到1秒，这也是es被称为近实时(Near Real Time)的原因
tanslog
- 如果在内存中的segment还没有写入磁盘前发生了宕机，那么其中的文档就无法恢复了，如何解决这个问题？
- es引入translog机制，写入文档到buffer时，同时将该操作写入translog
- translog文件会即时写入磁盘(fsync)，6.X默认每个请求都会落盘，可以修改为每5秒写一次，这样的风险便是丢失5秒的数据
- es启动时会检查translog文件，并从中恢复数据
flush
- 负责将内存中的segment写入磁盘，主要做如下的工作：
- 将translog写入磁盘
- 将index buffer清空，其中的文档生成一个新的segment，相当于一个refresh操作
- 更新commit point并写入磁盘
- 执行fsync操作，将内存中的segment写入磁盘
- 删除旧的translog文件

写性能优化

目标是增大写吞吐量 - EPS(Event Per Second)越高越好
优化方案
- 客户端：多线程写，批量写
- ES：在高质量数据建模的前提下，主要是在refresh，translog和flush之间做文章

refresh

目标为降低refresh的频率
- 增大refresh_interval，降低实时性，以增大一次refresh处理的文档数，默认是1s，设置为-1直接禁止自动refresh
- 增大index_buffer_size，参数为indices.memory.index_buffer_size(静态参数，需要设定在elasticsearch.yml中)，默认为10%

tanslog

目标是降低translog写磁盘的频率，从而提高写效率，但会降低容灾能力
- index.translog.durability设置为async，index.translog.sync_interval设置需要的大小，比如120s，那么translog会改为每120s写一次磁盘
- index.translog.flush_threshold_size默认为512mb，即translog超过该大小时会触发一次flush，那么调大该大小可以避免flush的发生

flush

目标为降低flush的次数，在6.X可优化的点不多，多为es自动完成

其他

副本设置为0，写入完毕再增加
合理的设计shard数，并保证shard均匀的分配在所有node上，充分利用所有node的资源
- index.routing.allocation.total_shards_per_node限定每个索引在每个node上可分配的总主副分片数
- 5个node，某索引有10个主分片，1个副本，上述值应该设置为多少？
  - (10+10)/5 = 4
  - 实际要设置为5个，防止在某个node下线时，分片迁移失败的问题

写性能优化

主要为index级别的设置优化

3. 读性能优化

读性能主要受以下几方面影响：
- 数据模型是否符合业务模型？
- 数据规模是否过大？
- 索引配置是否优化？
- 查询语句是否优化？

数据建模

高质量的数据建模是优化的基础
- 将需要通过script脚本动态计算的值提前算好作为字段存到文档中
- 尽量使得数据模型贴近业务模型

数据规模

根据不同的数据规模设定不同的SLA
- 上万条数据与上千万条数据性能肯定存在差异

索引配置调优

索引配置优化主要包括如下：
- 根据数据规模设置合理的主分片数，可以通过测试得到最适合的分片数
- 设定合理的副本数目，不是越多越好

查询语句调优

查询语句调优主要有以下几种常见手段：
- 尽量使用Filter上下文，减少算分的场景，由于Filter有缓存机制，可以极大提升查询性能
- 尽量不适用Script进行字段计算或者算分排序等
- 结合profile，explain API分析慢查询语句的症结所在，然后再去优化数据模型

4. 如何设定shard数

ES的性能基本是线性扩展的，因此我们只要测出1个Shard的性能指标，然后根据实际性能需求就能算出需要的Shard数。比如但Shard写入eps是10000，而线上eps需求是50000，那么你需要5个shard(实际还要考虑副本的情况)
测试1个shard的流程如下：
- 搭建与生产环境相同配置的单节点集群
- 设定一个单分片零副本的索引
- 写入实际生产数据进行测试，获取写新能指标
- 针对数据进行查询请求，获取读性能指标
压测工具可以采用esrally

5. xpack监控功能介绍

官方推出的免费集群监控功能

最后

大家可以关注我的微信公众号一起学习进步。