'Elasticsearch原理：實時架構'

ElasticSearch 是一個分佈式、高擴展、高實時的搜索與數據分析引擎。它能很方便的使大量數據具有搜索、分析和探索的能力。充分利用ElasticSearch的水平伸縮性，能使數據在生產環境變得更有價值。ElasticSearch 的實現原理主要分為以下幾個步驟，首先用戶將數據提交到Elastic Search 數據庫中，再通過分詞控制器去將對應的語句分詞，將其權重和分詞結果一併存入數據，當用戶搜索數據時候，再根據權重將結果排名，打分，再將返回結果呈現給用戶。

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。

參考官網：https://www.elastic.co/guide/en/elasticsearch/reference/6.3/index-modules-translog.html#_translog_settings

總結

translog是保證es數據安全的關鍵所在，增加flush的頻率可以減少數據丟失的風險，但是所帶來的是非常大的性能開銷，所以生產上要根據具體的業務需求來進行配置的優化。對實時要求不高的長久，可以考慮增加refresh的時間間隔，這會很有效的提升性能。

後續文檔將發佈如何部署單實例和分佈式ES集群，請關注，謝謝。