ES7.X写入过程原理及写入优化具体步骤

Elasticsearch写入数据原理

首先，客户端接收写入请求，将请求路由到其中的一个node下的一个分片（随机轮询算法）。
一。refresh：数据打入buffer，再打入os cache（此时已经可以访问），再写入一个segmentfile。一个过程称之为refresh。当写入完成buffer清空，默认1s一次。
二。flush：数据不仅打入buffer，也记录在tranlog，但每次buffer数据清空，tranlog不清空。tranlog积攒5秒（默认）后，执行flush。 flush第一步 refreshbuffer。第二步，建立commit point写入磁盘 。第三步。os cache强刷进入磁盘。（有java rest api可以控制flush，也就是控制刷盘操作）。
三。段合并
定期段合并 将每个refresh产生的segmentfile合并，将合并后segment file写入磁盘，也写入一个commit point。将之前segment file标记del之后物理删除。
四。注意：tranlog写入os cache那5秒。数据在buffer，tranlog os cache，以及buffer refresh写入的segment file里。并未持久化，所以此时宕机会导致5秒的数据丢失。

ES集群写入优化原理

一。加大tranlog的flush间隔，降低iops和写阻塞：

   默认index.translog.durability: request
  修改为index.translog.durability: async
  同时设置index.translog.sync_interval: 20s
  也就是刷盘周期。默认刷盘周期5s。不可设置低于100毫秒。
  同时因为加大了flush时间，导致tranlog增大，则应该增加
  tranlog阈值。
  index.translog.flush_threshold_size: 1024mb
  最大1024默认512，不可超越1024，因为会导致refresh从而
  产生新的Lucene段，导致频繁段合并。

二。加大索引刷新间隔refresh_interval：

    index.refresh_interval: 20s 默认1秒

三。段合并优化：

   段合并由lucene控制。 
   index.merge.scheduler.max_thread_count
   以及
   index.merge.policy.*
   index.merge.policy.segments_per_tier每层分段数量，数量越大，
   段合并越少，默认为10
   index.merge.policy.max_merged_segment指定单个segment最大容
   量5GB

四。索引缓冲区：

   indices.memory.index_buffer_size  可以适当增大其max min
   因为缓冲满会刷盘，也会生成新的segment file，我们的目的是降低
   生成segementfile的几率从而提高写效率。

五。bulk批处理线程池参数和队列

  因为建立索引索引的过程属于计算密集型
  最大线程数=CPU核心数+1；
  （IO密集型： 核心线程数 = CPU核数 / （1-阻塞系数））
  阻塞系数 = 平均等待/平均运行
  另外 阻塞队列大小也可以适当增加
  
  需要测试集群真正的写入压力测试，评估集群极限写入能力。

五。shard的任务分配（简要概述）

    写入原理已经详细介绍，简单轮询算法寻找shard。并不总是正确。
    基于可用空间的动态加权轮询也是可以的。

六。 索引过程调整和优化

    1.并发下，如果指定了doc_id，es有乐观锁机制，会判断版本号，所以可以尽可能自动生成id。
    2.调整字段mapping。这个根据业务具体分析。
    3.禁用_all
    4.禁用norms 评分。