一、安全性

Raft增加了如下两条限制以保证安全性：

1. 拥有最新的已提交的log entry的Follower才有资格成为leader。

   1. Follower就是对应节点拥有当前领导者已经提交的所有日志

2. Leader只能推进commit index来提交当前term的已经复制到大多数服务器上的日志，旧term日志的提交要等到提交当前term的日志来间接提交(log index 小于commit index的日志被间接提交)。

   1. Leader只能推进commit index。
   2. 当Leader的日志负责到一半的flowers上，Leader才回提交当前term的日志。
   3. Leader当前日志已经提交了，当前日志之前的日志一定也要提交。

Raft中节点在投票的时候，会判断被投票的候选者对应的日志是否至少和自己一样新。如果不是，则不会给该候选者投票。

flower日志比较的方法：

1.Candidate最后一条日志的任期号。如果比flower大说明是新日志。如果小，说明日志不是新的。如果相等。跳到2
2.判断索引长度,比自己长，说明是新日志。

还有一个问题，就是领导人不能保证一个已经在大多数节点存在的日志是否已经提交。

a、b、c、d、e代表不同的任期阶段

(a) S1是leader。同步任期2的数据给S2

(b) S1宕机，S5当选(S3、S4、S5投票)，产生任期3的日志

© S5宕机，S1恢复当选(同步任期2的数据给S3)。

(d) S1宕机，S5当选(因为他的任期日志比其他的都新)，复制了任期3的所有数据。

假如说在c阶段，S1提交了任期2的数据，那么如果出现d，则会导致任期2数据被覆盖，丢失。也就是说，S1在任期4时候，不能保证已经在大多数节点存在的日志(任期2的日志)是否提交。

所以raft永远不会通过计算副本数目的方式(大多数存在)去提交一个之前任期内(任期2)的日志条目。只有领导人当前任期里的日志条目通过计算副本数目可以被提交(e阶段)。这样之前任期的数据也会被提交。

标签：term,04,--,S1,任期,提交,Raft,日志,Leader
来源： https://blog.csdn.net/zhou920786312/article/details/115457885