ElasticSearch是一个分布式可扩展的近实时（NRT）搜索和分析引擎，这意味着文档从索引到可以被检索会有很小的延迟，默认延迟为1秒。
为什么默认会有1秒的延迟，这要从Elasticsearch底层实现说起。大家知道Elasticsearch底层是基于Lucene索引的，当有新文档要写入到索引中时(对已经存在于索引中的文档进行更新、删除等操作和写入操作过程相同)，首先Elasticsearch会找到写入索引具体对应的分片(shard)，文档经过一些处理，写入分片的内存缓存区。内存缓存区中的文档持久化到磁盘，要经历下面两个阶段。
1、索引刷新（refresh）
索引刷新是指将分片内存缓存区的数据生成segment保存到文件系统缓存中的操作。分片内存缓存区中的数据是不能被检索到的。Elasticsearch采用定时refresh的方式，定时将内存缓存区中的数据保存到文件系统缓存。Refresh操作的时间隔默认是1秒，可以通过refresh_interval参数批量指定，也可以对单个索引指定refresh时间间隔。Refresh操作会将内存缓存区的中数据，先生成一个Lucene的Segment，然后刷新到文件系统缓存中。文件系统缓存中保存的是segment。
图1 REFRESH过程
Refresh操作对应的接口为_refresh，调用接口可以立即将索引所有分片内存缓存区中的文档生成segment刷新到文件系统缓存，以便可以检索最新索引的文档。
例如：POST twitter/_refresh
2、索引持久化（flush）
文件系统缓存中segment最终写入磁盘，还需要Elasticsearch执行flush操作。flush操作默认执行时间间隔为30分钟，或者translog增长到512mb。flush操作对应Lucene的commit操作。
图2 FLUSH过程
Elasticserch调用flush操作的接口是_flush，调用flush接口可以立即将文件系统缓存的segment合并后写入磁盘。
例如：POST twitter/_flush
索引的segment在被flush到磁盘之前，一直存放在内存当中，如果在此期间机器发生宕机，内存中这部分数据就有丢失的风险。Elasticsearch采用了translog机制保障这部分内存数据的安全。
当索引在接收文档的写入、更新和删除操作时，写入分片内存缓冲区的同时，会在磁盘写一份translog日志，只有translog日志写入成功，本次操作才算成功。
Translog会记录下对索引的所有更新操作，一旦缓存中的数据在意外故障中丢失，服务恢复时，这些记录可以将数据恢复。分片的refresh操作时，translog中的操作记录不会被清除，当数据从文件系统缓存中写入磁盘后才会将translog清空。Translog的生命周期如下图：
图3 Translog生命周期
关于translog和flush的一些配置项：
index.translog.flush_threshold_size：当translog大小增长到此值时会进行一次flush操作。默认是512mb。
index.translog.flush_threshold_period：指定flush操作的时间间隔。默认是30分钟。
分析到这，大家应该已经明白，Elasticsearch检索的延迟，就是分片内存缓存区refresh到文件系统缓存的时间间隔。
可能大家会有这样的想法，如果把索引refresh_interval设置为1毫秒，Elasticsearch索引的文档是不是可以实时检索到了。理论上是这样，真实应用场景中是行不通的。首先分片内存缓存区Refresh是非常昂贵的操作，提升索引吞吐量的方式之一就是增大refresh_interval；其次refresh操作对应生成一个Lucene的Segment，当索引的refresh_interval很小时，索引文档时生成大量的segment，会影响索引检索性能。原因是Lucene为每个Segment在thread local里记录状态信息，这块堆内存的开销和segment数量*检索线程数量有关。
当然，Elasticsearch也提供实时（Realtime）检查的接口（GET API）。接口内部实现的原理是，在检索数据之前，先执行refresh操作。为了集群的性能考虑，我们在进行实时检索时，要慎重！
参考链接：
https://www.elastic.co/guide/en/elasticsearch/reference/5.0/index.html
http://www.cnblogs.com/smile361/p/7483561.html
