我对elasticsearch translog flush的理解和疑惑（看完网上的分析后感觉不严谨）

网上有的文章介绍过refresh 和 translog的区别，大致就是说refresh是把数据从内存写到系统缓存的过程，这样能确保数据在系统缓存中被检索到；flush把系统缓存提交到磁盘，然后清空translog。
 
然而我今天自己测试了一下发现 flush不仅仅能够做到数据持久化防丢失，同时也实现了refresh的功能，保证数据可以被检索到。
而且通过测试结果还发现官网描述的一个前后矛盾的现象，想向大家求教。
 
先说我的测试方法：
 
设置index.refresh_interval 为-1，然后修改一个文档，此时get请求时能看到更新，然后立马search 结果是看不到更新的。refresh后search能够看到了，这印证了第一个说法。

然后我又一次更新了文档，这个时候立马调用flush，发现search也能搜索到了。
 
那么网友们说的预期的结果应该是依然搜不到更新，因为flush仅仅是把系统缓存的数据写到磁盘而已，怎么会把内存buffer的数据同时同步到系统缓存了呢？这不应该是refresh做的事情吗？
 
于是我看了下官方文档。
 官方文档上大概是这样说的：每个写请求都会先写到内存一份数据，然后写translog，这个数据再没有refresh之前是不可见得（除非get请求从translog里面拿），调用refresh后lucene将他从内存写到文件系统缓存，此时就可以被检索到。flush是数据从文件系统缓存到磁盘的过程，重点：
1.Any docs in the in-memory buffer are written to a new segment.
2.The buffer is cleared.
3.A commit point is written to disk.
4.The filesystem cache is flushed with an fsync.
5.The old translog is deleted.
 
第一句话，内存中的文档会被写到心的段，然后后面新的段也就随着commit point提交到磁盘，所以就能被search了。
 
然后官网还有一个flush 配置的描述：durability  这个参数是控制flush策略的，默认是request 就是每个写请求都会触发一个flush。async则是按周期。我看了下2.2的源码，确实是这样。

那么我的问题就是，默认情况下 translog durability 是request，就是每个写请求都会触发flush，这样就和我实验的结果不一致了，也就是说每次index 或者 update 都应该能被search到变化，设置 refresh_interval 在默认的flush策略前应该没有作用才对。  向大佬们求教这个问题