Raft协议备注

Posted windliu

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Raft协议备注相关的知识,希望对你有一定的参考价值。

Raft协议

Raft协议基于日志实现了一致性

实现备份的是机制:复制状态机Replicated State Machine,如果两个相同的、确定性的状态机从同一状态开始,以相同顺序输入相同的日志,则两个状态机最终也会保持一致

技术图片

Raft了实现Consensus Module

Consensus Module作为一致性模块对外服务,负责接收客户端的消息,响应请求,并追加到本地日志,一致性模块保证每个机器上的log的一致性
请求到来时,带上(term,commitindex)和append log 去要求Follower追加消息,Follower会先判断(term,index)是否和当前最大的消息相同,如果相同就会追加,否则会拒绝
一致性模块负责复制消息到其他服务器节点,本地日志commit成功后立即应用到状态机

CNew用于服务器增加或者减少节点的情况

Leader:处理与客户端交互,处理消息
Follower:选民,转发请求到leader
Candidate:候选人,可以参选成为leader,不是所有Follower都能成为Candidate,只有数据较完整的才可以。如果Candidate发现自己的term落后了就会退回到Follower

RequestVote:选举期间的RPC消息
AppendEntries:leader选出后向Follow复制日志的RPC消息,心跳也是AppendEntries,不过日志内容为空

raft协议原理

  • Election Safty:每个任期只有一个leader
  • Leader Append-Only:leader仅新增日志,不能重写或删除日志条目
  • Log Match:如果两个日志的term和index相同,则两个状态机的完全相同
  • Leader Completeness:如果一条日志被Commit过,那么大于该日期条目的term的所有节点,都应该有该条目
  • State Machine Safty:如果某个server将日志交由状态机处理了,那么所有server交由状态机执行的日志条目数量完全相同

Election Safty

  • 竞选leader时,Candidate获取过半的票数,就能成为leader
    如果出现大家都投票给自己或两台机器各获得一般的票数,则随机Sleep重新选举
  • 先到先得
  • Follower遵循规则:选举term比自己大 -> index 比自己大,否则不会选举该Candidate
  • 随机超时,更快选出leader
  • 如果给candidate投票了,需要持久化记录投给谁了;否则如果follower重启,可能导致前后投票不相同

Log Match

leader向follower复制日志时,会带上当前最新的(该日志前)term和index,follower接收到请求后,会先比对自身最新的日志的term和index,匹配时才会追加,否则拒绝,这时leader会往前找term 和index,尝试和follower匹配成功,然后从该位置开始复制日志到follower

Leader completeness

不能提交之前任务内的日志作为Commit 点

选主

如果一个Follower在一定时间没有收到Leader的心跳,则开始重新选主
Follower把自己的状态变更为Candidate,并递增本地term,并持久化,向其他机器拉票,并给自己投票,开始等待,直到

  • candidate赢得选主,获得多数派的选票
  • 其他机器成为leader,心跳发现term大于等于本机term,自动变为Follower
  • 超时未能选主成功
  • 确保包含所有commit日志的主机才能成为candidate
    选举时candidate至少要和多数派主机通信,当发现candidate比本机的term,logindex还小时,follower就会拒绝投票

如何判断commit与否

leader发现log已经被多数派的主机写盘了,就认为commited

CNew,集群拓扑变化

将Cnew发送出去,如果Follower发现自己已经不在拓扑结构中,则退出

  • 生成logEntry Cold U Cnew
  • 推送给Follower
  • 过半则Commit
  • 生成CNew Log Entry,推送到所有Follower
  • Follower更新Cnew配置,了解自己在集群中的位置,如果新配置中已无当前节点,则自动退出
  • Leader收到多数派确认后,回复客户端执行命令成功

No op Entry

leader在选举刚结束后,可能有一些Entry是已经提交的,有一些是还未提交的,因此需要提交一个No op Entry来确保和Follower达到一致了,同时,也为了防止客户端来了新请求后不能及时到达

疑问

到底是如果commit的,Raft是如果保证状态机一致性的
情况1:
client - > leader -> Log AppendEntries - > 多数派确认 ->已经commited -> 返回client:成功
由于已经到多数机器上,即使重新选主,也一定会带有最新的log
但是这种情况呢
情况2:
client - > leader -> Log AppendEntries - > 未获取多数派确认 ->不算作Commited -> 返回client:失败重试
返回给client失败了,此时若leader断开网络,可能出现部分确认的实例被选中为leader?岂不是实际成功了

Raft维护的以下属性是否可以解释此问题:

  1. 如果在不同的日志文件内有2个条目有相同的index和term, 它们保存着相同的命令;
  2. 如果在不同的日志文件内有2个条目有相同的index和term,那么之前的所有条目都是相同的;
  3. 只有被多数派follower确认了才会认为Commit了

依据上述特性,出现情况2时,不满足特性3,client会收到执行失败的响应,此时应该做的是不断重试,直到成功,也就是说raft协议允许情况3,也要求client如果想要强一致性,就得不断的重试
raft保证了已提交日志的一致性

follower发现自己的term和logindex 比leader还大怎么办?
截断或leader退化成follower?
leader何时告诉follower log已提交了?
Raft约束日志是连续commit的,leader维护最大已经commit的日志id,并将这个信息附加到AppendEntries告知follower,follower了解到之后即可将本机已有的且已经commit的日志应用到本地的状态机。
技术图片

参考文章
https://blog.csdn.net/weixin_39843367/article/details/82498536
https://blog.csdn.net/baijiwei/article/details/78760308

以上是关于Raft协议备注的主要内容,如果未能解决你的问题,请参考以下文章

raft协议的一些要点

raft 和 zab协议

聊聊分布式一致性协议---Raft协议

Raft协议简析

Raft协议处理各种failover情况

raft协议