怎么样做免费网站,建筑招工找活平台,东莞网站制作网站,拍摄宣传片制作公司分布式Raft原理详解#xff0c;从不同角色视角分析相关状态 1. CAP定理2.Raft 要解决的问题3. Raft的核心逻辑3.1. Raft的核心逻辑2.1. 复制状态机2.2. 任期 Term2.3. 任期的意义#xff1a;逻辑时钟2.4 选举定时器 3. Leader选举逻辑4. 从节点视角查看Leader选举4.1. Follow… 分布式Raft原理详解从不同角色视角分析相关状态 1. CAP定理2.Raft 要解决的问题3. Raft的核心逻辑3.1. Raft的核心逻辑2.1. 复制状态机2.2. 任期 Term2.3. 任期的意义逻辑时钟2.4 选举定时器 3. Leader选举逻辑4. 从节点视角查看Leader选举4.1. Follower从节点4.2. Candidate候选者4.3. Leader主节点4.4. 触发选举的条件 5. 触发重新选举5.1. 获取超过半数投票赢得选举5.2. 投票未超过半数选举失败5.3. 收到其他Leader通信请求5.4. 脑裂问题 6. 宕机选举完成后6.1. Leader宕机6.2.2. Follower宕机 7. Log Replication日志同步复制7.1. 基础概念7.2. Leader视角7.3. Follower视角7.4. Logs7.5. 日志复制的例子7.6. 日志不一致7.7. logs 复制时异常问题及解决7.8. 复制故障说明 8. 疑问和思考3.1. 是否需要配置dfs.datanode.du.reserved 9. 参考文档 CAP 一个分布式系统不可能同时满足一致性 C Consistency、可用性AAvailability和分区容错性PPartition tolerance这三个基本需求最多只能同时满足其中的两项
分布式存储架构中设计共识算法要考虑在一个复制集群中所有节点按照确认的顺序处理命令最终结果是在客户端看来一个复制集群表现的像一个单状态机一样一致。为了保证多个节点顺序一致需要处理如下问题
非拜占庭错误包含网络延迟分区丢包重复和乱序只要多数节点quorum正常集群就能对外提供稳定的服务。错误的节点可以在稍后恢复后重新加入集群服务不依赖系统时钟实现修改的顺序一致性性能多数节点达成一致即可不能因为少量的慢节点拖累整集群的性能脑裂问题
关于常见分布式组件高可用设计原理的理解和思考 1. CAP定理
CAP 一个分布式系统不可能同时满足一致性 C Consistency、可用性AAvailability和分区容错性PPartition tolerance这三个基本需求最多只能同时满足其中的两项
分布式存储架构中设计共识算法要考虑在一个复制集群中所有节点按照确认的顺序处理命令最终结果是在客户端看来一个复制集群表现的像一个单状态机一样一致。为了保证多个节点顺序一致需要处理如下问题
非拜占庭错误包含网络延迟分区丢包重复和乱序只要多数节点quorum正常集群就能对外提供稳定的服务。错误的节点可以在稍后恢复后重新加入集群服务不依赖系统时钟实现修改的顺序一致性性能多数节点达成一致即可不能因为少量的慢节点拖累整集群的性能脑裂问题
2.Raft 要解决的问题
由于分布式系统引入了多个节点节点规模越大宕机、网络时延、网络分区就会成为常态任何一个问题都可能导致节点之间的数据不一致Raft 是用来解决分布式场景下的一致性问题的共识算法。
举例来说有5台机器组成的集群需要保证机器之间数据同步有如下问题需要考虑
客户端进行写入的时候是直接写入这5台机器再返回吗这样如果某台机器比较慢势必会影响性能那如果只写入一台机器新的数据要如何同步到其他机器呢服务应该在什么时候给客户端返回来保证数据的强一致性呢多个客户端同时写入的时候如何保证同步的时候操作执行的顺序是一致的呢或者说如何保证数据不会乱呢当客户端读取数据的时候会不会存在读到老数据的可能应该以一种什么样的方式去读才能读取到最新的数据呢
这些问题都是分布式系统经常会面临的问题。Raft 一致性算法可以保证即使在网络丢包延迟乱序或者宕机部分网络隔离的情况下集群中机器能保证数据的强一致性。
3. Raft的核心逻辑
3.1. Raft的核心逻辑
Raft的核心就是leader发出日志同步请求follower接收并同步日志最终保证整个集群的日志一致性。
先选举出 LeaderLeader 完全负责 Replicated-Log 的管理Leader 负责接受所有客户端更新请求然后复制到 Follower 节点并在安全的时候执行这些请求。若 Leader 故障Followes 会重新选举出新的 Leader
Raft 是满足 CAP 定理中的 C 和 P 特性属于强一致性的分布式协议。
Raft 的三个核心问题
Leader Election领导人选举选主主节点宕机后必须选择一个节点成为新的主节点有且仅有一个Leader节点如果Leader宕机通过选举机制选出新的LeaderLog Replication日志复制备份主节点必须接受客户端指令日志并强制复制到其他节点Leader从客户端接收数据更新/删除请求然后日志复制到Follower节点从而保证集群数据的一致性Safty安全性复制集群状态机必须一致。相同索引的日志指令一致顺序一致通过安全性原则来处理一些特殊case保证Raft算法的完备性
所以Raft算法核心流程可以归纳为
首先选出LeaderLeader节点负责接收外部的数据更新/删除请求然后日志复制到其他Follower节点同时通过安全性的准则来保证整个日志复制的一致性如果遇到Leader故障Followers会重新发起选举出新的Leader
Raft 的优点如下
高可用Raft 协议中N个节点系统容忍 N/2个节点的故障通常 N5。选举和日志同步都只需要大多数的节点 N/21正常互联即可即使 Leader 故障在选举 Term 超时到期后集群自动选举新 Leader不可用时间非常小强一致虽然 Raft 协议中所有节点的数据非实时一致但 Raft 算法保证 Leader 节点的数据最全同时所有修改请求写入 / 更新 / 删除都由 Leader 处理 从用户角度看是指永远可以读到最新的写成功的数据而从服务内部来看指的是所有的存活节点的 State Machine 中的数据都保持一致高可靠Raft 算法保证了 Committed 的日志不会被修改S0tate Matchine 只应用 Committed 的日志所以当客户端收到请求成功即代表数据不再改变。Committed 日志在大多数节点上冗余存储少于一半的磁盘故障数据不会丢失高性能与必须将数据写到所有节点才能返回客户端成功的算法对比Raft 算法只需要大多数节点成功即可少量节点处理缓慢不会延缓整体系统运行
2.1. 复制状态机
节点的状态切换状态机如下图所示
Start 起始状态各个节点刚启动的时候自动进入 Follower 状态Times out, starts electionFollower 在启动之后将开启一个选举超时定时器当这个定时器到期时Follower 将切换到 Candidate 状态发起选举每个 Follower 都投自己一票成为 CandidateTimes out, new election进入 Candidate 状态之后就开始选举但是如果在下一次选举超时之前还没有选出一个新的 Leader那么还会保持在 Candidate 状态重新开始一次新选举Receives votes from majority of servers当 Candidate 状态的节点收到了超过半数的节点的选票那么其将切换状态成为新的 Leader同时向其他节点广播其他节点成为 FollowerDiscovers current leader or new term处于 Candidate 状态的节点如果收到了来自 Leader 的消息或者更高任期号Term的消息表示集群中已经有 Leader 了将切换回到 Follower 状态Discovers server with higher termLeader 状态下如果收到来自更高任期号的消息将切换到 Follower 状态。这种情况大多数发生在有网络分区的状态下网络分区又恢复
Raft 节点间通过 RPC 请求来互相通信主要有以下两类 RPC 请求:
Request-Vote RPC用于 Candidate 状态的节点进行选举用途Append-Entries RPC由 Leader 节点向其他节点复制日志数据以及同步心跳数据
2.2. 任期 Term
Raft算法把时间轴划分为不同任期Term每个Term开始于选举阶段一般由选举阶段和领导阶段组成。每个任期Term都有自己的编号TermId该编号全局唯一且连续单调递增
每个任期开始都会进行领导选举Leader Election。如果选举成功则进入维持任务Term阶段此时Leader负责接收客户端请求并负责复制日志。Leader和所有Follower都保持通信如果Follower发现通信超时网络问题、或者Leader宕机会触发TermId递增并发起新的选举。如果选举成功则进入新的任期。如果选举失败Hint选举失败触发的条件是什么没选出Leader则当前任期很快结束TermId递增然后重新发起选举直到成功。
如下图Term N选举成功Term N1和Term N2选举失败Term N3重新选举成功
2.3. 任期的意义逻辑时钟
在Raft协议中任期充当逻辑时钟服务器节点可以通过任期发现一些过期的信息比如过时的 Leader。任期单调递增服务器之间通信的时候会交换当前任期号如果一个服务器的当前任期号比其他的小该服务器会将自己的任期号更新为较大的那个值。如果一个 Candidate 或 Leader 发现自己的任期号过期了它会立即回到 Follower 状态。如果一个节点接收到一个包含过期的任期号的请求它会直接拒绝这个请求.
2.4 选举定时器
在 Raft 中有两个 Timeout 定时器控制着选主 Election 的进行
选举超时时间Election Timeout意思是 Follower 要等待成为 Candidate 的时间要成为 Candidate 后才可以投票选举通常 Election Timeout 定时器为 150ms~300ms这个时间结束之后 Follower 变成 Candidate 开始选举过程。首先是自己对自己投票1然后向其他节点请求投票选票如果接收节点在收到投票请求时还没有参与过投票那么它会响应本次请求并把票投给这个请求投票的 Candidate然后重置自身的 Election Timeout 定时器一旦一个 Candidate 拥有所有节点中的大多数投票则此节点变成一个 Leader心跳超时时间Heartbeat Timeout当一个节点从 Candidate 变为 Leader 时此节点开始向其他 Follower 发送 Append Entries这些消息发送的频率是通过 Heartbeat Timeout 配置Follower 会响应每条的 Append Entry整个选举会一直进行直到 Follower 停止接受 heartbeat 并且变成 Candidate 开始下一轮选举即假设此时 Leader 故障或者丢失了Follower 检测到心跳超时在此期间没有收到 Leader 发送的 Append Entry后再等待自身选举超时后发起新一轮选举
简言之
随机超时时间 Follower节点每次收到Leader的心跳请求后会设置一个随机的区间位于[150ms, 300ms)的超时时间。如果超过超时时间还没有收到Leader的下一条请求则认为Leader过期/故障了Leader心跳1s Leader在当选期间会以一定时间间隔向其他节点发送心跳请求以维护自己的Leader地位
3. Leader选举逻辑
当 Leader 节点由于异常宕机、网络故障等无法继续提供服务时可以认为它结束了本轮任期TERMN需要开始新一轮的选举Election而新的 Leader 当然要从 Follower 中产生开始新一轮的任期TERMN1。从 Follower 节点的角度来看当它接收不到 Leader 节点的心跳即心跳超时时间触发时可认为 Leader 已经丢失便进入新一轮的选举流程 一个 Follower 的竞选过程如下
节点状态由 Follower 变为 Candidate同时设置当前的 Term 任期Candidate 节点给自己投 1 票同时向其他所有节点发送 拉票请求 RequestVote RPCCandidate 节点等待投票结果确认下一步的去向 case1本 Node 赢得选举节点状态变为 Leadercase2有其他 Node 赢得选举节点状态变为 Followercase3第一轮选举未产生结果节点状态保持为 Candidate case1本 Node自己赢得选举 只有当一个 Candidate 得到 超过半数选票时才能赢得选举 每一个节点按照先到先得的方式最多投票给一位 Candidate。在 Candidate 赢得选举后自己变为 Leader同时向所有节点发送心跳信息以使其他节点变为 Follower本次选举结束开始下一任任期 case2其他 Node 赢得选举 在等待投票结果的过程中如果 Candidate 收到其他节点发送的心跳信息即 AppendEntries RPC 并检查此心跳信息中的任期不比自己小这一点很重要则自己变为 Follower听从新上任的 Leader 的指挥 case3: 本轮选举未产生结果一段时间之后没有任何获胜者 极端情况下如当有多个 Candidate 同时竞选时由于每个人先为自己投一票导致没有任何一个人的选票数量过半。当这种情况出现时每位 Candidate 都开始准备下一任竞选将 TERM1同时再次发送拉票请求。为了防止出现长时间选不出新 Leader 的情况Raft 采用了两个方法来尽可能规避该情况发生防止第3种情况无限重复使得没有Leader被选举出来 Follower 认为 Leader 不可用的超时时间Election Timeout即选举超时时间是随机值防止了所有的 Follower 都在同一时刻发现 Leader 不可用的情况从而让先发现的 Follower 顺利成为 Candidate继而完成剩下的选举过程并当选使用随机化选举超时时间从一个固定的区间如150-300ms随机选择避免同时出现多个Candidate
即使出现多个 Candidate 同时竞选的情况再发送拉票请求时也有一段随机的延迟来确保各个 Candidate 不是同时发送拉票请求Candidate等待超时的时间随机Candidate 在开始一次选举的时候会重置一个随机的选举超时时间然后一直等待直到选举超时这样减小了在新的选举中再次发生选票瓜分情况的可能性 4. 从节点视角查看Leader选举
集群中每个节点只能处于Leader、Follower和Candidate三种状态的一种从节点视角看选举流程如下 4.1. Follower从节点
节点默认是Follower如果刚刚开始或和Leader通信超时时原因下述Follower会发起选举变成Candidate然后去竞选Leader如果收到其他Candidate的竞选投票请求按照先来先得每个任期只能投票一次的投票原则投票
4.2. Candidate候选者
Follower发起选举后就变为Candidate会向其他节点拉选票。Candidate的票会投给自己所以不会向其他节点投票如果获得超过半数的投票Candidate变成Leader然后马上和其他节点通信表明自己的Leader的地位如果选举超时重新发起选举如果遇到更高任期Term的Leader的通信请求转化为Follower
4.3. Leader主节点
节点成为Leader节点后此时可以接受客户端的数据请求负责日志同步如果遇到更高任期Term的Candidate的通信请求这说明Candidate正在竞选Leader此时之前任期的Leader转化为Follower且完成投票如果遇到更高任期Term的Leader的通信请求这说明已经选举成功新的Leader此时之前任期的Leader转化为Follower
4.4. 触发选举的条件
那么什么时候选举重新发生呢
Leader离线故障Follower发现通信超时收不到Leader的应答包
在选举完成后Leader和所有Follower都保持通信如果Follower发现通信超时任期IDTermId递增并发起新的选举。如果选举成功则进入新的任期。如果选举失败TermId递增然后重新发起选举直到成功。
5. 触发重新选举
上面说了Leader在任期内会周期性向其他Follower节点发送心跳来维持地位Follower如果发现心跳超时就认为Leader节点宕机或不存在。随机等待一定时间后Follower会发起选举变成Candidate然后去竞选Leader。重新选举结果有三种情况
5.1. 获取超过半数投票赢得选举
当Candidate获得超过半数如何判定超过了半数的投票时代表自己赢得了选举且转化为Leader。此时它会马上向其他节点发送请求从而确认自己的Leader地位从而阻止新一轮的选举投票原则当多个Candidate竞选Leader时一个任期内Follower只会投票一次票且投票先来显得Candidate存储的日志至少要和Follower一样新安全性准则否则拒绝投票
5.2. 投票未超过半数选举失败
当Candidate没有获得超过半数的投票时说明多个Candidate竞争投票导致过于分散或者出现了丢包现象。此时认为当期任期选举失败任期TermId1然后发起新一轮选举上述机制可能出现多个Candidate竞争投票导致每个Candidate一直得不到超过半数的票最终导致无限选举投票循环投票分散问题解决 Raft会给每个Candidate在固定时间内随机确认一个超时时间一般为150-300ms。这么做可以尽量避免新的一次选举出现多个Candidate竞争投票的现象
5.3. 收到其他Leader通信请求
如果Candidate收到其他声称自己是Leader的请求的时候通过任期TermId来判断是否处理如果请求的任期TermId不小于Candidate当前任期TermId那么Candidate会承认该Leader的合法地位并转化为Follower否则拒绝这次请求并继续保持Candidate
5.4. 脑裂问题
脑裂问题Brain Split即任一任期Term内有超过一个Leader被选出Raft要求在一个集群中任何时刻只能有一个Leader这是非常严重的问题会导致数据的覆盖丢失。
出现的场景如下面的Raft集群某个时刻出现网络分区集群被隔开成两个网络分区在不同的网络分区里会因为无法接收到原来的Leader发出的心跳而超时选主这样就会造成多Leader现象。 在网络分区1和2中出现了两个LeaderA和D假设此时要更新分区2的值,因为分区2无法得到集群中的大多数节点的ACK会导致复制失败。而网络分区1会成功,因为分区1中的节点更多,Leader A能得到大多数回应。
当网络恢复的时候集群网络恢复不再是双分区Raft会有如下操作
任期安全性约束Leader D 发现自己的Term小于Leader A会自动下台Step Down成为FollowerLeader A保持不变依旧是集群中的主Leader角色因为Leader A是重新选举出的TermId至少会加1分区中的所有节点会回滚自己的数据日志,并匹配新Leader的日志Log然后实现同步提交更新自身的值。通知旧Leader 节点D也会主动匹配主Leader节点A的最新值并加入到Follower中 最终集群达到整体一致集群存在唯一Leader节点A
小结下领导选举流程通过若干的投票原则保证一次选举有且仅可能最多选出一个Leader从而解决了脑裂问题
6. 宕机选举完成后
6.1. Leader宕机
每当Leader对所有的Follower发出Append Entries的时候Follower会有一个随机的超时时间如果超时TTL内收到了Leader的请求就会重置超时TTL如果超时后Follower仍然没有收到 Leader的心跳Follower会认为 Leader 可能已经离线此时第一个超时的Follower会发起投票这个时候它依然会向宕机的原Leader发出Reuest Vote原Leader不会回复。当收到集群超过一半的节点的RequestVote reply后,此时的Follower会成为Leader
若稍后宕机的Leader恢复正常之后重新加入到Raft集群初始化的角色是Follower非leader
6.2.2. Follower宕机
Follower宕机对整个集群影响不大可用个数内影响是Leader发出的Append Entries无法被收到但是Leader还会继续一直发送直到Follower恢复正常。Raft协议会保证发送AppendEntries request的rpc消息是幂等的即如果Follower已经接受到了消息但是Leader又让它再次接受相同的消息Follower会直接忽略
7. Log Replication日志同步复制
Raft集群建立完成后Leader接收所有客户端请求然后转化为log复制命令发送通知其他节点完成日志复制请求。每个日志复制请求包括状态机命令 任期号同时还有前一个日志的任期号和日志索引。状态机命令表示客户端请求的数据操作指令任期号表示Leader的当前任期。
7.1. 基础概念
日志定义客户端的每一个请求都包含一条将被复制状态机执行的指令。Leader 把该指令作为一个新的条目追加到日志中去然后并行的发起 AppendEntries RPC同步到其他副本安全复制当有超过一半的副本复制好了该条目便认为已经安全的复制Leader接着会将条目应用到其状态机中并将结果返回给客户端。若遇到网络故障或丢失包Leader 会不断地重试 AppendEntries RPC即使已经回复了客户端直到所有的 Follower 最终都存储了所有的日志条目日志索引每个日志条目存储一条状态机指令和 Leader 收到该指令时的任期号同时每个日志条目都有一个整数索引值来表明它在日志中的位置日志提交一旦创建该日志条目的 Leader 将它复制到过半的服务器上该日志条目就会被提交Raft 算法保证所有已提交的日志条目都是持久化的并且最终会被所有可用的状态机执行。不仅如此Leader 日志中该日志条目之前的所有日志条目也都是已经提交的条目。Leader会保存当前已提交最大的日志索引未来的所有 AppendEntries RPC 都会包含该索引这样其他的服务器才能最终知道哪些日志条目需要被提交。Follower 一旦知道某个日志条目已经被提交就会将该日志条目按顺序应用到自己的本地状态机中
日志由有序编号的日志条目组成。每个日志条目包含它被创建时的任期号每个方块中的数字并且包含用于状态机执行的命令。如果一个条目能够被状态机安全执行就被认为可以提交了如下图 Leader 决定什么时候将日志条目应用到状态机是安全的这种条目被称为是已提交的Committed。Raft 保证可已提交的日志条目是持久化的并且最终会被所有可用的状态机执行。一旦被 Leader 创建的条目已经复制到了大多数的服务器上这个条目就称为已提交的上图中的7号条目。Leader 日志中之前的条目都是已提交的包括由之前的 Leader 创建的条目。
Leader 跟踪记录它所知道的已提交的条目的最大索引值并且这个索引值会包含在之后的 AppendEntries RPC 中包括心跳中为的是让其他服务器都知道这个条目已经提交。一旦一个 Follower 知道了一个日志条目已经是已提交的它会将该条目应用至本地的状态机按照日志顺序
日志同步的概念服务器接收客户的数据更新/删除请求这些请求会落地为命令日志。只要输入状态机的日志命令相同状态机的执行结果就相同。Raft中是Leader发出日志同步请求Follower接收并同步日志最终保证整个集群的日志一致性。 在了解日志同步前先了解复制状态机的概念。复制状态机Replicated state machines是指不同节点从相同的初始状态出发执行相同顺序的输入指令集后会得到相同的结束状态。
分布式一致性算法的实现是基于复制状态机的。在Raft算法中节点初始化后具有相同初始状态。为了提供相同的输入指令集这个条件Raft将一个客户端请求command封装到一个Log Entry中。Leader负责将这些Log Entries 复制到所有的Follower节点然后节点按照相同的顺序应用commands从而达到最终的一致状态。
如果在不同日志中的两个条目有着相同日志索引index和任期号termid则所存储的命令是相同的这点是由Leader来保证的 如果在不同日志中的两个条目有着相同日志索引index和任期号termid则它们之间所有条目完全一样这点是由日志复制的规则来保证的
7.2. Leader视角
当Leader收到客户端的写请求到将执行结果返回给客户端的这个过程从Leader视角来看经历了以下步骤
本地追加日志信息Leader 节点接收到的数据处于未提交状态uncommitted并行发出 AppendEntries RPC请求Leader 节点会并发地向所有Follower节点复制数据并等待接收响应ACK等待大多数Follower的回应收到超过半数节点的成功提交回应代表该日志被成功复制到了大多数节点中committed一旦向 Client - 发出数据接收 Ack 响应后表明此时数据状态进入已提交状态Leader 节点再向 Follower 节点发通知告知该数据状态已提交在状态机上执行entry command。 既将该日志应用到状态机真正影响到节点状态appliedFollower开始commit自己的数据,此时- Raft集群达到主节点和从节点的一致回应Client 执行结果确认Follower也执行了这条command。如果Follower崩溃、运行缓慢或者网络丢包Leader将无限期地重试AppendEntries RPC直到所有Followers应用了所有日志条目
7.3. Follower视角
从Follower视角来看经历了如下步骤Follower收到日志复制请求的处理流程
Follower会使用前一个日志的任期号和日志索引来对比自己收到的数据如果相同接收复制请求回复ok否则回拒绝复制当前日志回复errorLeader收到拒绝复制的回复后继续发送节点日志复制请求不过这次会带上更前面的一个日志任期号和索引如此循环往复直到找到一个共同的任期号日志索引。此时Follower从这个索引值开始复制最终和Leader节点日志保持一致日志复制过程中Leader会无限重试直到成功。如果超过半数的节点复制日志成功就可以任务当前数据请求达成了共识即日志可 commit提交了 日志复制Log Replication有两个特点
7.4. Logs
Logs由顺序排列的Log Entry组成 每个Log Entry包含command和产生该Log Entry时的Leader Term。从上图可知五个节点的日志并不完全一致Raft算法为了保证高可用并不是强一致性而是最终一致性Leader会不断尝试给Follower发Log Entries直到所有节点的Log Entries都相同。
Index日志索引保证唯一性TermId任期Id标识当前操作在哪个任期内Action标识任期内的数据操作
在前面的流程中Leader只需要日志被复制到大多数节点即可向客户端返回而一旦向客户端返回成功消息那么系统就必须保证log在任何异常的情况下都不会发生回滚。
7.5. 日志复制的例子 从图中看LogIndex 1-4的日志已经完成同步LogIndex 5正在同步LogIndex 6还未开始同步下一小节会基于官方文档完整的描述日志复制的过程
7.6. 日志不一致
日志不一致问题在正常情况下Leader和Follower的日志复制能够保证整个集群的一致性但是遇到Leader宕机时Leader和Follower日志可能出现了不一致一般而言此时Follower相比Leader缺少部分日志。
为了解决数据不一致性Raft算法规定Follower强制复制Leader节点的日志即Follower不一致日志都会被Leader的日志覆盖最终Follower和Leader保持一致。
这个强制复制指的是即从前向后寻找Follower和Leader第一个公共LogIndex的位置然后从这个位置开始Follower强制复制Leader的日志。这里的复制动作受到下面的Raft安全性规则约束一切以数据最终一致性为前提
7.7. logs 复制时异常问题及解决
在进行一致性复制的过程中,假如出现了异常情况raft都是如何处理的呢
写入数据请求到达 Leader 节点前该阶段 Leader 挂掉不影响一致性触发重新选举重新选举出Leader写入请求到达 Leader 节点但未复制到 Follower 节点。该阶段 Leader 挂掉数据属于未提交状态Client 不会收到最终的 Ack 会认为超时失败、可安全发起重试写入请求到达 Leader 节点成功复制到 Follower 所有节点但 Follower 还未向 Leader 响应接收。若该阶段 Leader 挂掉虽然数据Follower 节点处于未提交状态uncommitted但是数据是保持一致的。重新选出 Leader 后可完成数据提交写入数据到达 Leader 节点成功复制到 Follower 的部分节点但这部分 Follower 节点还未向 Leader 响应接收。这个阶段 Leader 挂掉数据在 Follower 节点处于 未提交状态uncommitted且不一致。由于Raft 协议要求投票只能投给拥有 最新数据 的节点。所以拥有最数据的节点会被选为 Leader然后再 强制同步数据 到其他 Follower保证 数据不会丢失并 最终一致。写入数据到达 Leader 节点成功复制到 Follower 所有或多数节点数据在 Leader 处于已提交状态但在 Follower 处于未提交状态。该阶段 Leader 挂掉重新选出新的 Leader 后的处理流程和阶段 3 一样写入数据到达 Leader 节点成功复制到 Follower 所有或多数节点数据在所有节点都处于已提交状态但还未响应 Client。这个阶段 Leader 挂掉集群内部数据其实已经是 一致的Client 重复重试基于幂等策略对一致性无影响
7.8. 复制故障说明
正常操作期间Leader 和 Follower 的日志保持一致方格数字表示任期。所以 AppendEntries RPC 的一致性检查从来不会失败。但也有可能出现下图的故障 当一个 Leader 成功当选时最上面那行Follower 的状态机可能是a-f中的任何情况。Follower 可能会缺少一些日志条目如a、b可能会有一些未被提交的日志条目如c、d或者两种情况都存在e、f。例如场景 f 可能这样发生f 对应的服务器在任期 2 的时候被选举为 Leader 追加了一些日志条目到自己的日志中一条都还没提交commit就宕机了该服务器很快重启在任期 3 重新被选为 Leader又追加了一些日志条目到自己的日志中在这些任期 2 和任期 3 中的日志都还没被提交之前该服务器又宕机了并且在接下来的几个任期里一直处于宕机状态。那么新任Leader该如何同步日志呢
在Raft中Leader 通过强制 Follower 复制它的日志来解决不一致的问题。这意味着 Follower 中跟 Leader 冲突的日志条目会被 Leader 的日志条目覆盖。
Case1要使得 Follower 的日志跟自己一致Leader 必须找到两者达成一致的最大的日志条目索引最大删除 Follower 日志中从那个点之后的所有日志条目并且将自己从那个点之后的所有日志条目发送给 followerCase2选举时Leader 针对每一个 Follower 都维护了一个 nextIndex表示 Leader 要发送给 Follower 的下一个日志条目的索引。当选出一个新 Leader 时该 Leader 将所有 nextIndex 的值都初始化为自己最后一个日志条目的 index 加1上图中的 11。如果 Follower 的日志和 Leader 的不一致那么下一次 AppendEntries RPC 中的一致性检查就会失败。在被 Follower 拒绝之后Leader 就会减小 nextIndex 值并重试 AppendEntries RPC 。最终 nextIndex 会在某个位置使得 Leader 和 Follower 的日志达成一致。此时AppendEntries RPC 就会成功将 Follower 中跟 Leader 冲突的日志条目全部删除然后追加 Leader 中的日志条目如果有需要追加的日志条目的话。一旦 AppendEntries RPC 成功Follower 的日志就和 Leader 一致并且在该任期接下来的时间里保持一致
优化如果想要的话Raft协议可以被优化来减少被拒绝的 AppendEntries RPC 的个数。例如当拒绝一个 AppendEntries RPC 的请求的时候Follower 可以包含冲突条目的任期号和自己存储的那个任期的第一个 index。借助这些信息Leader 可以跳过那个任期内所有冲突的日志条目来减小 nextIndex这样就变成每个有冲突日志条目的任期需要一个 AppendEntries RPC 而不是每个条目一次。
8. 疑问和思考
3.1. 是否需要配置dfs.datanode.du.reserved
有。
因为HDFS的设计并不会在存储接近满时停止写入操作并且因为Non DFS Used存在可能会导致DFS Used 比真实的磁盘使用率小从而导致DFS Used 还没有100%但是磁盘使用率100%数据写入失败。
通常需要设置dfs.datanode.du.reserved至少预留200g根据实际情况而定并监控磁盘的使用率及时清理数据或者进行数据均衡。
9. 参考文档
Raft 协议分析与实战理论篇
