- 日志压缩，leader，follower各种独立进行, 并不是由leader发起, 然后向follower同步的过程
- 被压缩的日志一定是已经提交的, 并且应用到状态机完成的, 任何情况下都不可能出现回退的问题
- 比如一个新的leader当选, 会向其他follower同步自己的log, 这个过程会把follower上和自己不一致的log覆盖掉(清除), 当前follower可能是snapshot+部分log的情况, 那这种覆盖的场景不用考虑snapshot, 只需要考虑增量的log部分即可, 因为snapshot的内容是已经提交的, 和新leader的日志一定是一致的(包含最新已提交log的节点才可能当选为leader), 不会被覆盖
- 有种case, 是follower和leader之间失联太久, 重新建立起复制链接的时候, leader上需要同步的那部分日志已经打了快照删除了, 这时候只能把snapshot同步给follower(follower本地的日志需要清除), 然后再这个snapshot的基础之上, 再继续同步日志
- 场景
- follower没有挂掉, 只是运行的比较慢, 当leader执行snapshot的时候, 需要同步给follower的next log已经没了
- follower挂掉了, 然后重启，追赶日志差距
- 一个新的节点加入集群
- 当跟随者通过这种 RPC 接收到快照时，他必须自己决定对于已经存在的日志该如何处理。
- 通常快照会包含没有在接收者日志中存在的信息。在这种情况下，跟随者丢弃其整个日志；它全部被快照取代，并且可能包含与快照冲突的未提交条目。
- 如果接收到的快照是自己日志的前面部分（由于网络重传或者错误），那么被快照包含的条目将会被全部删除，但是快照后面的条目仍然有效，必须保留。
- 具体决定发送快照的条件是？
- 场景