0x00 概述

elasticsearch中有兩個比較重要的操作：refresh 和 flush，兩個操作都涉及到資料操作和磁碟效能。

0x01 refresh操作

當我們向ES傳送請求的時候，我們發現es貌似可以在我們發請求的同時進行搜尋。而這個實時建索引並可以被搜尋的過程實際上是一次es 索引提交（commit）的過程，如果這個提交的過程直接將資料寫入磁碟（fsync）必然會影響效能，所以es中設計了一種機制，即：先將index-buffer中文件（document）解析完成的segment寫到filesystem cache之中，這樣避免了比較損耗效能io操作，又可以使document可以被搜尋。以上從index-buffer中取資料到filesystem cache中的過程叫做refresh。

#
 
 refresh操作可以通過API設定：
POST /index/_settings
{“refresh_interval”: “10s”}

# 當我們進行大規模的建立索引操作的時候，最好將將refresh關閉。
POST /index/_settings
{“refresh_interval”: “-1″}

es預設的refresh間隔時間是1s，這也是為什麼ES可以進行近乎實時的搜尋。

0x02 flush操作與translog

我們可能已經意識到如果資料在filesystemcache之中是很有可能在意外的故障中丟失。這個時候就需要一種機制，可以將對es的操作記錄下來，來確保當出現故障的時候，保留在filesystem的資料不會丟失，並在重啟的時候可以從這個記錄中將資料恢復過來。elasticsearch提供了translog來記錄這些操作。 當向elasticsearch傳送建立document索引請求的時候，document資料會先進入到indexbuffer之後，與此同時會將操作記錄在translog之中，當發生refresh時（資料從index buffer中進入filesystem cache的過程）translog中的操作記錄並不會被清除，而是當資料從filesystem cache中被寫入磁碟之後才會將translog中清空。而從filesystem cache寫入磁碟的過程就是flush。可能有點暈，我畫了一個圖幫大家理解這個過程：

總結一下translog的功能：

1.保證在filesystemcache中的資料不會因為elasticsearch重啟或是發生意外故障的時候丟失。 2.當系統重啟時會從translog中恢復之前記錄的操作。 3.當對elasticsearch進行CRUD操作的時候，會先到translog之中進行查詢，因為tranlog之中儲存的是最新的資料。 4.translog的清除時間時進行flush操作之後（將資料從filesystem cache刷入disk之中）。

再總結一下flush操作的時間點：

1.es的各個shard會每個30分鐘進行一次flush操作。 2.當translog的資料達到某個上限的時候會進行一次flush操作。

有關於translog和flush的一些配置項：

index.translog.flush_threshold_ops:當發生多少次操作時進行一次flush。預設是 unlimited。 index.translog.flush_threshold_size:當translog的大小達到此值時會進行一次flush操作。預設是512mb。 index.translog.flush_threshold_period:在指定的時間間隔內如果沒有進行flush操作，會進行一次強制flush操作。預設是30m。 index.translog.interval:多少時間間隔內會檢查一次translog，來進行一次flush操作。es會隨機的在這個值到這個值的2倍大小之間進行一次操作，預設是5s。