文章目錄

• • 概述
  • 1.es中的基礎概念
  • 2.es中的索引過程
  • • 2.1 一次index請求的大體流程
    • 2.2 為什么是near real time
    • 2.3 為什么要有translog
    • • 2.3.1 translog的作用
      • 2.3.2 translog的持久化機制
      • 2.3.2 commit產生的時機

概述

??這里主要講講es index的過程，努力揭示es在index過程中具體做了哪些工作。
從而增加我們對es的了解，以便于更好的使用和優化es。

1.es中的基礎概念

es的基礎支撐是使用lucene,每個es的索引(index)有多個shard，每個shard都是一個獨立的lucene實例

每個lucene實例通過多個segment來管理自己存儲的數據，每個segment可一個認為是獨立的存儲單元，從存儲功能上來說類似于mysql中分表中的一張表

每個lucene實例同時引入了一個commit的概念來管理segment,因為segment是要寫入磁盤的，如果每產生一個segment都要寫入磁盤的話，那么效率會受到影響，所以一般都是多個segment進行一次寫磁盤操作，叫做commit，每次commit記錄了本次提交的節點的一個快照信息。也就是一個commit check point。這里的每個commit 產生的check point 對應的文件是lucene data存儲目錄下的segment_N文件，看lucene網上說每個lucene實例中可能有多個segment_N文件(主要是因為有些segment_N文件暫時不能刪除，或者使用了自定義的刪除策略)
參考這里

只有數據進入一個segment當中才能夠被搜索到。

2.es中的索引過程

??基于上面的基礎知識，我們來梳理一下對于客戶端通過http請求過來的一個index操作，對應的在elasticsearch的后端會對應的經歷哪些操作

2.1 一次index請求的大體流程

請求的路由:請求可能被發往es集群當中的任意一個節點（此時假設為A）。所有在Elasticsearch集群中的節點都包含：有關哪個分片存在于哪個節點上的元數據。根據一定的規則計算該文檔需要被發往哪個shard(主要是根絕文檔的id來計算),接收請求的節點將請求路由到對應的主分片所在節點(假設為B)。

請求的處理:當節點B接收到來自節點A的請求時，請求被寫入到translog（下面會講到），并將該文檔添加到內存緩沖區。如果請求在主分片上成功，則請求將并行發送到副本分片。只有在所有主分片和副本分片上的translog被持久化(fsync’ed)后，客戶端才會收到該請求成功的確認。

2.2 為什么是near real time

在經過上面兩步介紹，基本上了解了es處理請求的一個大致的套路
??那為什么說es是一個近實時(near real time)的搜索引擎呢，因為通過上面的請求寫進es的文檔并不能立即被搜索到。正常情況下可能會有一秒鐘的延遲，也就是在add之后，最長可能需要經過1s以后才能搜索的到。是什么原因導致的呢，我們就來更進一步的深入其中。

上面第2步當中的內存緩沖區中的內容是不能直接被搜索的，因為在lucene，只有一個打開的segment才能被搜索，此時緩沖區的內容還不是在一個段當中，但是緩沖區的內容會以固定的間隔刷新（默認為1秒）刷新的過程是:

將內存緩沖區的內容寫入文件系統緩存中的新段。此新段的內容更尚未被寫入文件系統，但是分段是打開的，內容可被搜索。

清空內存緩沖區。這里解釋了搜索問什么是近實時的，也就是默認的情況下會有1s的延遲。

當然，這里的內存緩沖區刷新到文件系統緩存的節奏是可以控制的，我們可以通過設置"refresh_interval": "1s"來設置刷新的時間間隔;或者進行強制刷新POST /${index}/_refresh(但是這個在生產中不太建議頻繁使用)

文件系統緩存中的數據會在滿足一定的條件下進行持久化操作，寫入磁盤，產生一個commit check point。

2.3 為什么要有translog

??在前面講es應對一次寫入請求的過程中提到，在主片寫入請求之前會先生成一個tranlog并進行持久化。那么為什么要有這個呢。

2.3.1 translog的作用

??其實es的translog很好理解，基本上和其他系統中的各種用于記錄的log類似，比如mysql中的binlog,redis中的aof日志，都是為了快速記錄操作記錄，防止因服務宕機等產生數據的丟失，當然binlog和aof log可能更加強大，因為他們保存的時間更久一些，可以直接用來做數據的回溯等操作。
??在上面的介紹中我們也可以看到，es除了translog的記錄使用的是同步持久化的方式,其他的操作都是對內存的操作，包括內存緩沖區和文件系統緩存都是對內存的操作。假如在這中間產生了一些意外，比如你不小心踢掉了插頭(這個理由確實有點爛。。。)，那么內存緩沖區和 文件系統緩存中的內容都丟了，即使你插上了插頭，重新啟動了服務，也是無濟于事啊。這個時候tranlog就要閃亮登場力挽狂瀾了。因為tranlog在請求能夠給客戶端正確返回的時候一般都是保證了已經進行了持久化的(默認是都會持久化，你也可以配置成非同步持久化模式，下面會介紹),所以這個時候就可以將translog中的數據拿出來進行回放就行了（并不是全部回放，只是和已經持久化的最后一次commit check point 對比，將之后的tanslog進行重放就行了）。

2.3.2 translog的持久化機制

同時translog的持久化機制也是可以設置的，主要分為同步和異步兩種，設置分別如下

index.translog.durability:request|async

• request模式:這個是默認的模式，在每次寫請求完成之后執行(index, delete, update, bulk)。這個過程在主分片和復制分片都會發生。最終， 基本上，這意味著在整個請求被 fsync 到主分片和復制分片的translog之前，你的客戶端不會得到一個 200 OK 響應
• async模式:會在后臺異步的按照一個配置參數"index.translog.sync_interval": "5s"進行translog的異步持久化，但是突然宕機的話有可能會導致數據丟失。所以沒有特殊情況，還是使用request 模式

2.3.2 commit產生的時機

es會在滿足一定的條件下進行一次commit操作(也叫flush操作或者lucene commit),對應的條件是:

1.index.translog.flush_threshold_size : 這個是沒有持久化的操作的最大數據存儲量，默認是512mb 2.index.translog.retention.age: 這個設置了不再用于幫助lucene commit 持久化的translog能夠保存的最長時間，默認是12h 3.index.translog.retention.size: 這個設置了不再用于幫助lucene commit 持久化的的translog的文件存儲量,可以比flush_threshold_size更大

對于上面三個參數的翻譯稍微有些模糊，從git的源碼中找到的注釋是這樣說的
大概的意思是現在的flush操作只會提交lucene commit 并不會直接delete translog ，也就是把flush和delete translog分開為分別控制的了,也就是只有參數index.translog.flush_threshold_size會影響flush操作。這一段的解釋主要是因為之前的老文檔中有這樣的解釋中的第四點。

在進行flush操作時:

所有在內存緩沖區的文檔都被寫入一個新的段。

緩沖區被清空。

一個提交點被寫入硬盤。

文件系統緩存通過 fsync 被刷新（flush）。
5. 老的 translog 被刪除。 這個目前應該不會立即刪除了

refer
https://www.elastic.co/guide/cn/elasticsearch/guide/current/translog.html
https://blog.csdn.net/zg_hover/article/details/77171014

這個里面有說明flush并不是delete old translog
https://github.com/elastic/elasticsearch/blob/master/docs/reference/index-modules/translog.asciidoc

總結

以上是生活随笔為你收集整理的elasticsearch index doc过程概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。