Raft实现报告（18）

论文设计了另一种基于leader的方法，其中领导者会创建一个快照，然后它会将这个快照发送给它的每一个follower。然而，这有两个缺点。

首先，将快照发送给每个follower会浪费网络带宽并减慢快照过程。每个follower已经具备了生成自己快照的所有基本信息，并且服务器从其本地状态生成快照，通常比通过网络发送和接受快照造成的消耗要更少。其次，leader的实现会更加的复杂。例如leader需要向follower复制新的日志条目的同时想他们发送快照，以免阻塞新的客户端请求。

还有两个影响快照性能的问题。

服务器必须决定何时进行快照。

如果服务器快照过于频繁，那么就会浪费磁盘带宽和能源；如果间隔时间过长，也有可能耗尽其存储容量，并且会增加重启期间日志中条目重新执行的时间。一种简单的策略是在日志达到固定的大小时进行快照。如果将此大小设置为远大于快照的预期大小，则快照的磁盘带宽开销将会变小。

写时复制

第二个性能问题是写入快照可能需要大量时间，如果我们不希望导致正常操作的延迟。解决方案是使用写时复制技术，以便在不影响正在写入快照的情况下接受新的更新。例如，使用功能数据结构构件的状态机自然的支持这一点，或者，操作系统的写时复制支持（例如，Linux上的fork）可用于创建整个状态机的内存快照（我们的实现就是使用这种方法）