分布式个性

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操作