单机系统故障恢复策略
在单机系统中，程序可能遭遇程序错误、崩溃等导致进程终止。为了在系统重启后恢复服务至先前状态，依赖于数据和日志的完整性。假设磁盘状态良好，我们主要聚焦于操作的重现机制。
1. 操作日志
操作日志是数据库（无论是关系型还是NoSQL）实现故障恢复的关键工具。
日志形式：关系型数据库常采用UNDO/REDO日志，记录事务的撤销和重做信息。例如，事务T将记录X的值从1改为3，则UNDO日志记录为<T,X,1>，REDO日志为<T,X,3>，或合并记录为<T,X,1,3>。NoSQL数据库如Redis则使用AOF（Append On* File）文件记录操作日志，具有独特的日志格式。
性能优化：对于性能敏感的系统，频繁写入日志可能不是*选择。此时，可采用批量提交策略，即累积一定数量的操作后再统一写入日志。Redis提供了多种AOF写入策略，包括每秒写入一次，以平衡数据一致性和性能。
2. CheckPoint机制
随着系统运行时间的增长，操作日志可能变得庞大，仅依赖REDO日志进行恢复将耗时过长。因此，引入CheckPoint机制，定期将内存中的数据快照保存到磁盘上。这样，在恢复时只需重放CheckPoint之后的REDO日志，显著缩短恢复时间。Redis中的RDB持久化即实现了这一机制。
分布式系统故障恢复策略
分布式系统中，每个数据项拥有多个副本，故障恢复时可通过选举新的主副本来继续服务。根据故障类型（临时性或*性），恢复策略有所不同。
- 临时性故障：节点重新上线后，需从其他副本同步缺失的数据，然后恢复服务。
- *性故障：需选择新节点，复制现有副本数据，成为新的副本节点。
此外，总控节点也可能故障，需通过强一致性的备机或选举协议（如Paxos）来确保高可用性（HA）。
分布式系统故障探测
故障探测是分布式系统容错处理的基础。心跳包是常用的探测手段，但存在误判风险。为此，引入租约（Lease）机制以增强可靠性。
- 租约特性：包括授权、时限和续约。总控节点向工作节点发放租约，工作节点在有效期内提供服务，并需定期续约。若续约失败或超时，则视为故障，确保服务一致性。
- 超时判定：考虑节点间时钟差异，总控节点在判定超时时会设置一定的放宽量，以避免误判。
一致性问题
分布式系统面临的*挑战之一是保持数据一致性。后续将深入探讨解决一致性问题的经典分布式协议。