上节我们完成了如下的内容：
众所周知，Elasticsearch存储的基本单元是Shard，ES中的一个Index可能分为多个Shard，事实上每个Shard都是一个Lucence的Index，并且每个LucenceIndex由多个Segment组成，每个Segment事实上是一些倒排索引的集合，每次创建一个新的Document，都会归属于一个新的Segment，而不会去修改原来的Segment。且每次的文档删除操作，会仅仅标记Segment中该文档为删除状态，而不会真正的立马物理删除，所以说ES的index可以理解为一个抽象的概念。就像下图所示：
Write Ahead Log 预写入日志
新文档被索引意味着文档会被首先写入内存buffer和translog文件，每个shard都对应一个translog文件
在Elasticsearch中，_refresh操作默认每秒执行一次，意味着将内存buffer的数据写入到一个新的Segment中，这个时候索引变成了可检索的，写入新Segment后会清空内存buffer。
Flush 操作意味着将内存buffer的数据全部写入到新的Segment中，并将内存中所有Segments全部刷盘，并且清空translog日志的过程。
Elasticsearch写入流程，当一个写请求到达Elasticsearch后，ES将数据写入MemoryBuffer中，并添加事务日志（translog）。如果每次一条数据写入内存后立即写到硬盘上，由于写入的数据肯定是离散的，因此写入磁盘的操作也就是随机写入了。硬盘随机写入的效率相当低，会严重降低ES的性能。
因此ES在设计时在MemoryBuffer和硬盘之间加入了高速缓存（FileSystemCache）来提高ES的写效率。
当写请求发送到ES后，ES将数据写入MemoryBuffer中，此时写入的数据还不能查询到。默认设置下，ES每1秒钟将MemoryBuffer中的数据Refresh到Linux的FileSystemCache，并清空MemoryBuffer，此时写入的数据就可以被查询到了。
在Elasticsearch中，写入和打开一个新段的轻量的过程叫做Refresh，默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说Elasticsearch是“近”实时搜索：文档的变化并不是立即对搜索可见，但会在一秒之内变成可见。
这些行为可能会对新用户操作困惑，他们索引了一个文档然后尝试搜索它，但却没有搜索到。这个问题的解决方法是用 Refresh API 执行一次手动刷新：
POST /_refresh
POST /my_blogs/_refresh
POST /my_blogs/_doc/1?refresh
{"xxx": "xxx"}
PUT /test/_doc/2?refresh=true
{"xxx": "xxx"}
并不是所有的情况都需要每秒刷新，可能你正在使用Elasticsearch索引大量的文件，你可能想优化索引速度而不是近实时搜索，可以通过设置 refrsh_interval，降低每个索引的刷新频率。
PUT /my_logs
{
"settings": {
"refresh_interval": "30s"
}
}
refresh_interval可以在既存索引上动态更新，在生产环境中，当你正在建立一个大的索引时，可以先关比自动刷新，待开始使用该索引时，再把他们调回来。
PUT /my_logs/_settings
{
"refresh_interval": -1
}
PUT /my_logs/_settings
{
"refresh_interval": "1s"
}
持久化变更flush
即使通过每秒刷新（Refresh）实现了近实时搜索，仍然要经常进行完整提交来确保从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢掉这些数据。
Elasticsearch增加了一个Translog，叫做事务日志，在每一次对Elasticsearch操作时都会进行日志记录，通过translog，整个流程是下面这个样子：
第一步：一个文档被索引之后，就会被添加到内存缓冲区中，并且追加到了translog，如下图描述一样：
新的文档被添加到内存缓冲区并且追加到了事务日志：
刷新（refresh）完成后，缓存被清空但是事务日志不会。
translog提供所有还没有被刷到磁盘的操作的一个持久化记录，当Elasticsearch启动的时候，它会从磁盘中使用最后一个提交点去恢复已经得段，并且会重放translog中所有在最后一次提交后发生的变更操作。
translog也被用来提供实时CRUD，当你试着通过ID查询、解析、删除一个文档，它会在尝试从相应的段中检索之前，首先检查translog任何最近的变更。这意味着它总是能够实时的获取到文档的最新版本。在刷新（flush）之后，段被全量提交，并且事务日志被清空。
这个执行一个提交并且截断translog的行为在Elasticsearch被称作一次flush，分片每30分钟被自动刷新（flush），或者在translog太大（512M）的时候也会刷新。
flush API可以被用来执行一个手工的刷新（flush）：
POST /blogs/_flush
POST /_flush?wait_for_ongoin
这就是说，在重启节点或者关闭之前执行flush有益于你的索引，当Elasticsearch尝试恢复或重新打开一个索引的时候，它需要重放translog中所有的操作，所以如果日志越短，恢复的会越快。
Translog有多安全？
Translog的目的是保证操作不会丢失，但是却引出了对应的问题：
在文件被fsync到磁盘前，被写入的文件在重启之后就会丢失。这个过程在主分片和复制分片都会发生。最终，基本上，这意味着在整个请求被fsync到主分片和复制分片的translog之前，你的客户端不会得到一个200的OK响应，在每次写请求后执行一个fsync会带来性能上的损失，尽管实践表明这个损失并不大（特别是bluk导入，在一次请求时平摊了大量的文档开销）
但是对于一些大容量的偶尔丢失几秒数据问题并不眼中的集群，使用异步的fsync还是比较有益的。比如，写入的数据被缓存到内存中，再每5秒执行一次fsync。
这个行为可以通过设置durability参数为async来启动。
PUT /my_index/x_settings
{
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}
这个选项可以针对索引单独设置，并且可以动态修改，如果你决定使用异步translog的话，你需要保证在发生crash时，丢失掉sync_interval时间段的数据也无所谓。请在决定前知晓这个特性。
如果你不确定这个行为的后果，最好使用默认参数：“index.translog.durability”: “request” 来避免数据丢失。