raft一致性协议

最新推荐文章于 2025-04-30 15:48:31 发布

天府二街的it打工仔

最新推荐文章于 2025-04-30 15:48:31 发布

阅读量3.3k

点赞数 6

文章标签： raft算法分布式 java

本文链接：https://blog.youkuaiyun.com/qq_38997816/article/details/121937817

版权

本文主要参考大佬文章深入理解raft协议，并适当修正了其中自认为表述有误差的地方。

1、一致性协议说明：

布式存储系统通常通过维护多个副本来进行容错，提高系统的可用性。要实现此目标，就必须要解决分布式存储系统的最核心问题：维护多个副本的一致性。这里说的是强一致性

首先需要解释一下什么是一致性（consensus）,它是构建具有容错性（fault-tolerant）的分布式系统的基础。在一个具有一致性的性质的集群里面，同一时刻所有的结点对存储在其中的某个值都有相同的结果，即对其共享的存储保持一致。集群具有自动恢复的性质，当少数结点失效的时候不影响集群的正常工作，当大多数集群中的结点失效的时候，集群则会停止服务（不会返回一个错误的结果）。

共识算法（Consensus Algorithm）就是用来做这个事情的，它保证即使在小部分（≤ (N-1)/2）节点故障的情况下，系统仍然能正常对外提供服务。共识算法通常基于replicated state machines，即所有结点都从同一个state出发，都经过同样的一些操作序列（log），最后到达同样的state。
在这里插入图片描述

系统中每个结点有三个组件：

状态机：当我们说一致性的时候，实际就是在说要保证这个状态机的一致性。状态机会从log里面取出所有的命令，然后执行一遍，得到的结果就是我们对外提供的保证了一致性的数据
Log：保存了所有修改记录
一致性模块：一致性模块算法就是用来保证写入的log的命令的一致性，这也是raft算法核心内容

2、raft协议（Understandable Distributed Consensus）

Paxos是最先提出和被证明的分布式一致性算法，后续的算法都是基于它发展而来的，但是它难以理解，存在诸多限制难实现。

Raft协议是Paxos的扩展，工程可实现的。它分成3个部分来增加可理解性，分别是领导人选举、日志复制和安全性。

领导人选举，Raft协议规定集群中必须有且只有一个领导者，客户端所有的读写请求最终都是发给领导人来处理的。在没有领导人的情况下，集群不对外提供服务。所以领导人选举是首要要解决的问题。
日志复制，一致性算法是从复制状态机的背景下提出的，复制状态机通常都是基于复制日志实现的。在整个集群中，通过日志按顺序执行，来保证集群中节点上的数据最终都是一致的。保证复制日志相同就是一致性算法的工作，所以协议针对日志复制，定义了一系列需遵守的规范。
安全性限制，因为主节点的责任是如此之大，所以节点们在选主的时候一定要谨慎，只有符合条件的节点才可以当选主节点。此外主节点在处理操作日志的时候也一定要谨慎，为了保证集群对外展现的一致性，不可以覆盖或删除前任主节点已经处理成功的操作日志。所谓的“谨慎处理”，其实就是在选主和提交日志的时候进行一些限制，这一部分在 Raft 核心算法中叫安全性（Safety）。

2.1 领导人选举（Leader election）

2.1.1 节点角色

Raft 集群中每个节点都处于以下三种角色之一：

Leader: 所有请求的处理者，接收客户端发起的操作请求，写入本地日志后同步至集群其它节点。
Follower: 请求的被动更新者，从 leader 接收更新请求，写入本地文件。如果客户端的操作请求发送给了 follower，会首先由 follower 重定向给 leader。
Candidate: 如果 follower 在一定时间内没有收到 leader 的心跳，则判断 leader 可能已经故障，此时启动 leader election 过程，本节点切换为 candidate 直到选主结束。

2.1.2 任期

每开始一次新的选举，称为一个任期（term），每个 term 都有一个严格递增的整数与之关联。

每当 candidate 触发 leader election 时都会增加 term，如果一个 candidate 赢得选举，他将在本 term 中担任 leader 的角色。但并不是每个 term 都一定对应一个 leader，有时候某个 term 内会由于选举超时导致选不出 leader，这时 candicate 会递增 term 号并开始新一轮选举。
在这里插入图片描述