yumWant2debug的博客

领导者向所有跟随者发送新一轮的心跳，如果收到多数派的响应，那么领导者就知道，在它发出心跳的那一刻，不可能有一个任期更大的领导者存在。实现线性一致性的一种办法是，领导者将读请求当作写请求处理即读请求也走Raft，领导者收到读请求时同样写入一条日志，等到raft集群将该日志复制、提交并应用到状态机后，返回读请求结果。可以这样优化的时间在于，Raft算法保证一个新的领导者至少在选举超时时间electionTimeout后才被选举出来，所以在租期时间内，可以认为选举不会发生，领导者仍然是真正的领导者。

领导者变更的安全性

现在故障发生了，节点5宕机了，同时节点4只和节点2保持连接，节点1、2、3互相保持连接。这种情况下节点1、3收不到节点4的心跳，会发起Pre-Vote请求，但由于节点2能收到节点4的心跳，所以节点2不会同意Pre-Vote请求，因此节点1、3无法满足超过半数节点同意Pre-Vote请求的条件，该请求以失败告终。如图所示的4节点Raft集群有一个节点和其他三个网络不太稳定，假设它能发送消息给别的节点，但收不到其他节点的消息，那么它将一直收不到心跳消息，这会导致该节点转为候选者，然后自增任期并发起新的选举。

在响应客户端之前宕机，该命令已经执行成功，只是回复客户端的过程中宕机，客户端没有收到命令执行的回复，会寻址下一个领导者处理请求，同一个命令会被执行两次，这是不可接受的。Raft算法要求由领导者处理客户端请求，如果客户端不知道领导者是谁，那么它会和任意一台服务器通信；如果通信的节点不是领导者，那么它会告诉领导者是谁。如果请求id已在日志中，说明这是重复的请求，此时忽略新的命令，直接返回已执行的命令的响应。，客户端会重新发出请求到其他服务器上，最终定位到新的领导者，用新的领导者处理请求，直到命令被执行。

Raft日志复制

当分区后，会出现一种状况，分区的一方没有收到领导者，可能会导致选举Term一直上升，因为无法达到超过半数的选票即3张，因此导致Term一直上涨，等到分区恢复后,由于它的Term最大，导致其他节点不能获得选票，在不断增加Term后，最后才能选出Leader。由于新领导者的选举会更新超过半数服务器的任期，因此旧的领导者即便收到客户端请求也不能提交新的日志，因为它会联系至少一台具有新任期的多数派集群的节点，并发现自己的任期太旧，然后自己转为跟随者继续工作。

随着时间推移，需要进行节点配置变更，需要安全、自动的方式添加节点到集群.通常系统配置是由每台服务器的id和地址组成，之所以不能直接从旧配置切换到新配置，在于可能导致出现矛盾的多数派。如图系统中本来以3台服务器的配置运行，此时系统管理员添加两台服务器。如果系统管理员直接修改配置，那么集群中的节点可能无法完全在同一时间做到配置切换，这会导致服务器S1和S2形成旧集群的多数派，而同一时间服务器S3、S4、S5切换到新配置，会产生两个不同的多数派。

raft领导者选举介绍

领导者将从nextIndex[2]=11处开始检查，一直检查到nextIndex[2]=4处，附带的日志条目信息为index=3且term=1，与领导者匹配。（3） 如此往复，直到领导者的nextIndex[1]=5，带上前一个日志的唯一标识：索引为4且任期为4的信息。（1） 一开始领导者根据自己的日志长度，记录nextIndex[1]= 10+1 =11，带上前一个日志条目的唯一标识：索引为10且任期为6.检查发现跟随者1的索引为10处没有日志，检查失败。跟随者1的索引为9处还是没有日志，检查失败。