由于这部分内容涉及到很多 Lucene 和操作系统等内容，个人理解可能不到位或者有误，还请各位看客指出存在的问题，不吝赐教

1. 重要知识点

1. refresh：
当我们向ES发送请求的时候，我们发现es貌似可以在我们发请求的同时进行搜索。而这个实时建索引并可以被搜索的过程实际上是一次es 索引提交（commit）的过程，如果这个提交的过程直接将数据写入磁盘（fsync）必然会影响性能，所以es中设计了一种机制，即：先将index-buffer中文档（document）解析完成的segment写到filesystem cache之中，这样避免了比较损耗性能io操作，又可以使document可以被搜索。从index-buffer中取数据到filesystem cache中的过程叫做refresh。
refresh操作可以通过API设置：

POST /index/_settings
{“refresh_interval”: “10s”}

当我们进行大规模的创建索引操作的时候，最好将将refresh关闭。

POST /index/_settings
{“refresh_interval”: “-1″}

es默认的refresh间隔时间是1s，这也是为什么ES可以进行近乎实时的搜索。

2. flush and translog
我们可能已经意识到如果数据在filesystem cache之中是很有可能在意外的故障中丢失。这个时候就需要一种机制，可以将对es的操作记录下来，来确保当出现故障的时候，保留在filesystem的数据不会丢失，并在重启的时候可以从这个记录中将数据恢复过来。elasticsearch提供了translog来记录这些操作。
当向elasticsearch发送创建document索引请求的时候，document数据会先进入到index buffer之后，与此同时会将操作记录在translog之中，当发生refresh时（数据从index buffer中进入filesystem cache的过程）translog中的操作记录并不会被清除，而是当数据从filesystem cache中被写入磁盘之后才会将translog中清空。而从filesystem cache写入磁盘的过程就是flush。
下图辅助理解，存在一定问题：

2. 进一步修正认知

官方大佬解读
超哥解读
中文社区讨论
陆老师lucene详解
1. 核心概念解读：
ES 的 shard 实质为一个 Lucene 的 index，其中包含多个 Lucene Segments。
Lucene ReOpen： 将积累的数据用于搜索。
Lucene Flush： 将内存的数据写入硬盘，但不执行系统的 sync 进行刷盘操作，实际上只是在系统 cache，相当于 es 的 refresh。
Lucene Commits： Segment 数据和并写入磁盘。
ES Translog： 每个分片一个事务日志，文档写入 ES 时会同步写 Translog 和 Index Buffer Memory。
ES Refresh： Index Buffer Memory 中的数据复制到内存中新建的 Segment 中，然后数据可以查询。这个过程会产生 Lucene Flush 操作，生成一个新的 Segment 。I-B-M清空，但是 Translog 不会清空。
ES Flush： 内存缓冲区的 Segments 写入写合并的 Segment 后落盘，清空 Translog。对应 Lucene Commit 操作。
2. 写入原理相关：
ES 一个分片允许多线程并发写入，写入过程只会所锁文档的 uid。
写入工作主要由于 Lucene 的 IndexWriter 负责，多线程调用 IndexWriter 执行写入时，IndexWriter 会为每个线程分配一个 DocumentsWriterPerThread 对象，简称 DWPT，每个 DWPT 内部包括一个 buffer，这个 buffer 最终会 flush 为单独的 Segment 文件。
当一个 doc 在 IndexWriter 写入完毕后，其内部会判断是否进行 Lucene Flush，当 ES 的 I-B-M 慢了，或者进行 Refresh 操作时，会触发 Lucene Flush，此时会产生较多的 Segments。
执行 Lucene Flush 的时候该 DWPT 不会加锁，因此不会阻塞正在执行的写入操作，写入操作会使用新的 DWPT。