《Introduction to Reliable and Secure Distributed Programming》
2.2 Abstracting Process
2.2.1 Process Failures
process 正常的时候将会执行分布式算法，但是当 process 无法正常执行算法的时候，我们称 process 发生故障了。
根据引发故障的原因，我们可以对 process 做不同的抽象。
下图展示了不同的故障类型。
Crashes
process 最简单的故障方式就是停止执行，换句话说，process 在时刻 t crash，并且再没有 recover。
我们将这种故障称之为 crash fault，在这种故障假设下的抽象为 crash-stop process abstraction。
通常分布式编程抽象的实现算法需要达成一个共识：最多允许 f 个 process 故障。
The relation between the number f of potentially faulty processes and the total number N of processes in the system is generally called resilience.
当然故障的 process 可以重启，只是在 crash-stop 抽象中，恢复的 process 不再是系统的一部分。crash-stop 抽象并不是排除恢复的可能性，也不是禁止恢复，只是算法实现不能依赖 process 的恢复保证正常执行。
默认情况下本书都是假设 crash-stop process abstraction。
2.2.3 Omissions
omission fault 是一种更平常的故障类型，现象为 process 没有发送或接收应该处理的消息。
omission faults 的原因是造成消息丢失的缓存溢出或网络拥塞。
本书不会讨论这种故障。
2.2.4 Crashes with Recoveries
大部分 process 不会停止是一个很强的假设，所以这里提出另外一种 crash-recovery process abstraction。
在这种抽象中，故障指的是 process 停止并且无法恢复，或者 process 无限次停止恢复，只要 process 在有限次重启后可以恢复，那么就认为 process 是正常的。
process 重启之后内部状态就丢失了，所以需要增加一个 stable storage（也被称为 log），重启后需要恢复的信息持久化到日志中。
在 process 恢复时，我们假设生成一个⟨ Recovery ⟩事件，当 process 启动时，默认生成一个⟨ Init ⟩事件。对于恢复过程来说⟨ Init ⟩事件是原子性的，如果 process 在初始化过程中停止了，那么 process 重启后继续初始化流程，然后处理⟨ Recovery ⟩事件。
在 crash-recovery 抽象下设计算法需要尽量减少访问 stable storage，因为访问 stable storage 的成本通常来说很高。
看起来 crash-stop 抽象也可以处理 process 停止、恢复的情况，只要修改一下恢复后的 process 的 identity 即可，但是这样分布式系统中的 process 数量就增加了，本书讨论的分布式算法中 process 集合是静态的，并且预先知道对方。
在 crash-recovery 抽象中处理 process 内部 module 之间的接口也很麻烦，在恢复的时候，下层 module 无法确定上层 module 在停止之前是否处理了消息，有两种方式解决这个问题：
- 改变 module 之间的接口。下层 module 不向上层 module 发送消息，而是将消息存储在 stable storage 中，上层 module 访问 stable storage 处理消息。
- 下层 module 周期性向上层 module 发送消息，直到收到上层 module 回复的确认消息才停止。具体的实现需要处理回复的确认消息，也需要过滤重复消息。
本书将会采用第一种解决方式。
2.2.5 Eavesdropping Faults
当系统运行在不可信环境中，系统的组件可能会暴露给恶意程序，甚至会被恶意程序控制。
恶意程序可能会窃听分布式系统中传递的消息，然后重传消息扰乱系统的正常执行，这种故障称为 eavesdropping fault。
窃听的问题可以通过 cryptography 解决，这是相对独立的一门学科，并且与分布式算法设计没有太多相关性，所以本书不会讨论 eavesdropping fault。
2.2.6 Arbitrary Faults
arbitrary fault 也被称为 Byzantine，也就是故障 process 可以发出任意消息。
毫无疑问，arbitrary fault 很难处理。而且 arbitrary fault 并不一定是特意的或者恶意的，也有可能是由程序中的 bug 引起的。
本书只关注 arbitrary fault 的特意性和恶意性，这需要 cryptographic 的协助，下一章将会介绍 Cryptographic 抽象。
网友评论