Flushing of Tansaction log
translog帮助防止节点失败时的数据丢失。它的设计目的是帮助shard恢复操作，否则数据可能会从内存flush到磁盘时发生意外而丢失。日志每5秒被提交到磁盘上，或者在每个成功的索引、删除、更新或批量请求时提交。
为了防止数据丢失，每个shard都有一个事务日志或与之关联的写入日志。任何索引或删除操作在内部Lucene索引处理后被写入到translog中。在崩溃的情况下，当shard恢复时，可以从事务日志中重新重放最近的事务。
ES的flush是执行Lucene提交并产生新的translog的过程。它是在后台自动完成的，以确保事务日志不会太大，这将使在恢复期间重放其操作花费大量时间。它也通过API来操作。
与刷新索引shard相比，真正昂贵的操作是刷新其事务日志(涉及Lucene提交)。通过延迟刷新或完全禁用它们，可以提高索引吞吐量。但是这种做法有利有弊，延迟的flush当然会花费更长的时间。
基本参数
index.translog.flush_threshold_size - translog按size大小flush，默认为521M。
我们可以增加index.translog.flush_threshold_size从默认的512M到更大的值，比如1gb。这允许在发生刷新之前在translog中积累更大的segment。通过让更大的segment构建，可以减少刷新的频率，而更大的segement合并的频率也更低。所有这些都减少了磁盘I/O开销，提高了索引吞吐量。当然，将需要相应的heap空闲内存来提供额外缓冲空间，调整时此设置时请记住这一点。
index.translog.flush_threshold_ops - 多少任务来执行操作，默认为ulimited
index.translog.flush_threshold_period - 在触发刷新之前，不管事务日志大小，需要等待多长时间。默认为30m
index.translog.sync_interval - 多久检测是否需要flush。默认为5s
index.translog.durability - sync方式。默认为fsync，可选为async。2者区别，fsync每次操作都会commit到translog。async按设置的sync_interval时间定期commit到translog。 fsync更耗费资源，但可靠性好，async模式下，如果sync_interval间隔时间内发生问题，中间没有commit的操作会全部丢失
最佳实践
如没有其他特殊需求。可以使用一下参数来配置
index.translog.flush_threshold_size: "1gb"
index.translog.sync_interval: "60s"
index.translog.durability: "async"
