日誌技術是宕機恢復的主要技術之一。日誌技術最初使用在資料庫系統中。嚴格來說日誌技術不是一種分布式系統的技術，但在分布式系統的實踐中，卻廣泛使用了日誌技術做宕機恢復，甚至如 bigtable 等系統將日誌儲存到乙個分布式系統中進一步增強了系統容錯能力
本章首先簡單介紹資料庫系統中的日誌技術，進而抽象簡化問題模型，在簡化模型的基礎上介紹兩種實用的日誌技術 redo log 與 no redo/no undo log
資料庫系統日誌技術簡述
在資料庫系統中實現宕機恢復，其難點在於資料庫操作需要滿足 acid，尤其在支援事務（transaction）的資料庫系統中宕機往往發生在某些事務只執行了部分操作的時候。此時宕機恢復的主要目標就是資料庫系統恢復到乙個穩定可靠狀態，消除未完成的事務對資料庫狀態的影響。資料庫的日誌主要分為 undo log、redo log、redo/undo log 與 no redo/no undo log。這四類日誌的區別在更新日誌檔案和資料檔案的時間點要求不同，從而造成效能和效率也不相同。本文不就資料庫中的這四類日誌技術做深入討論，相關資訊可以參考有關資料庫系統方面的資料
redo log 與 check point
問題模型
首先簡化原資料庫系統中的問題模型為乙個較為簡單的模型：假設需要設計乙個高速的單機查詢系統，將資料全部存放在記憶體中以實現高速的資料查詢，每次更新操作更新一小部分資料（例如key-value 中的某乙個 key）。現在問題為利用日誌技術實現該記憶體查詢系統的宕機恢復。與資料庫的事務不同的是，這個問題模型中的每個成功的更新操作都會生效。這也等效為資料庫的每個事務只有乙個更新操作，且每次更新操作都可以也必須立即提交（auto commit）
redo log
redo log 是一種非常簡單實用的日誌技術。在上節的問題模型中，只需按如下流程更新既可以實用 redo log
redo log 更新流程:
日誌檔案
2.按更新操作修改記憶體中的資料
3.返回更新成功
上述更新流程中第 2 步沒有考慮修改記憶體資料需要多執行緒互斥等問題，但對於說明 redo log的原理沒有影響。從 redo log 的流程可以看出， redo 寫入日誌的是更新操作完成後的結果（雖然本文不討論 undo log，這點是與 undo log 的區別之一），且由於是順序追加寫日誌檔案，在磁碟等對順序寫有力的儲存裝置上效率較高用 redo log 進行宕機恢復非常簡單，只需要「回放"日誌即可
redo log 的宕機恢復:
1.從頭讀取日誌檔案中的每次更新操作的結果，用這些結果修改記憶體中的資料check point
1.向日誌檔案中記錄「begin check point」
3.向日誌檔案中記錄「end check point」
基於 check point 的宕機恢復流程:
1.將 dump 到磁碟的資料載入到記憶體。
2.從後向前掃瞄日誌檔案，尋找最後乙個「end check point」日誌
3.從最後乙個「end check point」日誌向前找到最近的乙個「begin check point」日誌，並回
放該日誌之後的所有更新操作日誌
本節介紹另一種特殊的日誌技術「no undo/no redo log」，這種技術也稱之為「0/1 目錄」(0/1 directory)
本節介紹這種技術並不再使用上節的問題場景，而假設另一種問題場景：若資料維護在磁碟中，
某批更新由若干個更新操作組成，這些更新操作需要原子生效，即要麼同時生效，要麼都不生效
0/1 目錄技術中有兩個目錄結構，稱為目錄 0(directory 0)和目錄 1(directory 1)。另有乙個結構稱為主記錄（master record）記錄當前正在使用的目錄稱為活動目錄。主記錄中要麼記錄使用目錄 0，要麼記錄使用目錄 1。目錄 0 或目錄 1 中記錄了各個資料的在日誌檔案中的位置
下圖給出了乙個 0/1 目錄的例子。活動目錄為目錄 1，資料有 a、b、c 三項。查目錄 1 可得a、b、c 三項的值分別為 2、5、2
0/1 目錄的資料更新過程始終在非活動目錄上進行，只是在資料生效前，將主記錄中的 0、1 值反轉，從而切換主記錄
0/1 目錄資料更新流程:
1.將活動目錄完整拷貝到非活動目錄
2.對於每個更新操作，新建乙個日誌項紀錄操作後的值，並在非活動目錄中將相應資料的位置
修改為新建的日誌項的位置
3.原子性修改主記錄：反轉主記錄中的值，使得非活動目錄生效
日誌技術的使用非常廣泛，在 zookeeper 系統中，為了實現高效的資料訪問，資料完全儲存在記憶體中，但更新操作的日誌不斷持久化到磁碟，另一方面，為了實現較快速度的宕機恢復， zookeeper週期性的將記憶體資料以 checkpoint 的方式 dump 到磁碟
mysql 的主從庫設計也是基於日誌。從庫只需通過回放主庫的日誌，就可以實現與主庫的同步。由於從庫同步的速度與主庫更新的速度沒有強約束，這種方式只能實現最終一致性
mola與 armor系統支援多種不同的儲存引擎，對於接受到的更新操作，這兩個系統將操作日誌（redo log）儲存到磁碟，引擎可以通過回放日誌實現副本資料的同步。在 mola中，由於不需要強一致性，日誌與資料分離，且日誌也儲存多個副本，當日誌副本更新滿足 quorum 要求後就返回。引擎通過回放日誌的方式實現資料更新，由於回放速度不一致，mola 提供最終一致性保證。同時，由於返回使用者更新成功時只保證日誌更新成功，此時讀取引擎資料未必可以讀到最新更新的資料。armor*中更新了這一設計，日誌與資料不分離，更新日誌的同時也更新引擎資料，從而可以立刻讀取到成功更新的資料
分布式下如何實現統一日誌系統？
在業務系統開發中，日誌的收集和分析很重要，特別是在進行故障分析時，日誌記錄得好，可以幫我們快速定位問題原因。在網際網路分布式系統下，日誌變得越來越分散，資料規模也越來越大，如何更好地收集和分析日誌，就變成了乙個特別重要的問題。為什麼需要統一日誌系統 elk 統一日誌系統 總結 檢視日誌對工程師來說最...
分布式系統原理 筆記
資料分布協議 使用維度各有利弊 雜湊 更新起來要成倍遷移 一致性雜湊 環雜湊，易實現負載均衡 資料量 元資料多，類似b樹的中間節點 資料範圍 也是元資訊多 基本副本協議 中心化 primary secondary 中心節點負責維護資料的更新 併發控制 協調副本的一致性 去中心化 乙個節點向另乙個節點...
kafka ELK分布式日誌系統搭建
設定zookeeper 開啟自動啟動 用第一種！筆者在centos7虛擬機器經過大量研究實驗表明，第二種存在不生效的bug！但是第一種目前沒有不生效的情況。三.安裝kibana。最簡單。新手安裝kibana到啟動也就5分鐘。四，安裝logstash 本文使用的是kafka.conf檔案。input ...