说一下ElasticSearch中文档的写流程

Document写入原理（buffer、segment、commit、segment merge）
ES为了实现搜索的近实时，也是做了很多的设置。结合了内存buffer、OS cache、disk三种存储，尽可能的提升搜索能力。那么在document写入index的时候，就有其独特的写流程。
ES的底层是使用lucene实现的。在lucene中一个index是分为若干个segment（分段）的，每个segment都会存放index中的部分数据。在ES中，是将一个index先分解成若干shard，在shard中，使用若干segment来存储具体的数据。
具体的写入流程查看下图：其中数字仅是标识，不代表绝对顺序流程。

图解：
1：客户端发起增删改请求，将请求发送到ES中。
2：ES将本次请求中要操作的document写入到buffer中。ES为了保证搜索的近实时（NRT），设置了每秒刷新一次buffer的默认操作。buffer的自动刷新时间可以手工修改，也可以通过命令触发buffer的刷新。
POST /test_index/_refresh

PUT test_index
{
“settings”: {
“number_of_shards”: 5,
“number_of_replicas”: 1,
“refresh_interval”: “30s”
}
}
3：ES在将document写入到buffer的同时，也会将本次操作的具体内容写入到translog file中，这个日志文件记录的是ES的所有操作过程。其存在的意义在于保证ES异常宕机也尽可能少的丢失数据。（很难保证绝对的数据不丢失）。Translog文件是在磁盘中的，ES会保持一个长IO，对应这个translog文件。提高访问效率。
4：ES每秒中都会刷新buffer，将buffer中的数据保存到index segment中，这个segment也是一个file文件。在刚创建这个文件的时候，文件是存储在内存中的。segment中存储的是最近1秒钟ES接收到的document写操作数据。
5：在index segment file创建并写入数据后，ES会立刻将segment file写入到系统缓存（OS cache）中，在写入后，index segment立刻被打开，可以为客户端的搜索请求提供服务。不必等待index segment写入到磁盘后再打开index segment，因为写入磁盘的操作是一个IO操作，我们都知道IO操作是一个重量级操作，如果等待index segment写入磁盘后再打开为搜索请求提供服务，那么ES就失去了近实时搜索的能力。当index segment写入OS cache后，buffer中的数据就会清空。
6：translog file记录的是ES的操作过程，万一ES宕机，当重启后，ES会读取系统磁盘中的数据和translog中的日志，实现一个数据的恢复。保证数据尽可能不丢失。translog文件也是持久化在系统磁盘中的，ES默认每5秒钟执行一次translog文件的持久化。如果在持久化的时候刚好有document写操作在执行，那么这次持久化操作会等待写操作彻底完成后才执行。如果允许部分数据丢失的话，可以通过设置修改translog的持久化为异步操作。
PUT test_index
{
“settings”: {
“number_of_shards”: 5,
“number_of_replicas”: 1,
“index.translog.durability” : “async”,
“index.translog.sync_interval” : “5s”
}
}
7：随着时间的推移，translog文件会不断增大。当translog文件大到一定程度的时候或一定时间后，ES会触发commit操作。commit操作具体内容有：将buffer中的数据刷新到一个新的index segment中，将index segment写入到OS cache中并打开index segment为搜索提供服务；清空buffer；执行一个commit point操作，将OS cache中所有的index segment标识记录在这个commit point中并持久化到系统磁盘DISK中；这些commit point中记录的index segment会被ES触发的fsync持久化到DISK中；清空本次持久化的index segment对应的translog文件中的日志内容。这个完整的操作也称为flush。这个操作默认每30分钟执行或translog文件过大时执行。
8：按照之前的所有流程来看，每秒中都会生成一个index segment文件。每30分钟都会将这些index segment文件持久化到磁盘中，那么磁盘中的index segment文件数量会非常多，会影响搜索的效率。ES会自动的执行segment merge操作。merge的时候，被标记为deleted状态的document也会被物理删除。merge的流程是：ES选择一些大小相近的segment文件，merge成一个大的segment文件；将merge后的segment文件持久化到磁盘中；执行一个commit操作，commit point除记录要持久化的OS cache中的index segment外，还记录了merge后的segment文件和要删除的原segment文件；commit操作执行成功后，将merge后的segment打开为搜索提供服务，将旧的segment关闭并删除。

ES中的的search搜索，执行的时候具体的数据所在位置可能在多个位置，如： index segment 1、 index segment 2。search执行的时候，会检索所有已打开的index segment。
注意：在ES中，index中的document数据执行删除和更新操作都不是即时的物理删除，都是先标记为deleted状态，当ES空闲时或存储空间不足时，一次性删除deleted状态的document。所以，在执行删除或更新操作的时候，会先将操作数据写入到buffer中，在buffer数据写入segment中的时候，会生成一个.del文件，用于记录哪一个index segment中的哪一个document是deleted状态的，那么在搜索执行的时候，如果在多个index segment中查询到了多个不同版本的同id值的document时，会依据.del文件中的数据来过滤查询结果，保证搜索结果是正确的。