Elasticsearch调优经历

默认情况下ElasticSearch索引的refresh_interval为1秒，这意味着数据写1秒才就可以被搜索到。

每次索引refresh会产生一个新的 lucene 段，这会导致频繁的 segment merge 行为，对系统 CPU 和 IO 占用都比较高。

如果产品对于实时性要求不高，则可以降低刷新周期，如：index.refresh_interval: 120s。

但是这种特性对于功能测试来说比较麻烦：

因为实时性不能保证，所以每次插入测试数据之后，都需要sleep一段时间，才能进行测试。
因为实时性不能保证，及时通过sleep策略通过的case，也可能偶尔失败。
为了解决上述问题，需要提供ElasticSearch增删改数据之后数据立即刷新的策略。
可知有以下三种刷新策略：

RefreshPolicy#IMMEDIATE:
请求向ElasticSearch提交了数据，立即进行数据刷新，然后再结束请求。
优点：实时性高、操作延时短。
缺点：资源消耗高。
RefreshPolicy#WAIT_UNTIL:
请求向ElasticSearch提交了数据，等待数据完成刷新，然后再结束请求。
优点：实时性高、操作延时长。
缺点：资源消耗低。
RefreshPolicy#NONE:
默认策略。
请求向ElasticSearch提交了数据，不关系数据是否已经完成刷新，直接结束请求。
优点：操作延时短、资源消耗低。
缺点：实时性低
updateRequest.setRefreshPolicy(WriteRequest.RefreshPolicy.WAIT_UNTIL);
每笔500ms以上，特别影响性能。尽量不要使用