对raft算法的一点理解

raft算法的目的及工作过程：
raft算法是为了保证在超过半数的服务器正常工作的情况下仍然可以达成一致，像一个整体一样工作，并且一少部分慢的机器不会影响系统的整体性能的一致性算法。
Raft算法开始时在集群中选举出*负责日志复制的管理，*接受来自客户端的请求并把该日志复制给集群中的其它服务器，然后通知其它服务器提交该日志。*必须保证其它服务器与它的日志同步，当*宕掉后会自发选举出新的*。
*选取：
1）如何成为*：
候选人在选举过程中获得大多数选票，以获得大多数选票做判断标准就可以防止选举过程中出现两个*的情况，因为每个服务器只能投一票，所以不可能有两台服务器同时获得超过半数的选票。候选人获得某台服务器选票的条件是候选人的任期不能小于服务器最后知道的任期号，而且该服务器之前没有投票给其它的候选人，并且候选人的日志要比该服务器新或者一样新（此举是为了日志复制与提交的安全性，会在后面详细阐述）。
2）选票被瓜分怎么办：
在选举过程中若是有多台追随者同时成为候选人，难免会出现候选人获得一样票数的情况，根据上述的大多数原则要重新开始下一轮的选举，并且此时的任期号需要加1。而为了防止这种瓜分情况，每台服务器等待超时的时间都是随机设定的，这样就可以减少同时超时的概率了。
日志复制：
1）如何保证日志的一致性：
日志复制采取的是覆盖原则，*强制追随者们复制它的日志来处理日志的不一致，即通过nextindex的递减来找到追随者们最后一条与它匹配的日志，并用*之后的日志来覆盖追随者们之后不匹配的日志。这个方法看似很危险，但是通过之后的安全性中的阐述可以看到，采取覆盖的方法并不会出现危险性。
安全性：
1）如何防止已经提交的日志被覆盖：
之所以会出现这种情况，是因为一个日志较旧的服务器成为了*，解决措施是候选人发出RequestVote RPC时，要附上自己最新的一条日志。收到这个RPC的服务器比较这条日志和自己最新的日志。如果自己的日志较新，一定投出反对票。
2）日志的提交要求：
如果要提交的日期是当前任期，则可以根据大多数原则，即当大多数服务器有此日志时，它可以被提交。如果要提交的是之前任期的日志，则它不可以单独提交，而是应该与当前任期的日志一起提交。因为如果只提交之前任期的日志，则在提交之后，有可能被新出现的*覆盖。

就如上图中（c）（d）所示，索引2处的日志已经被提交了，但是由于S5成为了*，它强行覆盖了日志2，但是如果（e）中索引2和3处的日志能够同时提交，S5根本不会成为*，就不会出现这种情况。

对raft算法的一点理解

相关推荐