先放一張整體圖，有一個總體、清晰的瞭解。
elasticsearch shard的refresh發生在從下面的圖一到圖二的過程中：
圖一：
圖二：
commit point本身是一個磁盤文件，包含了已經fsync到磁盤上的segments。in-memory buffer是內存的一塊區域，用於存儲上一次refresh後，下一次refresh之前的新增加（更新也是新增）的document記錄生成的inverted index。translog類似於oracle中的redo，記錄操作以便重放、以及根據id實時檢索最新的document記錄。不在本次講解範圍內，先略去不管。
在圖一，新增加（更新也是新增）的document記錄生成的inverted的索引，會首先存儲在內存中的in-memory buffer中，然後在默認情況下，會每隔1s（index.refresh_interval）fresh一次，生成新的segment。然後此segment會被打開（只爲描述fresh，此處忽略磁盤flush的問題）打開後，就可以被文檔檢索請求檢索到對應的更新記錄。在segment被打開之前，記錄在其上的記錄，是檢索不到的。如上面圖2。以上就是fresh的的邏輯。下面說一下fresh相關的參數：
index.search.idle.after：索引的動態參數。一個分片在多久沒有接收search、get請求後，可以被視爲是idle空閒的。默認值是30s。
index.refresh_interval：索引的動態參數。設置分片兩次refresh的間隔。設置爲-1可以禁用refresh。如果沒有顯示設置的話，當一個分片變爲idle之後，再次接收到search/get請求時，請求會等待直到下一次默認refresh後，讀取數據返回。這是對於bulk批量索引的優化，加速批量索引處理。顯式設置一個值，可以打破這個邏輯。
在索引document的時候，可以攜帶在url中攜帶refresh參數。例如：
POST test_index/_doc?refresh
?refresh可以跟下面幾種參數：
1，空值或者true：例如POST test_index/_doc?refresh=true或者POST test_index/_doc?refresh 。表示立即refresh 結果。以在當前請求結果中能反映本次更新的記錄。會降低性能。
2，wait_for：例如：POST test_index/_doc?refresh=wait_for 。請求會等待，直到後臺refresh後才返回。
3，false：默認值，等同於不加?refresh url參數。例如：POST test_index/_doc?refresh=false 或者POST test_index/_doc 請求處理成功後返回，依賴es默認refresh機制。
在實際操作當中，根據實際需要設置index.search.idle.after、index.refresh_interval 配置參數，以及refresh請求參數，靈活滿足業務需求同時提升操作性能。