Raft共识算法入门教程


1 分布式基础概念

    1.1  数据副本与一致性问题

    1.2  分布式系统的进化史

    1.3  全面解读CAP定理

    1.4  CAP理论为什么不能同时满足?

    1.5  BASE原则

2 全面解读Raft共识算法

    2.1  全面解读Raft共识算法

    2.2  Raft日志的作用

    2.3  Raft日志复制

    2.4  Raft共识算法是否属于二阶段提交?

    2.5  Raft算法中的三种超时时间

    2.6  Raft算法动图展示

3 实战操练Raft共识算法

Raft算法中的三种超时时间

Raft算法中,有三种很重要的超时设置:选举超时、最小选举超时、心跳超时。下文给大家详细的介绍一下。

(1)选举超时。就是新一轮选举开始时,每个节点随机思考要不要做领导者的时间,这个时间一般100-到200ms,非常短。假设集群由3个节点组成,为了防止3个节点同时发起投票,Raft会给每个节点分配一个随机的选举超时时间(Election Timeout)。在这个时间内,节点必须等待,不能成为Candidate状态。现在假设节点a等待168ms,节点b等待210ms,节点c等待200ms。由于a的等待时间最短,所以它会最先成为Candidate,并向另外两个节点发起投票请求,希望它们能选举自己为Leader。另外两个节点收到请求后,假设将它们的投票返回给Candidate状态节点a,节点a由于得到了大多数节点的投票,就会从Candidate变为Leader。

(2)最小选举超时。在分布式系统中,有时候需要对集群中的成员数量进行更新的操作。对于被下线的服务器而言,如果它们没有及时关闭,那么它们将不会接收到心跳信息和日志信息,从而不断发生超时,最后导致任期不断增加(高于集群中所有成员的任期),然后不断向集群中发送请求投票消息。集群中的Leader将变为Follower,集群中将不断开始新的选举,从而扰乱集群的正常运行。

解决方案:Raft引入了一个最小选举超时时间,意思是如果集群中存在Leader时,并且接收到心跳信息之后在最小选举超时时间内接受到请求投票消息,那么将会忽略掉该投票消息。

(3)心跳超时。心跳是Leader发送心跳给Follower的时间。这个时间一旦超时,Follower会觉得Leader挂了,这样会开始新的选举周期。