摘要：因為倒排索引打分機制全文檢索原理分詞原理等等，這些都是不會過時的技術(shù)。中，單個倒排索引文件稱為。其中有一個文件，記錄了所有的信息，稱為文檔新寫入時，會生成新的。過程上個過程中在文件系統(tǒng)緩存中，會有意外故障文檔丟失。寫入次怕后，清空。

前言

最近 TL 分享了下 《Elasticsearch基礎整理》，蹭著這個機會。寫個小文鞏固下，本文主要講 ES -> Lucene
的底層結(jié)構(gòu)，然后詳細描述新數(shù)據(jù)寫入 ES 和 Lucene 的流程和原理。這是基礎理論知識，整理了一下，希望能對 Elasticsearch 感興趣的同學有所幫助。

什么是 Elasticsearch ？
Elasticsearch 是一個基于 Apache Lucene(TM) 的開源搜索引擎。

那 Lucene 是什么？
無論在開源還是專有領域，Lucene 可以被認為是迄今為止最先進、性能最好的、功能最全的搜索引擎庫，并通過簡單的 RESTful API 來隱藏 Lucene 的復雜性，從而讓全文搜索變得簡單。

Elasticsearch 不僅僅是 Lucene 和全文搜索，我們還能這樣去描述它：

分布式的實時文件存儲，每個字段都被索引并可被搜索

分布式的實時分析搜索引擎

可以擴展到上百臺服務器，處理 PB 級結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)

就像很多業(yè)務系統(tǒng)是基于 Spring 實現(xiàn)一樣，Elasticsearch 和 Lucene 的關(guān)系很簡單：Elasticsearch 是基于 Lucene 實現(xiàn)的。ES 基于底層這些包，然后進行了擴展，提供了更多的更豐富的查詢語句，并且通過 RESTful API 可以更方便地與底層交互。類似 ES 還有 Solr 也是基于 Lucene 實現(xiàn)的。

在應用開發(fā)中，用 Elasticsearch 會很簡單。但是如果你直接用 Lucene，會有大量的集成工作。

因此，入門 ES 的同學，稍微了解下 Lucene 即可。如果往高級走，還是需要學習 Lucene 底層的原理。因為倒排索引、打分機制、全文檢索原理、分詞原理等等，這些都是不會過時的技術(shù)。

如圖

一個 ES Index （索引，比如商品搜索索引、訂單搜索索引）集群下，有多個 Node （節(jié)點）組成。每個節(jié)點就是 ES 的實例。

每個節(jié)點上會有多個 shard （分片）， P1 P2 是主分片 R1 R2 是副本分片

每個分片上對應著就是一個 Lucene Index（底層索引文件）

Lucene Index 是一個統(tǒng)稱。由多個 Segment （段文件，就是倒排索引）組成。每個段文件存儲著就是 Doc 文檔。

lucene 中，單個倒排索引文件稱為 segment。其中有一個文件，記錄了所有 segments 的信息，稱為 commit point：

文檔 create 新寫入時，會生成新的 segment。同樣會記錄到 commit point 里面

文檔查詢，會查詢所有的 segments

當一個段存在文檔被刪除，會維護該信息在 .liv 文件里面

新文檔創(chuàng)建或者更新時，進行如下流程：

更新不會修改原來的 segment，更新和創(chuàng)建操作都會生成新的一個 segment。數(shù)據(jù)哪里來呢？先會存在內(nèi)存的 bugger 中，然后持久化到 segment 。

數(shù)據(jù)持久化步驟如下：write -> refresh -> flush -> merge

一個新文檔過來，會存儲在 in-memory buffer 內(nèi)存緩存區(qū)中，順便會記錄 Translog。

這時候數(shù)據(jù)還沒到 segment ，是搜不到這個新文檔的。數(shù)據(jù)只有被 refresh 后，才可以被搜索到。那么 講下 refresh 過程

refresh 默認 1 秒鐘，執(zhí)行一次上圖流程。ES 是支持修改這個值的，通過 index.refresh_interval 設置 refresh （沖刷）間隔時間。refresh 流程大致如下：

in-memory buffer 中的文檔寫入到新的 segment 中，但 segment 是存儲在文件系統(tǒng)的緩存中。此時文檔可以被搜索到

最后清空 in-memory buffer。注意: Translog 沒有被清空，為了將 segment 數(shù)據(jù)寫到磁盤

文檔經(jīng)過 refresh 后， segment 暫時寫到文件系統(tǒng)緩存，這樣避免了性能 IO 操作，又可以使文檔搜索到。refresh 默認 1 秒執(zhí)行一次，性能損耗太大。一般建議稍微延長這個 refresh 時間間隔，比如 5 s。因此，ES 其實就是準實時，達不到真正的實時。

上個過程中 segment 在文件系統(tǒng)緩存中，會有意外故障文檔丟失。那么，為了保證文檔不會丟失，需要將文檔寫入磁盤。那么文檔從文件緩存寫入磁盤的過程就是 flush。寫入次怕后，清空 translog。

translog 作用很大：

保證文件緩存中的文檔不丟失

系統(tǒng)重啟時，從 translog 中恢復

新的 segment 收錄到 commit point 中

具體可以看官方文檔：https://www.elastic.co/guide/...

上面幾個步驟，可見 segment 會越來越多，那么搜索會越來越慢？怎么處理呢？

通過 merge 過程解決：

就是各個小段文件，合并成一個大段文件。段合并過程

段合并結(jié)束，舊的小段文件會被刪除

.liv 文件維護的刪除文檔，會通過這個過程進行清除

如這個圖，ES 寫入原理不難，記住關(guān)鍵點即可。

write -> refresh -> flush

write：文檔數(shù)據(jù)到內(nèi)存緩存，并存到 translog

refresh：內(nèi)存緩存中的文檔數(shù)據(jù)，到文件緩存中的 segment 。此時可以被搜到

flush 是緩存中的 segment 文檔數(shù)據(jù)寫入到磁盤

寫入的原理告訴我們，考慮的點很多：性能、數(shù)據(jù)不丟失等等

（完）

參考資料：

《深入理解 Elasticsearch》

https://lucene.apache.org/cor...

https://www.jianshu.com/p/e82...