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，這種情況緩存中的translog在flush之後會被清空。
3、默認5s，會強制對translog進行flush。最小值可配置100ms。
6.3版本顯示保留translog文件的最長持續時間。默認爲12h。
總結
translog是保證es數據安全的關鍵所在，增加flush的頻率可以減少數據丟失的風險，但是所帶來的是非常大的性能開銷，所以生產上要根據具體的業務需求來進行配置的優化。對實時要求不高的場景，可以考慮增加refresh的時間間隔，這會很有效的提升性能。
——————————————————————————————————
作者：桃花惜春風
轉載請標明出處，原文地址：
https://blog.csdn.net/xiaoyu_BD/article/details/81735473
如果感覺本文對您有幫助，請留下您的贊，您的支持是我堅持寫作最大的動力，謝謝！