Elasticsearch如何保證資料不丟失？

西北偏北UP發表於2021-01-31

如何保證資料寫入過程中不丟

資料寫入請求達到時，以需要的資料格式組織並寫入磁碟的過程叫做資料提交，對應es就是建立倒排索引，維護segment檔案
如果我們同步的方式，來處理上述過程，那麼系統的吞吐量將很低
如果我們以非同步的方式，先寫入記憶體，然後再非同步提交到磁碟，則有可能因為機器故障而而丟失還未寫入到磁碟中的資料

為了解決這個問題，一般的儲存系統都會設計transag log (事務日誌)或這write ahead log(預寫式日誌)。它的作用時，將最近的寫入資料或操作以日誌的形式直接落盤，從而使得即便系統崩潰後，依然可以基於這些磁碟日誌進行資料恢復。

Mysql有redo undo log ，而HBASE、LevelDB，RockDB等採用的LSM tree則提供了write ahead log 這樣的設計，來保證資料的不丟失

直接落盤的 translog 為什麼不怕降低寫入吞吐量？

上述論述中，資料以同步方式落盤會有效能問題，為什麼將translog和wal直接落盤不影響效能？原因如下：

寫的日誌不需要維護複雜的資料結構，它僅用於記錄還未真正提交的業務資料。所以體量小
並且以順序方式寫盤，速度快

es預設是每個請求都會同步落盤translog ，即配置index.translog.durability 為request。當然對於一些可以丟資料的場景，我們可以將index.translog.durability配置為async 來提升寫入translog的效能，該配置會非同步寫入translog到磁碟。具體多長時間寫一次磁碟，則通過index.translog.sync_interval來控制

前面說了，為了保證translog足夠小，所以translog不能無限擴張，需要在一定量後，將其對應的真實業務資料以其最終資料結構(es是倒排索引)提交到磁碟，這個動作稱為flush ，它會實際的對底層Lucene 進行一次commit。我們可以通過index.translog.flush_threshold_size 來配置translog多大時，觸發一次flush。每一次flush後，原translog將被刪除，重新建立一個新的translog

elasticsearch本身也提供了flush api來觸發上述commit動作，但無特殊需求，儘量不要手動觸發

如何保證已寫資料在叢集中不丟

對每個shard採用副本機制。保證寫入每個shard的資料不丟

in-memory buffer

前述translog只是保證資料不丟，為了其記錄的高效性，其本身並不維護複雜的資料結構。實際的業務資料的會先寫入到in-memory buffer中，當呼叫refresh後，該buffer中的資料會被清空，轉而reopen一個segment,使得其資料對查詢可見。但這個segment本身也還是在記憶體中，如果系統當機，資料依然會丟失。需要通過translog進行恢復

其實這跟lsm tree非常相似，新寫入記憶體的業務資料存放在記憶體的MemTable（對應es的in-memory buffer），它對應熱資料的寫入，當達到一定量並維護好資料結構後，將其轉成記憶體中的ImmutableMemTable(對應es的記憶體segment)，它變得可查詢。