Raft算法简介

最新推荐文章于 2024-09-09 18:18:29 发布

Link_xXx

最新推荐文章于 2024-09-09 18:18:29 发布

阅读量914

点赞数

分类专栏：算法

本文链接：https://blog.csdn.net/Link_xXx/article/details/80798448

版权

算法专栏收录该内容

2 篇文章 0 订阅

订阅专栏

本文介绍了Raft一致性算法的核心概念，包括节点的三种状态：follower、candidate和leader。选举过程中，follower在超时后变为candidate并发起投票，而leader通过心跳消息维持其地位。log replication过程中，leader确保所有节点的日志与自身同步。关键术语包括term（区分信息过期的逻辑时间）、heartbeat timeout（触发follower成为candidate的超时）和election timeout（用于选举新leader）。随机设置的超时时间避免了选举冲突，确保系统快速收敛到一致状态。

摘要由CSDN通过智能技术生成

Stanford的新的分布式协议raft算法作为paxos算法的替代品（Paxos难于理解，难以实现），优点是更注重协议的可理解性以及可落地性，已经在etcd，consul中应用。该协议各节点之间如同主从模式,由一个节点负责接收命令,然后通知各个从节点,当过半数节点确认后,则该命令生效.

raft协议中节点分为三种状态：

1.Follower：所有结点都以follower的状态开始，负责跟随leader保持同步状态，选主时负责投票。如果leaderheartbeat timeout ②会进入candidate状态。

2.Candidate ：由超时的follower转变而来，会发起新一轮的选主投票过程，会投自己一票并且发起RequestVote RPC给其余节点，要求投票，得到超过半数的candidate将成为新的leader。

3.Leader：一般一个任期（term ①）内只有一个leader，主要负责处理所有客户端交互，发送heartbeat消息（Append Entries messages）维护更新其余follower日志状态。

ps:任一状态下发现高于当前任期的新任期的合法leader时候会变成该Leader的Follower

raft协议总共有两种过程,分别是election(用于选主)以及log replication(用于保持各节点一致):

election过程：

当follower的heartbeat超时，则自增currentTerm，由Follower转换为Candidate，设置votedFor为自身（投自己一票），并行发起RequestVote RPC，等待其他节点投票，不断重试，直至满足以下任一条件：

1. 获得超过半数Server的投票，转换为Leader，广播Heartbeat

2. 接收到合法Leader的AppendEntries RPC，转换为Follower

3. 选举超时(election timeout ③)，没有Server选举成功，自增currentTerm，再次重新选举

选举过程中有两种需要注意的情况：

Candidate发起投票时候广播出去的信息中会带上该选举期的term以及本地日志最后一条的index，其余节点接收到投票要求后，会对比[term, Index]，只有localTerm<term，localIndex<=Index时，节点才认为该RequestVote RPC请求合法并且为他投票。

如果在选举过程中收到来自其它Leader的AppendEntries RPC。如果该Leader的Term不小于本地的localTerm，则认可该Leader身份的合法性，主动降级为Follower；反之，则维持Candidate身份，继续等待投票结果。

这样保证了新选举出来的leader拥有最新的信息，符合Leader Append-Only规则（Leader从不“重写”或者“删除”本地Log，仅仅“追加”本地Log）。