流程-NTR
refresh：数据写入os cache并被打开供搜索的过程，默认是1秒/次。每隔一秒就会将buffer中的数据写入一个新的index segment file，先写入os cache中。所以，es是近实时的，数据写入到可以被搜索，默认是1秒。
POST my_index/_refresh，可以手动refresh，一般不需要手动执行，没必要，让es自己搞就可以了
比如说，我们现在的时效性要求，比较低，只要求一条数据写入es，一分钟以后才让我们搜索到就可以了，那么就可以调整refresh interval
PUT my_index
{
"settings": {
"refresh_interval": "30s"
}
}
数据写入buffer
写入os cache
只要segment写入os cache，那就直接打开供search使用，不立即执行commit
每隔一定时间，buffer中的数据被写入segment文件
2 流程
基于translog和commit point，如何进行数据恢复
fsync+清空translog，就是flush，默认每隔30分钟flush一次，或者当translog过大的时候，也会flush
POST my_index/_flush，一般来说别手动flush，让它自动执行就可以了
translog，每隔5秒被fsync一次到磁盘上。在一次增删改操作之后，当fsync在primary shard和replica shard都成功之后，那次增删改操作才会成功
但是这种在一次增删改时强行fsync translog可能会导致部分操作比较耗时，也可以允许部分数据丢失，设置异步fsync translog
PUT my_index/_settings
{
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}
数据写入buffer缓冲+translog日志文件
buffer中的数据被写入新的segment file，并进入os cache
间隔一秒
此时segment被打开并供search使用
buffer被清空
重复1~3，新的segment不断添加，buffer不断被清空，而translog中的数据不断累加
当translog长度达到一定程度的时候，commit操作发生
-触发flush操作
buffer中的所有数据写入一个新的segment，并写入os cache，打开供使用
buffer被清空
一个commit ponit被写入磁盘，标明了所有的index segment
filesystem cache中的所有index segment file缓存数据，被fsync强行刷到磁盘上
现有的translog被清空，创建一个新的translog
文件合并
segment merge
why
每秒一个segment file，文件过多，而且每次search都要搜索所有的segment，很耗时
默认会在后台执行segment merge操作，在merge的时候，被标记为deleted的document也会被彻底物理删除
流程
选择一些有相似大小的segment，merge成一个大的segment
将新的segment flush到磁盘上去
写一个新的commit point，包括了新的segment，并且排除旧的那些segment
将新的segment打开供搜索
将旧的segment删除
手动执行
POST /my_index/_optimize?max_num_segments=1，尽量不要手动执行，让它自动默认执行就可以了
数据恢复
查询disk数据
查询translog
只存储上一次flush(commit point)到现在的数据变更
重新执行各种操作
buffer中执行
重新刷新每个segment到os cache
等待下一次commit
更新
删除旧doc
删除
