ES學習筆記之-Translog實現機制的理解

ES做爲一個NoSQL，典型的應用場景就是存儲數據。即用戶能夠經過api添加數據到es中。因爲Lucene內部的實現， 每次添加的數據並非實時落盤的。而是在內存中維護着索引信息，直到緩衝區滿了或者顯式的commit, 數據纔會落盤，造成一個segement，保存在文件中。

那麼假如因爲某種緣由，ES的進程忽然掛了，那些在內存中的數據就會丟失。而實際上，用戶調用api, 返回結果確認用戶數據已經添加到索引中。這種數據丟失是沒法被接受的。怎麼解決這個問題呢？

ES實現了Translog， 即數據索引前，會先寫入到日誌文件中。假如節點掛了，重啓節點時就會重放日誌，這樣至關於把用戶的操做模擬了一遍。保證了數據的不丟失。

經過ES的源碼，瞭解一下實現的細節。 首先關注Translog類。

Translog類是一個索引分片層級的組件，即每一個index shard一個Translog類。它的做用是: 將沒有提交的索引操做以持久化的方式記錄起來(其實就是寫到文件中)。

InternalEngine 在commit metadata中記錄了當前最新的translog generation。 經過這個 generation，能夠關聯到全部沒有commit的操做記錄。

每一個Translog實例在任什麼時候候都只會有一個處於open狀態的translog file. 這個translog file跟translog generation ID是一一映射的關係。

出於性能的考慮，災後重建並非回放全部的translog, 而是最新沒有提交索引的那一部分。因此必須有一個checkpoint, 即translog.ckp文件。

綜上，從文件的視角看待translog機制實際上是兩個文件:

$ tree translog
translog
├── translog-11.tlog
└── translog.ckp

translog記錄日誌的格式以下:|記錄size|操做的惟一id|操做的內容|checksum| 每次add操做返回的location會記錄到versionMap中，這樣就能實現realtime get的功能了。

瞭解了這一點，在配置es的時候，有兩種途徑能夠提高ES索引的性能。

a. 將translog日子和索引配置到不一樣的盤片。
b. 將translog的flush間隔設置長一些。好比以下的參數:
index.translog.sync_interval : 30s 
index.translog.durability : 「async」 
index.translog.flush_threshold_size: 4g 
index.translog.flush_threshold_ops: 50000

瞭解了translog的機制，會發現，即便是translog機制，也並不能徹底能避免數據的丟失。在性能和數據丟失容忍度上，仍是須要作一些平衡。