因为ES的近时效性，所以insert或update es的数据的时候短时间可能查询不到（1s左右）
在es中新增的document会被收集到indexing buffer区后被重写成一个segment然后直接写入filesystem cache中，这个操作是非常轻量级的，相对耗时较少，之后经过一定的间隔或外部触发后才会被flush到磁盘上，这个操作非常耗时。但只要sengment文件被写入cache后，这个sengment就可以打开和查询，从而确保在短时间内就可以搜到，而不用执行一个full commit也就是fsync操作，这是一个非常轻量级的处理方式而且是可以高频次的被执行，而不会破坏es的性能。
在elasticsearch里面，这个轻量级的写入和打开一个cache中的segment的操作叫做refresh，默认情况下，es集群中的每个shard会每隔1秒自动refresh一次，这就是我们为什么说es是近实时的搜索引擎而不是实时的，也就是说给索引插入一条数据后，我们需要等待1秒才能被搜到这条数据，这是es对写入和查询一个平衡的设置方式，这样设置既提升了es的索引写入效率同时也使得es能够近实时检索数据。
refresh操作相比commit操作是非常轻量级的但是它仍然会耗费一定的性能，所以不建议在每插入一条数据后就执行一次refresh命令，如果我们有比较强的查询需求，我们可以采用其他办法来解决
通过Redis来缓解（我们只是为了解决es延迟，并不是为了提供查询速度）
1、数据insert或update到es时,把数据先放到Redis里面TTL设置3s
2、查询数据的时候先拉redis，如果redis没有在查询es
为什么设置TTL为3s：
1、因为es的延迟理论上最多3s
2、没有解决缓存一致性问题
对比Redis做MySQL缓存
Redis作为MySQL的缓存时，因为需要保证缓存和DB的一直性需要延迟双删TTL一般8h
延迟双删：
1、删除redis缓存
2、update MySQL db
3、sleep 1s 后在删除redis缓存
Redis作为ES缓存，是为了解决ES查询延迟的问题，在并发情况喜爱的缓存一致性问题并没有解决，但是我们也可以用redis的分布式缓存解决缓存一直性的问题，但是TTL还是会设置3s，是因为设置之初，只是解决延迟问题，es查询没有问题
