最近在研究關于系統的基于日志的故障恢復，無意間在網上發現一篇論文中對于系統日志模型的精彩論述，翻譯過來并附上我的思路：
『
一個系統是一個具有明顯的邊界的實體，它根據一定的輸入，自身運行邏輯及系統的內部時鐘變化來產生相應的輸出。
所謂“明顯的邊界”是指系統所產生的輸出是明確而無二義性的。我們稱這個邊界為系統的設計規范（specification）。一個系統通過與其所處環境進行交互，從而獲取輸入并產生輸出。一個系統可以被拆解為不同的子系統。這些子系統通常被稱為系統模塊（system components），每個模塊又獨立地成為一個系統，作為一個系統，這個模塊又會和它的相關環境進行交互（比如，一個更大的系統中的其他的模塊組件）來獲取輸入并產生輸出，這些模塊還可以繼續被分解為更小的子系統。
一個系統可以被建模為一個狀態機（state machine），其中的狀態包含了系統所持有并處理的數據。這些狀態的遷移被分為兩大類：由系統內部邏輯所觸發且對外部環境透明的遷移和直接與外部環境相接觸的遷移。前者的例子如內存數據和寄存器數據的轉換，內存中數據結構的重組。第二種遷移的例子包含了各種各樣的系統和環境之間的交互，一般來說，如果這個過程能被建模成系統的I/O操作，則應屬于這一類別。因此，一個消息內容的形成是一個或多個第一類別狀態遷移的結果，但將消息輸出到系統的環境則是屬于第二類遷移。
第二類別的狀態遷移可以捕獲交互事件（interaction events），或者簡單的事件（events）。這些事件可以由系統外部的觀察者（observer）來獲取。顯然，這里的事件是消息、信號、數據及其內容以及一切系統和其環境交互（如機器人運動手腳，報警器報警，打印機打印等等）的發送和接受的模型。此外事件還可以用來描述系統缺乏交互的時間，比如一個計時器在日志中輸出系統的空閑時間等。
當一個大的系統被拆分成多個模塊時，每個模塊都被賦予了整個系統所處理數據的一部分，正因為模塊和模塊間的接口銜接和數據感知，一些原來屬于第一類別的狀態轉換，因為系統的拆分在更低的層次上變成了第二類別，成為系統和環境之間的交互。
對于一個特定的系統，他對于輸入的形式和獲取時間是不可預知的，但是這個系統卻應該能夠做到根據一個特定的輸入以及系統當前的特定狀態獲取一個特定的輸出。因此系統的執行可以被建模為狀態轉換序列，每個狀態的輸入是一個不確定性事件。為了記錄日志并做到故障恢復，我們還應做到能夠在環境中捕獲這個不確定性事件輸入。
此外，在系統與系統間進行交互式，事件的傳遞時間也應該是不確定性的。
』
怎樣用日志來預防系統崩潰，在崩潰后如何還原系統，我想關鍵問題就是怎么做好內存的快照，這樣，在斷電重啟后可以通過日志來還原內存的信息這樣第一步就是確認內存中的數據結構，哪些是必不可少的。確定系統恢復的粒度，按照子系統的分割和事件的記錄來進行replay，根據子系統的劃分，可以找出每個子系統中第二類別的事件進行記錄。
以向數據庫系統提交作業為例，實際上在整個作業提交的過程中，每個層次都要做到可以在失敗的情況下重現，這個功能在完善的數據庫系統和集群批處理系統中當然已經很完善。但如果是針對web系統的作業提交，則需要針對Web的作業持久方案，做一個日志恢復處理。需要特別指出的是，對于數據的查詢是不需要做備份的。
在具體實現上，我想應該包括：日志記錄，故障檢測，日志持久三個部分。一份日志就是一個對于系統檢查點（checkpoint）的連續記錄。日志記錄者負責記錄日志到日志持久者，故障檢測器隨時監控系統，發現故障后，從日志持久者中讀取日志，進行replay.
@2008 楊一. 版權所有. 保留所有權利