RAFT协议（算法）

一、RAFT 协议介绍

RAFT（Reliable and Available Distributed Fault-Tolerant Consensus Protocol）是一种用于管理复制状态机的分布式一致性算法。（也有RAFT共识别算法的叫法）它旨在提供一种易于理解和实现的方法，以确保在分布式系统中多个节点能够就某个状态达成一致。

RAFT 将分布式系统中的节点分为三种角色：领导者（Leader）、跟随者（Follower）和候选人（Candidate）。节点在不同的情况下会转换角色，以实现系统的一致性和高可用性。

二、RAFT 协议的作用

1. 实现分布式一致性

   • 在分布式系统中，由于节点可能会出现故障、网络延迟等问题，不同节点上的数据可能会出现不一致的情况。RAFT 协议通过选举领导者、日志复制等机制，确保所有节点上的数据最终保持一致。

   • 例如，在一个分布式数据库系统中，RAFT 可以确保各个节点上的数据副本始终保持一致，即使部分节点出现故障，系统仍然能够正常运行。

2. 提供高可用性

   • RAFT 协议通过领导者选举和日志复制机制，保证系统在部分节点出现故障时仍然能够正常工作。当领导者出现故障时，其他节点会自动发起选举，选出新的领导者，继续提供服务。

   • 例如，在一个分布式存储系统中，如果某个存储节点出现故障，RAFT 可以确保其他节点能够继续提供数据存储和访问服务，不会因为单个节点的故障而导致整个系统瘫痪。

3. 简化分布式系统的设计和实现

   • RAFT 协议的设计相对简单，易于理解和实现。它提供了明确的角色划分和状态转换规则，使得开发人员可以更容易地构建分布式系统。

   • 例如，开发人员可以使用现有的 RAFT 实现库，快速构建一个高可用的分布式系统，而不需要从头开始设计和实现复杂的分布式一致性算法。

三、RAFT 协议的适用场景

1. 分布式数据库系统

   • 在分布式数据库系统中，需要确保各个节点上的数据副本保持一致，以提供高可用性和数据可靠性。RAFT 协议可以用于实现数据库的复制和一致性管理，确保数据在多个节点之间的一致性。

   • 例如，CockroachDB、TiKV 等分布式数据库系统都使用了 RAFT 协议来实现数据的复制和一致性管理。

2. 分布式存储系统

   • 分布式存储系统需要保证数据的可靠性和高可用性，RAFT 协议可以用于实现存储节点之间的数据复制和一致性管理。

   • 例如，Etcd、Consul 等分布式存储系统都使用了 RAFT 协议来实现数据的复制和一致性管理。

3. 分布式协调服务

   • 在分布式系统中，需要一种协调服务来管理各个节点的状态和任务分配。RAFT 协议可以用于实现分布式协调服务，确保各个节点之间的状态一致。

   • 例如，Apache Zookeeper 是一个广泛使用的分布式协调服务，它使用了一种类似 RAFT 的协议来实现数据的复制和一致性管理。

总之，RAFT 协议是一种用于管理复制状态机的分布式一致性算法，它可以实现分布式系统中的一致性和高可用性，简化分布式系统的设计和实现。RAFT 协议适用于分布式数据库系统、分布式存储系统、分布式协调服务等场景。

四、深入了解

作用，解决分布式环境下，数据不一致的问题

角色：leader、follower、candidate

一开始都为follower，开始选举，先超时的节点进入Candidate，投票选举成为Leader，Leaders上进行用户写操作，将更新日志发送给其他节点。

follower：Follower是请求的被动更新者，从Leader接收更新请求，将日志 入本地文件中。

candidate：如果Follower在一定时间内，没有收到Leader的心跳则判断Leader可能已经发生故障（或还没有选举），此时启动Leader Election过程，本节点切换为Candidate（向各个节点发起投票），直到选主结束。

Leader：所有请求的处理者，接收客户端发起的操作请求，写入 本地日志后，同步至其它Follower节点。

概念：

• Term（任期）值：用于标识Raft协议中的领导者选举周期和日志的一致性。它有助于节点识别领导者的有效性和日志的来源。

• Index（索引）值：用于标识日志条目在日志中的位置，确保日志条目的顺序一致性和日志的正确回放。

Leader选举

Failover 是指在集群中的某个节点发生故障后，系统自动将领导角色（Leader）转移到一个新的节点的过程

S2节点先超时的成为Candidate（term+1），发起投票，每个节点赞同并设置term为S2节点。（赞成票超过节点数一半）S2成为Leader。

Failover过程

S2宕机了，重新选举。

投票分裂

S1和S5同时超时成为Candidate，发起投票后，票数一样（此时除了宕机S2term为2，其他都为4），也会向宕机的S2发起投票，直到另一个节点S3超时term+1，为5最大，都投票给他

日志复制过程

（当前S1为Leader，S2为follow，其他宕机）

S1写入本地后，发起更新日志过程，待，半数节点收到后，才提交。多个日志一个一个发送请求，和日志修改状态分开提交。

修复日志不一致问题

没有leader就选举，有就进行一致性检查，都和自己保持一致

如何保证数据安全性

通过比较日志的term和index大小确定日志的新旧，避免数据少的节点成为leader。先比较term再index

参考：动画：Raft算法Leader选举、脑裂后选举、日志复制、修复不一致日志和数据安全_哔哩哔哩_bilibili