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機制，也並不能完全能避免數據的丟失。在性能和數據丟失容忍度上，還是需要做一些平衡。