Raft系列7 快照技术和动态修改配置（原创）

可能是你能找到的最完整最详细的中文版的Raft算法说明博客

内容来源都是原生的论文，可以保证内容的可靠性，并且对论文里面的很多细节做了扩展说明

日志快照

快照技术的优点：

1. 节省磁盘空间，因为业务关心的是数据的最终态（状态机里面的值），而不是过程态（日志里面的命令们），所以在保证数据一致性的前提下，没有必要去保存那些过程态的数据
2. 快照技术可以大大提升重启节点后，加载历史数据的效率
3. 提升leader同步太过落后的follower数据的效率，从而提升响应的性能，否则要一个个的传输落后的log（nextIndex是挨个的递减的，不支持跨步），会很慢

快照生成的原理：

image

1. 每个服务器独立地创建快照，快照只包括自己日志中已经被提交的条目。主要的工作是状态机将自己的状态写入快照中。
2. Raft 快照中也包含了少量的元数据：the last included index 指的是最后一个被快照取代的日志条目的索引值（状态机最后应用的日志条目），the last included term 是该条目的任期号。保留这些元数据是为了支持快照后第一个条目的 AppendEntries 一致性检查，因为该条目需要之前的索引值和任期号。
3. 一旦服务器完成写快照，他就可以删除 last included index 之前的所有日志条目，包括之前的快照。

分析：

1. 每个服务器是可以单独的完成自己的快照生成，而不需要leader通知。这减少了交互的次数。
2. 直接打包状态机里面的数据，可以避免了遍历日志计算的过程，结合lastApplied，可以很快生成一个快照
3. 所有commit的log都会永远有效；只要一个log的term和index匹配成功，那么之前的所有log都一样：这是快照生成的两个前提特性。

快照生成触发的时机：当日志大小达到一个固定大小的时候就创建一次快照。

动态修改配置（比如扩容）

最暴力的方式实现动态修改配置就是集体停机，然后挨个重启，缺点是造成服务的短时间的不可用，而Raft通过引入联合一致（joint consensus），从而解决这个问题

• 日志条目被复制给集群中新、老配置的所有服务器。
• 新、旧配置的服务器都可以成为 leader 。
• 达成一致（针对选举和提交）需要分别在两种配置上获得过半的支持。

也就是说，当系统进入联合一致性的状态下，一条日志的复制和commit变的更加复杂了，但是功能仍然可用，leader的统计变的更复杂，需要分别统计新配置集群的copy成功数量，老配置集群copy成功的数量，综合来判断某一个日志是否可以commit。并且随着老的server被新的server逐渐替代，最终会以新的配置server group进入新的状态

参考

Raft算法中文版（论文翻译）
https://www.cnblogs.com/linbingdong/p/6442673.html

如果你觉得对你有帮助的话，一定要点赞！