elasticsearch的核心优势就是近乎实时，为什么说是近乎实时而非真实意义上的实时呢，因为elasticsearch能够做到准实时，而并不是完全的实时。下面介绍elasticsearch是如何索引数据的整个流程。
先上图：
首先，当我们对记录进行修改时，es会把数据同时写到内存缓存区和translog中。而这个时候数据是不能被搜索到的，只有数据形成了segmentFile，才会被搜索到。默认情况下,es每隔一秒钟执行一次refresh，可以通过参数index.refresh_interval来修改这个刷新间隔，执行refresh主要做三件事：
1、所有在内存缓冲区中的文档被写入到一个新的segment中,但是没有调用fsync,因此内存中的数据可能丢失
2、segment被打开使得里面的文档能够被搜索到
3、清空内存缓冲区
从上面可以看出，内存缓存中的数据，每一秒会生成一个新的segment，一分钟就会生成60哥segments。只有在生成segment之后，才会被索引到，所以这里说并非realtime，而是near-realtime。
translog的相当于事务日志，记录着所有对elasticsearch的操作记录，也是对elasticsearch的一种备份。因为并不是写到segment就表示数据落到磁盘了，实际上segment是存储在系统缓存（page cache）中的，只有达到一个周期或者数据量达到一定值，才会flush到磁盘上。这个时候如果系统内存中的segment丢失，是可以通过translog来恢复的。这个flush过程主要做了三件事：
1、往磁盘里写入commit point信息。
2、文件系统中的segment，fsync到磁盘。
3、清空translog文件。
translog可以保证缓存中的segment的恢复，但translog也不是实时也磁盘的，也就是说，内存中的translog丢了的话，也会有丢失数据的可能。所以translog也要进行flush。translog的flush主要有三个条件：
1、可以设置是否在某些操作之后进行强制flush，比如索引的删除或批量请求之后。
2、translog大小超过512mb，会强制segment进行flush，随后会强制对translog进行flush。
3、默认5s，会强制对translog进行flush。最小值可配置100ms。
6.3版本显示保留translog文件的最长持续时间。默认为12h。
总结
translog是保证es数据安全的关键所在，增加flush的频率可以减少数据丢失的风险，但是所带来的是非常大的性能开销，所以生产上要根据具体的业务需求来进行配置的优化。对实时要求不高的长久，可以考虑增加refresh的时间间隔，这会很有效的提升性能。
——————————————————————————————————
作者：桃花惜春风
转载请标明出处，原文地址：
https://blog.csdn.net/xiaoyu_BD/article/details/81735473
如果感觉本文对您有帮助，请留下您的赞，您的支持是我坚持写作最大的动力，谢谢！