摘要：因?yàn)榈古潘饕蚍謾C(jī)制全文檢索原理分詞原理等等，這些都是不會(huì)過(guò)時(shí)的技術(shù)。中，單個(gè)倒排索引文件稱(chēng)為。其中有一個(gè)文件，記錄了所有的信息，稱(chēng)為文檔新寫(xiě)入時(shí)，會(huì)生成新的。過(guò)程上個(gè)過(guò)程中在文件系統(tǒng)緩存中，會(huì)有意外故障文檔丟失。寫(xiě)入次怕后，清空。

前言

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

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

那 Lucene 是什么？
無(wú)論在開(kāi)源還是專(zhuān)有領(lǐng)域，Lucene 可以被認(rèn)為是迄今為止最先進(jìn)、性能最好的、功能最全的搜索引擎庫(kù)，并通過(guò)簡(jiǎn)單的 RESTful API 來(lái)隱藏 Lucene 的復(fù)雜性，從而讓全文搜索變得簡(jiǎn)單。

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

分布式的實(shí)時(shí)文件存儲(chǔ)，每個(gè)字段都被索引并可被搜索

分布式的實(shí)時(shí)分析搜索引擎

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

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

在應(yīng)用開(kāi)發(fā)中，用 Elasticsearch 會(huì)很簡(jiǎn)單。但是如果你直接用 Lucene，會(huì)有大量的集成工作。

因此，入門(mén) ES 的同學(xué)，稍微了解下 Lucene 即可。如果往高級(jí)走，還是需要學(xué)習(xí) Lucene 底層的原理。因?yàn)榈古潘饕⒋蚍謾C(jī)制、全文檢索原理、分詞原理等等，這些都是不會(huì)過(guò)時(shí)的技術(shù)。

如圖

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

每個(gè)節(jié)點(diǎn)上會(huì)有多個(gè) shard （分片）， P1 P2 是主分片 R1 R2 是副本分片

每個(gè)分片上對(duì)應(yīng)著就是一個(gè) Lucene Index（底層索引文件）

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

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

文檔 create 新寫(xiě)入時(shí)，會(huì)生成新的 segment。同樣會(huì)記錄到 commit point 里面

文檔查詢(xún)，會(huì)查詢(xún)所有的 segments

當(dāng)一個(gè)段存在文檔被刪除，會(huì)維護(hù)該信息在 .liv 文件里面

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

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

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

一個(gè)新文檔過(guò)來(lái)，會(huì)存儲(chǔ)在 in-memory buffer 內(nèi)存緩存區(qū)中，順便會(huì)記錄 Translog。

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

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

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

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

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

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

translog 作用很大：

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

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

新的 segment 收錄到 commit point 中

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

上面幾個(gè)步驟，可見(jiàn) segment 會(huì)越來(lái)越多，那么搜索會(huì)越來(lái)越慢？怎么處理呢？

通過(guò) merge 過(guò)程解決：

就是各個(gè)小段文件，合并成一個(gè)大段文件。段合并過(guò)程

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

.liv 文件維護(hù)的刪除文檔，會(huì)通過(guò)這個(gè)過(guò)程進(jìn)行清除

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

write -> refresh -> flush

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

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

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

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

（完）

參考資料：

《深入理解 Elasticsearch》

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

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