ES底層數(shù)據(jù)持久化的過程？

　　通過分步驟看數(shù)據(jù)持久化過程：write -> refresh -> flush -> merge

　　write 過程

　　一個(gè)新文檔過來，會(huì)存儲(chǔ)在 in-memory buffer 內(nèi)存緩存區(qū)中，順便會(huì)記錄 Translog(Elasticsearch 增加了一個(gè) translog ，或者叫事務(wù)日志，在每一次對(duì) Elasticsearch 進(jìn)行操作時(shí)均進(jìn)行了日志記錄)。

　　這時(shí)候數(shù)據(jù)還沒到 segment ，是搜不到這個(gè)新文檔的。數(shù)據(jù)只有被 refresh 后，才可以被搜索到。

　　refresh 過程

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

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

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

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

　　flush 過程

　　每隔一段時(shí)間—例如 translog 變得越來越大—索引被刷新(flush);一個(gè)新的 translog 被創(chuàng)建，并且一個(gè)全量提交被執(zhí)行

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

　　所有在內(nèi)存緩沖區(qū)的文檔都被寫入一個(gè)新的段。緩沖區(qū)被清空。一個(gè)Commit Point被寫入硬盤。文件系統(tǒng)緩存通過 fsync 被刷新(flush)。老的 translog 被刪除。

　　merge 過程

　　由于自動(dòng)刷新流程每秒會(huì)創(chuàng)建一個(gè)新的段 ，這樣會(huì)導(dǎo)致短時(shí)間內(nèi)的段數(shù)量暴增。而段數(shù)目太多會(huì)帶來較大的麻煩。 每一個(gè)段都會(huì)消耗文件句柄、內(nèi)存和cpu運(yùn)行周期。更重要的是，每個(gè)搜索請(qǐng)求都必須輪流檢查每個(gè)段;所以段越多，搜索也就越慢。

　　Elasticsearch通過在后臺(tái)進(jìn)行Merge Segment來解決這個(gè)問題。小的段被合并到大的段，然后這些大的段再被合并到更大的段。

　　當(dāng)索引的時(shí)候，刷新(refresh)操作會(huì)創(chuàng)建新的段并將段打開以供搜索使用。合并進(jìn)程選擇一小部分大小相似的段，并且在后臺(tái)將它們合并到更大的段中。這并不會(huì)中斷索引和搜索。

　　一旦合并結(jié)束，老的段被刪除：

　　新的段被刷新(flush)到了磁盤。 ** 寫入一個(gè)包含新段且排除舊的和較小的段的新提交點(diǎn)。新的段被打開用來搜索。老的段被刪除。

　　合并大的段需要消耗大量的I/O和CPU資源，如果任其發(fā)展會(huì)影響搜索性能。Elasticsearch在默認(rèn)情況下會(huì)對(duì)合并流程進(jìn)行資源限制，所以搜索仍然 有足夠的資源很好地執(zhí)行。