Part 18：Raft论文翻译-《CONSENSUS BRIDGING THEORY AND PRACTICE》（日志压缩-总述）
5 Log compaction（日志压缩）
Raft日志在正常操作期间会增长，因为它包含了众多的客户端请求。随着log的增大，它会占用更多的空间，也需要更多的时间来重放。如果没有一些方法来压缩日志，这最终会导致可用性问题：服务器要么会耗尽空间，要么需要太长时间才能启动。因此，对于任何实际的系统都有某种形式的日志压缩是必要的。
日志压缩的一般思想是，日志中的许多信息会随着时间的推移而过时，可以被丢弃。例如，如果以后的操作将x设置为3，则将x设置为2的操作会过时。一旦log entry被提交并应用到状态机上，就不再需要用于到达当前状态的中间状态和操作，并且可以将它们压缩掉。
与Raft基础算法和成员变更不同，不同的系统在日志压缩方面会有不同的需求。由于以下几个原因，没有针对日志压缩的一刀切的解决方案。首先，不同的系统可能会选择在不同程度上权衡简单性和性能。其次，状态机必须密切参与日志压缩，并且状态机在大小以及它们是基于磁盘还是易失性内存上有很大的差异。
本章的目的是讨论日志压缩的各种方法。在每种方法中，日志压缩的大部分责任都落在状态机上，状态机负责将状态写入磁盘并压缩状态。状态机可以以不同的方式实现这一点，这在本章中进行了描述，并如图5.1所总结：
- 针对基于内存的状态机的快照在概念上是最简单的方法。在快照过程中，将整个当前系统状态都写入稳定存储上的快照，然后丢弃迄今为止的整个日志。Chubby和Zookeeper使用了快照技术，我们也在LogCabin中实现了快照；
- 对于基于磁盘的状态机，作为正常操作的一部分，将在磁盘上维护系统状态的最近副本。因此，一旦状态机反映了对磁盘的写入，就可以丢弃日志，并且仅在向其他服务器发送一致的磁盘映像时才使用快照（第5.2节）；
- 日志压缩的增量方法，如日志清理和对数结构的合并树，见第5.3节。这些方法可以有效地写入磁盘，并随着时间的推移均匀地利用资源；
- 最后，第5.4节讨论了一种日志压缩的方法，该方法将直接在日志中存储快照所需的机制最小化。虽然更容易实现，但这种方法只适用于非常小的状态机。
LogCabin目前只实现了基于内存的快照处理方法（它嵌入了基于内存的状态机）。
许多的压缩方法都基于一些关键的概念。
首先，各个服务器各自独立压缩自己已提交的日志，而不是由Leader集中式的压缩。这就避免了Leader向其它服务器传输已有日志数据的负担。这也有助于系统的模块化设计：日志压缩的复杂功能被封装在了状态机内部不需要与Raft出现过多的交互。这就降低了系统整体的复杂性：系统的复杂度是Raft的复杂度+日志压缩的复杂度，而不是两者复杂度的乘积。通过Leader集中式的日志压缩将在5.4小节描述，对于状态机较小的系统，这个方法比较有用。
其次，Raft和状态几件的交互涉及到前缀log的责任从Raft转移到状态机。一旦log entry被状态机apply，状态机将能够从磁盘中恢复这些log entry。一旦状态机从磁盘恢复前缀log，那他就会通知Raft丢弃现有的前缀日志（针对从磁盘恢复的那个服务器）。在Raft放弃管理前缀log之前，Raft必须保存自己的一些状态来描述前缀日志。特别地，Raft会保存它将要丢弃的前缀log的index和所属的term信息，这个信息作为后面log的起始信息。Raft也会保存最新的配置信息以保证集群成员变更支持性。
最后，一旦Raft丢弃了前缀log，状态机将接管两个责任。如果服务器重启，在其apply来自Raft的log entry之前，状态机需要从磁盘中加载状态。而且，状态机需要生成一个一致性的状态镜像以保证其能够将镜像快速的复制给其它速度比较慢的Follower（Follower之间的状态同步，避免从Leader复制）。在log entry被“完全复制”到集群中的每个成员之前，推迟压缩是不必要的，因为少数缓慢的Follower不会阻止集群完全可用，并且可以随时将新的服务器添加到集群中。因此，慢速Follower或新服务器偶尔需要通过网络接收它们的初始状态。Raft将检查这个情况，当Leader丢弃log后又需要某些已经丢弃的log时候。这种情况下，状态机必须提供一致的状态镜像，Leader将会把这个状态镜像发送给其它的Follower（新加入的服务器或者慢速的Follower）。
