1.上一篇文章中提到index segment只要刷入到os cache后，就打开供查询，这个操作是非常危险的，一旦未将数据刷入到os disk，而此时数据丢失，将会导致不可逆的问题。
所以本篇补充，继续进行优化docuemnt写入流程。
2.最终的优化的写入流程：
1）数据写入buffer缓冲和translog日志文件中。
当你写一条数据document的时候，一方面写入到buffer缓冲中，一方面同时写入到translog日志文件中。
2）每隔1秒，buffer中的数据会被写入index segment file，并写入os cache，此时index segment并打开供search查询使用
3）buffer被清空
4）重复1~3步骤，新的segment不断添加，buffer不断被清空，而translog的数据不断增加，随着时间的推移，translog文件会越来越大
5）当translog长度达到一定程度的时候，commit操作发生
5-1）buffer中的所有数据写入一个新的segment，并写入os cache打开供使用
5-2）buffer被清空
5-3）一个commit point被写入磁盘，这个commit point中标明所有的index segment
5-4）filesystem cache（os cache）中的所有index segment file缓存数据，被fsync强制刷到磁盘os disk
5-5）现在的translog被清空，创建一个新的translog
3.基于translog和commit point，如何进行数据恢复
fsync+清空translog，就是flush，默认每隔30分钟flush一次，或者当translog过大的时候，也会flush
POST /my_index/_flush/?wait_for_ongoing
新版本使用
POST /my_index/_flush
执行结果：
{
"_shards": {
"total": 10,
"successful": 5,
"failed": 0
}
}
但是不建议使用手动flush，让es自动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"
}
4.es数据恢复
os cache中囤积了一些数据，但是此时服务器宕机，os cache中的数据全部丢失，那么我们怎么进行数据恢复？
机器被重启，disk上的数据并没有丢失，
os disk 上面存放了上一次commit point为止，所有的segment file都fsync到磁盘上
translog就存储了上一次flush（commit point）直到现在最近的数据的变更记录。
此时就会将trangslog文件中的变更记录回放，重新执行之前的各种操作在，写入到buffer中，再重新刷一个一个的segment到os cache中，等待下一次commit发生即可。
