本节书摘来自华章计算机《深入理解ElasticSearch》一书中的第3章，第3.4节,作者：[美] 拉斐尔·酷奇（Rafa Ku）　马雷克·罗戈任斯基（Marek Rogoziński）更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.4　准实时、提交、更新及事务日志

一个理想的搜索解决方案中，新索引的数据应该能立即搜索到。ElasticSearch给人的第一印象仿佛就是如此工作的，即使是在多服务器环境下，然而事实并非如此（至少不是任何场景都能保证新索引的数据能被实时检索到），原因我们后面会讲解。接下来的案例中，我们将使用下面的命令将一篇文档索引到新创建的索引中：

现在，更新该文档，并尝试立即搜索它。为实现该目的，我们将串行执行下面的两个命令：

前面的命令将返回类似下面的结果：

第一个返回结果对应索引命令的操作，正如你所见，一切正常。第二个返回结果是查询对应的结果，其中title字段的值应该是test2，然而返回的却是修改前的那个文档，这是怎么回事？
关于上面这个问题，在给出答案之前，不妨去回顾一下Lucene的内部机制，探究一下Lucene是如何让新索引的文档在搜索时可用的。
3.4.1　索引更新及更新提交
在阅读1.1节时我们已经知道，在索引期新文档会写入索引段。索引段是独立的Lucene索引，这意味着查询是可以与索引并行的，只是不时会有新增的索引段被添加到可被搜索的索引段集合之中。Apache Lucene通过创建后续的（基于索引只写一次的特性）segments_N文件来实现此功能，且该文件列举了索引中的索引段。这个过程称为提交（committing），Lucene以一种安全的方式来执行该操作，能确保索引更改以原子操作方式写入索引，即便有错误发生，也能保证索引数据的一致性。
让我们回到之前的例子，尽管第一个操作向索引中添加了文档，但它并没有执行提交commit操作，这就是返回结果令人惊讶的原因。然而，一次提交并不足以保证新索引的数据能被搜索到，这是因为Lucene使用了一个叫作Searcher的抽象类来执行索引的读取。如果索引更新提交了，但Searcher实例并没有重新打开，那么它觉察不到新索引段的加入。Searcher重新打开的过程叫作刷新（refresh）。出于性能考虑，Lucene推迟了耗时的刷新，因此它不会在每次新增一个文档（或批量增加文档）的时候刷新，但Searcher会每秒刷新一次。这种刷新已经非常频繁了，然而有很多应用却需要更快的刷新频率。如果碰到这种状况，要么使用其他技术，要么审视需求是否合理。ElasticSearch提供了强制刷新的API。例如，在例子中可以使用下面的命令：

如果在搜索前执行该命令，就会得到我们预期的结果。
更改默认的刷新时间
Searcher自动刷新的时间间隔可以通过以下手段改变：更改ElasticSearch配置文件中的index.refresh_interval参数值或者使用配置更新相关的API。例如：

上面的命令将Searcher的自动刷新时间间隔更改为5分钟。请注意，上次刷新后的新增数据并不会被搜索到。
刷新操作是很耗资源的，因此刷新间隔时间越长，索引速度越快。如果需要长时间高速建索引，并且在建索引结束之前暂不执行查询，那么可以考虑将index.refresh_interval参数值设置为-1，然后在建索引结束以后再将该参数恢复为初始值。
3.4.2　事务日志
Apache Lucene能保证索引的一致性，这非常棒，但是这并不能保证当往索引中写数据失败时不会损失数据（如磁盘空间不足、设备损坏，或没有足够的文件句柄供索引文件使用）。另外，频繁提交操作会导致严重的性能问题（因为每提交一次就会触发一个索引段的创建操作，同时也可能触发索引段的合并）。ElasticSearch通过使用事务日志（transaction log）来解决这些问题，它能保存所有的未提交的事务，而ElasticSearch会不时创建一个新的日志文件用于记录每个事务的后续操作。当有错误发生时，就会检查事务日志，必要时会再次执行某些操作，以确保没有丢失任何更改信息。而且，事务日志的相关操作都是自动完成的，用户并不会意识到某个特定时刻触发的更新提交。事务日志中的信息与存储介质之间的同步（同时清空事务日志）称为事务日志刷新（flushing）。
请注意事务日志刷新与Searcher刷新的区别。大多数情况下，Searcher刷新是你所期望的，即搜索到最新的文档。而事务日志刷新用来确保数据正确写入了索引并清空了事务日志。
除了自动的事务日志刷新以外，也可以使用对应的API。例如，可以使用下面的命令，强制将事务日志中涉及的所有数据更改操作同步到索引中，并清空事务日志文件：

我们也可以使用flush命令对特定的索引进行事务日志刷新（如library索引）：

上面第二行命令中，我们紧接着在事务日志刷新之后，调用Searcher刷新操作，打开一个新的Searcher实例。
事务日志相关配置
如果事务日志的默认配置不能满足用户需要，ElasticSearch还支持默认配置修改功能以满足特定需求。以下参数既可以通过修改elasticsearch.yml文件来配置，也可以通过索引配置更新API来更改。

• index.translog.flush_threshold_period：该参数的默认值为30分钟，它控制了强制自动事务日志刷新的时间间隔，即便是没有新数据写入。强制进行事务日志刷新通常会导致大量的I/O操作，因此当事务日志涉及少量数据时，才更适合进行这项操作。
• index.translog.flush_threshold_ops：该参数确定了一个最大操作数，即在上次事务日志刷新以后，当索引更改操作次数超过该参数值时，强制进行事务日志刷新操作，默认值为5000。
• index.translog.flush_threshold_size：该参数确定了事务日志的最大容量，当容量大于等于该参数值，就强制进行事务日志刷新操作，默认值为200MB。
• index.translog.disable_flush:禁用事务日志刷新。尽管默认情况下事务日志刷新是可用的，但对它临时性地禁用能带来其他方面的便利。例如，向索引中导入大量文档的时候。

尽管前面提及的所有参数都被指定用于用户选定的某个索引，但它们同时也定义了该索引各个分片的事务日志处理方式。
当然，除了通过修改elasticsearch.yml文件来配置上述参数，我们也可以使用设置更新API来更改相关配置。例如：

前述命令会在向索引导入大量数据之前执行，大幅提高索引的速度。但是请记住，当数据导入完毕之后，要重新设置事务日志刷新相关参数。
3.4.3　准实时读取
事务日志给我们带来一个免费的特性：实时读取（real-time GET），该功能让返回文档各种版本（包括未提交版本）成为可能。实时读取操作从索引中读取数据时，会先检查事务日志中是否有可用的新版本。如果近期索引没有与事务日志同步，那么索引中的数据将会被忽略，事务日志中最新版本的文档将会被返回。为了演示实时读取的工作原理，我们用下面的命令替换范例中的搜索操作：

ElasticSearch将返回类似下面的结果：

如代码所示，这正是我们想要的结果，而且这里并没有使用Searcher刷新技巧就得到了最新版本的文档。