关于java:elastic-stack-那些事5

分布式个性

es 反对集权模式，是一个分布式系统，益处有二：

1. 增大零碎容量，磁盘 内存 使得 es 集群能够反对 pb 级别的业务
2. 进步零碎可用性 即便局部节点进行服务 整个集群能够失常应用

es 集群由多个 es 实例组成

1. 不同的集群通过集群名称组成，通过 cluster.name 定义
2. 每个 es 实例实质上是一个 jvm 过程，且有本人的名字 通过 node.name 定义

构建集群

启动一个节点
bin/elasticsearch -E cluster.name=my_cluster -E node.name=node1

cluster state
es 集群的相干数据称为 cluster state 次要记录如下信息：

1. 节点信息 节点名称 连贯地址等
2. 索引信息 索引名称 配置等

master node
能够批改 cluster state 的节点称为 master 节点 一个集群只能有一个
cluster state 存储在每个节点上，master 保护最新版本并同步给其余节点
master 节点通过集群中所有节点选举产生，能够被选举的节点称为 master eligible 节点
node.master=true

分片

1. 如何将数据分簿于所有节点上
   引入分片解决问题

2. 分片是 es 反对 pb 事务的基石

   1. 分片存储了局部数据，能够散布于任意节点上
   2. 分片数在索引创立时指定，且后续不容许更改，默认为五个
   3. 分片有主分片和正本分片的区别，实现数据高可用
   4. 正本分片数据由主分片同步，能够有多个，从而进步吞吐量
3. 持续减少节点是否进步索引的数据容量？
   不能，只有三个分片，新增节点上的资源无奈被利用
4. 持续减少正本数是否进步索引的数据吞吐量？
   不能，新增正本还是散布在已有节点上，资源并没有增多

衰弱状态

通过 api GET _cluster/health 能够查看集群的健康状况，包含三种：

1. green 衰弱 指所有的主副分片都失常
2. yellow 指所有的主分片都失常 然而有正本分片未失常调配
3. red 所有分片都未调配

故障转移

1. node1 所在的集器宕机，集群会如何解决？

   1. node2 发现主分片 p0 未调配，将 R0 晋升为主分片，此时因为所有的主分片都失常，集群状态为 yellow
   2. node2 为 p0 和 p1 生成新的正本，集群状态为绿色

分布式存储

1. 应用映射算法将文档平均的散布在所有的分片上，以充分利用资源
2. es 应用 shard = hash(routing)%number_of_primary_shards
3. hash 算法能够保障将数据平均的散布在分片中
4. routing 默认为文档 id

文档创立流程

1. client 向 node3 发动文档创立申请
2. node3 通过 routing 计算出该文档应该存储在 shard1 上，查问 cluster state 后确认主分片在 p1
   在 node2 中，转发创立申请到 node2 上
3. p1 接管并创立文档，将同样的申请发送到正本分片 r1
4. r1 接管并执行创立文档申请后告诉 p1 创立胜利
5. p1 接管正本分片后果后，告诉 node3 创立胜利
6. node3 将后果返回给 client

文档读取流程

1. client 向 node3 发动读取文档 1 的申请
2. node3 通过 routing 计算该文档在 shard1 上，查问 cluster state 后获取 shard1 的主副分片列表，而后轮询获取 shard，例如 R1，转发申请到 node1
3. R1 接管并执行读取文档，将后果返回 node3
4. node3 返回后果给 client

脑裂问题

1. 当集群中呈现网络网体，node2 与 node3 从新组成集群选举一个 master，并更新 cluster state
2. node1 本人组成集群后，也会更新 cluster state
3. 同一个大集群有两个 master 并且有两个 cluster state 网络复原后无奈决定哪个是正确的 master 和 cluster state

4. 解决 减少选举条件 可被选举为 master-eligible 节点数大于等于 quorum 时才能够进行 master 选举

   1. quorum=master-eligible 节点数 /2+1 例如三个 master-eligible 节点时，quorum 为 2
   2. 设定 discovery.zen.minimum_master_nodes 为 quorum 可防止脑裂

shard

倒排索引不可变更

1. 倒排索引一旦生成，不能更改
2. 不必思考并发写文件的问题，防止锁机制带来的性能问题
3. 能够充分利用缓存，载入一次，屡次读取
4. 利于对文件进行压缩存储，节俭磁盘和内存存储空空间
5. 写入新文档时，必须从新构建倒排索引文件，而后替换老文件，新文档才会被检索，实时性差

文档搜寻实时性

1. lucene 构建单个倒排索引称为 segment 合在一起称为 index，与 es 中的 index 不同，es 中一个 shard 对应一个 lucene index。
2. lucene 会有一个专门的文件来记录所有的 segment 信息，称为 commit point。

文档搜寻实时性 – refresh

1. segment 写入缓存，并凋谢查问，该过程称为 refresh
2. 在 refresh 前文档会先存储在一个 buffer 中，refresh 时将 buffer 中的所有文档清空并生成 segment
3. es 默认每一秒执行一次 refresh，因而文档的实时性被进步到 1 秒，这也是 es 被称为近实时的起因

translog

如果缓存中 segment 还没写入磁盘时产生宕机怎么办？

1. es 引入 translog 机制，写入到 buffer 时，同时将操作写入 translog。
2. translog 文件会即时写入磁盘 fsync，6.X 默认每个申请都会落盘，能够批改每五秒一次，这个危险为失落五秒内数据，祥光配置为 index.translog.*
3. es 启动时会查看 translog 文件，并且从中复原数据

flush

flush 负责将内存中的 segment 写入磁盘

1. 将 translog 写入磁盘
2. 将 index buffer 清空，其中的文档生成新的 segment 相当于 refresh 操作
3. 更新 commit point 并写入磁盘
4. 执行 fsync 操作 将内存中的 segment 写入磁盘
5. 删除旧的 translog

删除与更新文档

1. lucene 专门保护一个 .del 文件，记录所有的曾经删除的文档，.del 上记录的文芳时 lucene 外部的文档 id
2. 在分会查问后果前会过滤掉.del 中的文档
3. 更新文档等于先删除，在创立新文档

segment merging

1. 随和 segment 增多 一次查问的 segment 过多 查问速度变慢
2. es 定时在后盾进行 segment merge 缩小 segment 数量
3. 通过 force_mergeapi 能够手动 merge 操作