raft协议的详细说明

分布式系统相对于单机系统的优势之一是容错性更好。

这是怎么做到的？一个简单的方法是备份。一个系统的工作模式是:接受客户端的命令，系统进行处理，并将处理结果返回给客户端。可以看出，系统中的数据可能会因为命令而发生变化。

实现备份的一种方法是复制状态机(RSM ),它具有非常重要的属性确定性:

也就是说，如果我们能把命令按顺序施加到状态机上，它就能产生同样的状态和同样的输出。

那么如何实现状态机呢？如下图所示(来自raft协议):

在上图中，每个RSM都有一个复制的日志，其中存储了来自客户端的命令。每个RSM中replicate log中的命令顺序相同，状态机按顺序处理replicate log中的命令，并将处理结果返回给客户端。因为状态机是确定性的，所以每个状态机的输出和状态都是相同的。

上图有一个模块——共识模块只是没有提到。该模块用于保证每台服务器上日志的一致性！

所以raft是一种一致性协议，是一种保证服务器上副本一致性的算法。

2.raft协议原则

下面将记录我在看论文时思考的重要观点。

筏式协议的性质

如何确保选举安全

在raft中，只要候选人获得多数票，他就可以成为领导者。追随者投票时遵循两个条件:

对于选举结果:

这里重要的一点是:如何保证在有限的时间内确定一个候选人，选票不会一直被瓜分？Raft使用了一个更优雅的实现，随机化选举超时。这使得每个服务器的超时不同。当新一轮选举开始时，一些服务器不是投票者。或者一些合格的候选人没有参加下一轮。这种做法使得一个单一的领导人很快被选举出来。

2.2如何确保日志匹配

当领导者执行appendEntry rpcs时，该消息将携带两条信息，preLogIndex和preLogTerm。当follower收到消息时，它会首先判断其最新日志条目的索引和$ term是否与RPC中的相同，如果是，它会追加。

这确保了新添加的日志必须与其之前的日志相同。从第一个日志开始就遵循这个原则，很自然的会做出这样的推断。

2.3如何保证领导者的完整性

这在《筏约》中得到充分证明。这个证明比较短。我用逆序法看的时候加了一些注释。

假设领导者是第一个在领导者中不包含提交点的人(t

2.4 raft协议中有一个约定，你不能提交上一期的日志条目作为提交点。这是为什么呢？

这个问题主要是由于raft协议的以前的$ TERM部分的提交条目中的混乱，并且它被误解为该协议用于确保在以前的条款中已经复制到大多数服务器但尚未提交的日志在新的条款中不会被覆盖。

事实上，本文中图8的过程是正确的。

(c)中index=2没有提交，在(d)中复制是正确的做法。论文想说明的是:如果在(c)中，领导提交了上一任的条目，在(d)中还是会被覆盖，也就是说会被commit的条目覆盖，这是错误的！因此，同意“不能提交来自以前的$ TERM的条目”

2.5集群成员的变化

例如，如果集群的配置发生变化，就会添加几个新的服务器，并挂起几个服务器。这会影响选举。

Raft的解决方案是两阶段方法，它引入了一种称为* * *相同状态的过度配置。具体做法和图表:

考虑上面的过程:

2.6日志过长或者日志回放时间过长怎么办？

此时您需要进行日志压缩。

Raft的方法是写时复制的快照(在linux中，写或复制可以通过fork完成)

写入时复制主要与性能有关。如果状态机中的数据太多，快照会消耗大量时间，可能导致系统可用性大大降低。