分布式一致算法Raft的简单理解

最新推荐文章于 2023-02-27 20:39:49 发布

爱逛街的老鼠

最新推荐文章于 2023-02-27 20:39:49 发布

阅读量311

点赞数

分类专栏：算法文章标签：分布式算法 zookeeper

本文链接：https://blog.csdn.net/dsfdasfka/article/details/123007268

版权

算法专栏收录该内容

3 篇文章 0 订阅

订阅专栏

分布式一致算法Raft

Raft算法是可以用来代替Paxos算法的分布式一致算法。这是一个用来管理复制日志（replicated log）。
一致性算法是在复制状态机的背景下产生的。在这种方法中，一组服务器上的状态机计算相同状态的相同副本并且即使某些服务器宕机，也可以继续运行。一致性算法的工作就是保证复制日志的一致性。

前提

一致性算法允许多台机器作为一个集群协同工作，并且在其中的某几台机器出故障时集群仍然能正常工作。一致性算法的工作就是保证复制日志的一致性。每台服务器上的一致性模块接收来自客户端的命令，并将它们添加到其日志中。它与其他服务器上的一致性模块通信，以确保每个日志最终以相同的顺序包含相同的命令，即使有一些服务器失败。一旦命令被正确复制，每个服务器上的状态机按日志顺序处理它们，并将输出返回给客户端。实际系统的一致性算法通常具有以下属性：

它们可以在所有非拜占庭条件下（不限于网络延迟、分区、数据包丢失、重复和乱序）的安全性。（状态机拜占庭系统的特点是整个系统共同维护一个状态,所有节点采取一致的行动）
只要任何大多数（过半）服务器可以运行，并且可以相互通信与客户通信，一致性算法就可用。
不依赖于时序来确保日志的一致性：错误的时钟和极端的消息延迟在最坏的情况下会导致可用性问题。
在通常情况下只要集群大多数服务器（过半）已经已经响应了单轮远程过程调用，命令就可以完成; 少数（一半以下）慢服务器不会影响整个系统性能。

除此之外，Raft算法对比其他几个算法具有以下的新特性：

Strong leader：在Raft中，日志条目（log entries）只从leader流向其他服务器。这简化了复制日志的管理，使得raft更加容易理解。
Leader选举：Raft 使用随机计时器进行 leader 选举。这只需在任何一致性算法都需要的心跳（heartbeats）上增加少量机制，同时能够简单快速地解决冲突。
成员变更：Raft 使用了一种新的联合一致性方法，其中两个不同配置的大多数在过渡期间重叠。这允许集群在配置更改期间继续正常运行。

Raft一致算法

基础

一个 Raft 集群包含若干个服务器节点（一般可以包含5个）。在任何时刻，每个服务器都处于三个状态之一：leader、follower或者candidate。在正常情况下，集群中只有一个 leader 并且其他的节点全部都是 follower。

Raft 把时间分割成任意长度的任期（term），raft保证了在任意一个任期内，最多只有一个 leader 。每一个服务器节点存储一个当前任期号，该编号随着时间单调递增。服务器之间通信的时候会交换当前任期号；如果一个服务器的当前任期号比其他的小，该服务器会将自己的任期号更新为较大的那个值。

Raft 算法中服务器节点之间使用 RPC 进行通信，并且基本的一致性算法只需要两种类型的 RPC。请求投票（RequestVote） RPC 和追加条目（AppendEntries）RPC。

leader 选举

Raft 使用一种心跳机制来触发 leader 选举并且 Leader 周期性地向所有 follower 发送心跳（不包含日志条目的 AppendEntries RPC）来维持自己的地位。以下为选举的步骤：

follower 先增加自己的当前任期号并且转换到 candidate 状态。然后投票给自己并且并行地向集群中的其他服务器节点发送 RequestVote RPC（让其他服务器节点投票给它）。
当一个 candidate 获得集群中过半服务器节点针对同一个任期的投票，它就赢得了这次选举并成为 leader。每个服务器节点只会投给一个 candidate ，按照先来先服务（first-come-first-served）的原则。
赢得选举的candidate成为leader然后向其他的服务器节点发送心跳信息来确定自己的地位并阻止新的选举。
如果在本次选举中没有leader产生，那么通过增加当前的任期号开启新一轮的选举。

为了避免无限期的重复选举过程，raft使用随机选举超时的方法。选举超时时间是从一个固定的区间（例如 150-300 毫秒）随机选择。这样可以把服务器都分散开以至于在大多数情况下只有一个服务器会选举超时；然后该服务器赢得选举并在其他服务器超时之前发送心跳。

日志复制

当leader被选举出来后，就开始为客户端请求提供服务。客户端的每一个请求都会包含一条将被复制状态机执行的指令。leader就会把这个指令作为一个新的条目追加到日志中去，然后并行的发起AppendEntries RPC，让他们复制该条目，当大多数服务器都已经完成复制，leader就会应用该条目到状态机中，并返回结果给客服端。（若follower故障，会不断重试）

如果不同日志中的两个条目拥有相同的索引和任期号，那么他们存储了相同的指令。
如果不同日志中的两个条目拥有相同的索引和任期号，那么他们之前的所有日志条目也都相同。

正常操作期间，leader 和 follower 的日志保持一致，所以 AppendEntries RPC 的一致性检查从来不会失败。然而，leader 崩溃的情况会使日志处于不一致的状态。这时候在raft算法中，leader 通过强制 follower 复制它的日志来解决不一致的问题。先删除follow中不一致的日志条目，然后追加leader中新的日志条目。（Leader从来不会覆盖或者删除自己的日志条目）

注：每个日志条目都有一个整数索引值来表明他在日志中的位置。

Follower 和 candidate崩溃

如果 follower 或者 candidate 崩溃了，那么后续发送给他们的 RequestVote 和 AppendEntries RPCs 都会失败。Raft 通过无限的重试来处理这种失败

安全性

Raft 使用了一种更加简单的方法，它可以保证新 leader 在当选时就包含了之前所有任期号中已经提交的日志条目，不需要再传送这些日志条目给新 leader 。这意味着日志条目的传送是单向的，只从 leader 到 follower，并且 leader 从不会覆盖本地日志中已经存在的条目。如果一个candidate没有包含所有的提交日志条目，它是不会当选为leader的。除此之外，如果要赢得选举，候选者必须与集群中超过半数的节点通信。Raft 通过比较两份日志中最后一条日志条目的索引值和任期号来定义谁的日志比较新。