分布式系统的一致性协议，Raft协议虽然说比paxos协议要简单，但是要理解也是有困难的。经过几天反复看raft协议的论文，然后仔细研读raft的代码感觉自己掌握了raft协议，其中理解最困难的是日志复制安全的那个限制吧。

1.raft要解决的问题。raft要解决的是分布式集群的一致性问题，而不是一个完善的存储系统，比如客户端当时没受到服务器返回，网络通路就挂了，过了几天还要服务器能自动给你返回，不是raft要解决的问题，这是由一个完善的系统的开发者要来解决的问题，不是raft的范围，raft只能确认你的请求被集群是否一致的接受，并且只要被提交确认接受就不可在相同位置被更改，只解决这些问题，我们看raft自己的客户端例子，他不解决返回异常的问题，所以读者不要扩大raft的解决范围

2. 两个rpc请求响应对 都有个current term成员，这样只要收到别人的current term比自己的current term大就更新自己的current term，比自己小拒绝这个投票，在下次自己发起投票的时候+1

3.选举限制5.4.1这节说的比较的term号是日志的term号不是节点的current term号，并且比较的日志并不一定是提交过的日志，是自己和对方所有的日志比较，包括提交和未提交的

4.提交的限制5.4.2这个图配上说明非常迷惑，其实他就是说如果leader的current term是4,你不能直接去提交自己的最大日志是term=2的那条日志，就算这个日志leader知道已经被所有机器接受也不能提交这个日志。如果你提交该日志就可能被s5覆盖，破坏raft的安全，当然不提交也会被s5覆盖，但raft只保证被提交日志的安全性;比current term小的日志term  ,Leader就不会去统计该日志是否被大多数节点接受。只有当有个新日志并且其必须term=4被大多数节点接受，然后可以直接提交这个term=4的新日志;这样可以导致之前的term=2的日志也被默认提交了，这点用数学归纳法证明。

5.leader提交了某日志在下次心跳的时候会通知其他节点也去提交这个日志，然后缓慢的通知节点一条一条的去应用日志

6.提交的日志，和应用的日志都是不一定存盘的，也就是节点挂了，再启动是有可能不知道自己提交了哪些日志，应用了哪些日志，至少raft协议和我看到的实现是没规定必须存盘

7.脏读问题，也就是读到了老版本的问题。如果集群出现了分区，由于老leader被废黜了自己却不知道，是会出现该问题的，因为读是没有日志的。解决这个问题，分为两步，一是新leader上任要提交空白日志去确认自己到底曾经提交了哪些日志(前面说过提交状态是不存盘的，还有可能是新leader以前是folloewer 还没来的及提交日志)。二是需要走一次心跳rpc，看自己的leader权限是否被废黜了。以上是一种分两步的方法。

还有一种方法是依赖时序的lease机制，这个tikv里有对脑裂的脏读问题详细描述。

8.日志rpc的prevlogindex当leader刚发出日志心跳的时候，就是等于自己的最大的日志索引,走过一次心跳后就为follower们的当前日志索引或当前日志索引之前的索引。本节点状态的nextindex就是follower们的想获得的日志索引，也就是follow的当前日志索引+1。投票rpc中的lastlogindex就是candidater自己的最大索引。这样索引的开始都是1而不是c语言用的0; leader发送的log entries是从nextindex发的，前面的日志是否存在只用比较prevlogindex prevlogterm一致就行了

9.客户端判断是否请求成功只用判断leader的该请求是否被提交就行了，不用去查询大多数节点，也不用判断是否被应用

10.应用状态机只是告诉用户可以把commit index存盘，只是可以，不一定非要存盘。应用状态机还有个工作就是将配置正在更改的状态清理。这个要及时，因为我看到的raft是不会处于配置更改状态，然后继续接受配置更改请求的

11.快照压缩:    1)各个节点自己独立打快照，2)打的快照只能包含已经提交的日志，3)快照中也要包含最后一次的配置,4)打完快照就可以丢弃之前的日志了，5)收到leader的快照丢弃自己的快照，6)follower收到leader的快照跟自己的commit index冲突也不要紧:因为leader最新，最牛逼，并且都是已经提交了的日志打快照

12.配置更改，论文花了很大篇幅介绍配置更改的时候并不阻塞客户端请求的方法。注意: 只要收到新配置该节点就立马采用新配置，不管是否被提交

   (1)一次添加多个节点比较麻烦，先说一次添加一个节点，我看的代码就是这样实现的，不会发生多个leader的情况，比如abcde 集群，e作为leader添加f 节点，e立马采用新配置感知了f的加入，这时候a想竞争leader:  (ab(c)def)如果想产生两个leader节点c 就要投两票，集合有交叉，所以不能产生两个leader。

  (2) 一次添加多个节点就比较麻烦了，开始是abc集群，现在添加de两个节点，就会发生ab可以投a作为leader,cde可以投c作为leader，解决这个问题分两阶段，第一阶段有个共同一致性状态Cold-new日志，提交这个日志前，集群想选leader必须获得新老配置两个各自的集群的大多数才能成功，提交日志也是必须获得双方的大多数，这样就不会产生两个leader,提交后再全部所有都切换为新配置。注意的是新老集群的任一方不得单独做决定，只有双方都确认了才能做决定。

在共同一致态，raft的规则是于之前说的不同的，

  1)日志被复制到所有节点

  2)新老都可以成为leader

   3)共同一致态要同时获得新老集群的大多数才能达成一致。

3个问题:

1)为了可用性，不要拖慢集群响应速度，新节点日志比较老，就先不给其投票权，但给其复制日志，等日志追上来了再给其投票权

2)leader是老集群的成员，leader自己被删除了或则说leader自己不是新集群一份子，这样leader只有在提交了Cnew后才下台，这是种奇怪的状态:他的复制日志，自己也不把自己计算大多数，只是复制提交日志。他提交完日志使命就结束了

3)被移除的pld集群的节点要竞争领导，导致正常leader被退位，使用最小超时时间，在这个最小超时时间内发起的投票直接拒绝，也不更新自己的current term;一个没有节点记录的选举，直接拒绝它的投票，并提示其下机

13.分区后的节点重连进集群，因为term比集群的大会干扰集群导致重新选举，而导致业务中断，这种情况采用zk的pre-vote机制。

>源码注释