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

原文地址:https://www.cnblogs.com/windliu/p/11080544.html

时间: 2024-10-11 04:06:34

Raft协议备注的相关文章

Raft协议实战之Redis Sentinel的选举Leader源码解析

这可能是我看过的写的最详细的关于redis 选举的文章了, 原文链接 Raft协议是用来解决分布式系统一致性问题的协议,在很长一段时间,Paxos被认为是解决分布式系统一致性的代名词.但是Paxos难于理解,更难以实现,诸如Google大牛们开发的分布式锁系统Chubby都遭遇了很多坑.Raft协议设计的初衷就是容易实现,保证对于普遍的人群都可以十分舒适容易的去理解.另外,它必须能够让人形成直观的认识,这样系统的构建者才能够在现实中进行必然的扩展. 本文从Redis Sentinel集群选择Le

[搜狐科技]由浅入深理解Raft协议

由浅入深理解Raft协议 2017-10-16 12:12操作系统/设计 0 - Raft协议和Paxos的因缘 读过Raft论文<In Search of an Understandable Consensus Algorithm>的同学都知道,Raft是因为Paxos而产生的.Paxos协议是出了名的难懂,而且不够详细,紧紧依据Paxos这篇论文开发出可用的系统是非常困难的.Raft的作者也说是被Paxos苦虐了无数个回合后,才设计出了Raft协议.作者的目标是设计一个足够详细并且简单易懂

go任务调度3(etcd协调服务、raft协议)

etcd是将数据存储在集群中的高可用k-v存储.允许应用实时监听存储中的k-v变化.能容忍单点故障,能够应对网络分区. (raft是一个分布式协议,管理的是日志:etcd管理的是k-v,把k-v放到日志里,kv就编程分布式集群了)(调用者写入请求发给leader请求写入k-v,leader会将日志实时向follower们复制,leader不会立即返回给调用者,会马上往集群follower做日志拷贝.当日志被复制给N+1个节点后(即大多数),本地提交(也就是告诉客户端提交成功),返回给调用者(客户

RocketMQ 多副本前置篇:初探raft协议

目录 1.Leader选举 1.1 一轮投票中,只有一个节点发起投票的情况 1.2 一轮投票中,超过一个节点发起投票的情况 1.3 思考如何实现Raft选主 2.日志复制 Raft协议是分布式领域解决一致性的又一著名协议,主要包含Leader选举.日志复制两个部分. 温馨提示: 本文根据raft官方给出的raft动画进行学习,其动画展示地址:http://thesecretlivesofdata.com/raft/ @(本节目录) 1.Leader选举 1.1 一轮投票中,只有一个节点发起投票的

基于 raft 协议的 RocketMQ DLedger 多副本日志复制设计原理

目录 1.RocketMQ DLedger 多副本日志复制流程图 1.1 RocketMQ DLedger 日志转发(append) 请求流程图 1.2 RocketMQ DLedger 日志仲裁流程图 1.3 RocketMQ DLedger 从节点日志复制流程图 2.RocketMQ DLedger 多副本日志复制实现要点 2.1 日志编号 2.2 追加与提交机制 2.3 日志一致性如何保证 上一篇 源码分析 RocketMQ DLedger(多副本) 之日志复制(传播) ,可能有不少读者朋

Raft协议--中文论文介绍

本篇博客为著名的 RAFT 一致性算法论文的中文翻译,论文名为<In search of an Understandable Consensus Algorithm (Extended Version)>(寻找一种易于理解的一致性算法). Raft 是一种用来管理日志复制的一致性算法.它和 Paxos 的性能和功能是一样的,但是它和 Paxos 的结构不一样:这使得 Raft 更容易理解并且更易于建立实际的系统.为了提高理解性,Raft 将一致性算法分为了几个部分,例如领导选取(leader

Raft协议详解-leader发送心跳代码go

如果已经把最新的log更新了,那就多等一会,反之,很快就广播AppendEntries(也就是心跳消息) func (rf *Raft) LeaderState() { time.Sleep(10 * time.Millisecond) if rf.LastApplied == rf.CommitIndex { time.Sleep(25 * time.Millisecond) } go rf.BroadcastAppendEntriesRPC()}

TIDB 架构及分布式协议Paxos和Raft对比

近来newsql大热,尤以TIDB最火,pingcap不断打磨TiDB,现如今版本已经迭代到3.0,产品已经基本趋于成熟.对于TiDB,整体架构图如下图所示是由四个模块组成,TiDB Server,PD Server,TiKV Server,TiSpark. TiDB Server负责接受SQL请求,处理SQL的相关逻辑,并通过PD找到存储计算所需数据的TiKV地址,与TiKV交互获取数据,最终返回结果.TiDB Server是无状态的,其本身并不存储数据,只负责计算,可以无限水平扩展,可以通过

共识协议——RAFT&amp;PBFT

区块链是一个没有中央权威的分布式对等系统.虽然权力下放可以防止各方的腐败行为,但是它必需要有一个可靠的共识协议来作出决策,让分散在世界各地的节点可以形成一致的意见.常见的共识算法有比特币采用的POW,fabric使用的PBFT,以及分布式系统一般采用的RAFT等. 一.RAFT协议 Raft基于分布式系统中常见的CFT(Crash Fault Tolerance)问题,比如分布式系统中一些节点由于某些原因宕机造成的问题,Raft协议正常运行的前提是要保证系统中至少一半以上(n/2+1)的节点可以