最近在研究关于系统的基于日志的故障恢复，无意间在网上发现一篇论文中对于系统日志模型的精彩论述，翻译过来并附上我的思路：
『
一个系统是一个具有明显的边界的实体，它根据一定的输入，自身运行逻辑及系统的内部时钟变化来产生相应的输出。
所谓“明显的边界”是指系统所产生的输出是明确而无二义性的。我们称这个边界为系统的设计规范（specification）。一个系统通过与其所处环境进行交互，从而获取输入并产生输出。一个系统可以被拆解为不同的子系统。这些子系统通常被称为系统模块（system components），每个模块又独立地成为一个系统，作为一个系统，这个模块又会和它的相关环境进行交互（比如，一个更大的系统中的其他的模块组件）来获取输入并产生输出，这些模块还可以继续被分解为更小的子系统。
一个系统可以被建模为一个状态机（state machine），其中的状态包含了系统所持有并处理的数据。这些状态的迁移被分为两大类：由系统内部逻辑所触发且对外部环境透明的迁移和直接与外部环境相接触的迁移。前者的例子如内存数据和寄存器数据的转换，内存中数据结构的重组。第二种迁移的例子包含了各种各样的系统和环境之间的交互，一般来说，如果这个过程能被建模成系统的I/O操作，则应属于这一类别。因此，一个消息内容的形成是一个或多个第一类别状态迁移的结果，但将消息输出到系统的环境则是属于第二类迁移。
第二类别的状态迁移可以捕获交互事件（interaction events），或者简单的事件（events）。这些事件可以由系统外部的观察者（observer）来获取。显然，这里的事件是消息、信号、数据及其内容以及一切系统和其环境交互（如机器人运动手脚，报警器报警，打印机打印等等）的发送和接受的模型。此外事件还可以用来描述系统缺乏交互的时间，比如一个计时器在日志中输出系统的空闲时间等。
当一个大的系统被拆分成多个模块时，每个模块都被赋予了整个系统所处理数据的一部分，正因为模块和模块间的接口衔接和数据感知，一些原来属于第一类别的状态转换，因为系统的拆分在更低的层次上变成了第二类别，成为系统和环境之间的交互。
对于一个特定的系统，他对于输入的形式和获取时间是不可预知的，但是这个系统却应该能够做到根据一个特定的输入以及系统当前的特定状态获取一个特定的输出。因此系统的执行可以被建模为状态转换序列，每个状态的输入是一个不确定性事件。为了记录日志并做到故障恢复，我们还应做到能够在环境中捕获这个不确定性事件输入。
此外，在系统与系统间进行交互式，事件的传递时间也应该是不确定性的。
』
怎样用日志来预防系统崩溃，在崩溃后如何还原系统，我想关键问题就是怎么做好内存的快照，这样，在断电重启后可以通过日志来还原内存的信息这样第一步就是确认内存中的数据结构，哪些是必不可少的。确定系统恢复的粒度，按照子系统的分割和事件的记录来进行replay，根据子系统的划分，可以找出每个子系统中第二类别的事件进行记录。
以向数据库系统提交作业为例，实际上在整个作业提交的过程中，每个层次都要做到可以在失败的情况下重现，这个功能在完善的数据库系统和集群批处理系统中当然已经很完善。但如果是针对web系统的作业提交，则需要针对Web的作业持久方案，做一个日志恢复处理。需要特别指出的是，对于数据的查询是不需要做备份的。
在具体实现上，我想应该包括：日志记录，故障检测，日志持久三个部分。一份日志就是一个对于系统检查点（checkpoint）的连续记录。日志记录者负责记录日志到日志持久者，故障检测器随时监控系统，发现故障后，从日志持久者中读取日志，进行replay.
@2008 杨一. 版权所有. 保留所有权利