raft设计服务器三种状态,RAFT协议完整笔记-上

1 整体描述

在Raft被提出来之前，Paxos协议是第一个被证明的一致性算法，但是Paxos的论文非常难懂，导致基于Paxos的工程实践和教学都十分头疼，于是Raft在设计的过程中，就从可理解性出发，使用算法分解和减少状态等手段，目前已经应用非常广泛。所以本文通过对https://github.com/maemual /raft-zh_cn/blob/master/raft-zh_cn.md这篇论文的梳理， 进行了一些归纳总结。

在Raft中，问题可以分解为：领导选取、日志复制、安全和成员变化。每一个步骤都是一个比较清晰的待解决问题， 便于理解，

接下里我们先来了解一下Raft协议中所涉及的几个基本概念。

2 基本概念

2.1 复制状态机(Replicated State Machine)

1BB4BDB869844A08A5C39DF25B673FAA.png复制状态机通过复制日志来实现：日志：每台机器保存一份日志，日志来自于客户端的请求，包含一系列的命令

状态机：状态机会按顺序执行这些命令

一致性模型：分布式环境下，保证多机的日志是一致的，这样回放到状态机中的状态是一致的

一致性算法作用于一致性模型，一般有以下特性：safety：在非拜占庭问题下(网络延时，网络分区，丢包，重复发包以及包乱序等)，结果是正确的

availability：在半数以上机器能正常工作时，则系统可用

timing-unindependent：不依赖于时钟来保证日志一致性，错误的时钟以及极端的消息时延最多会造成可用性问题

注意：真实的实现中，建议状态机的每个命令操作都采用幂等的，这样一致性的保证会更容易。

2.2 服务器状态

每台服务器一定会处于三种状态：1.领导者

2.候选人

3.追随者

image.png

追随者只响应其他服务器的请求。如果追随者没有收到任何消息，它会成为一个候选人并且开始一次选举。收到大多数服务器投票的候选人会成为新的领导人。领导人在它们宕机之前会一直保持领导人的状态。

2.3 任期(Term)

Raft

算法将时间划分成为任意不同长度的任期(term)。任期用连续的数字进行表示。每一个任期的开始都是一次选举(election)，一个或多个候选人会试图成为领导人。如果一个候选人赢得了选举，它就会在该任期的剩余时间担任领导人。在某些情况下，选票会被瓜分，有可能没有选出领导人，那么，将会开始另一个任期，并且立刻开始下一次选举。Raft

算法保证在给定的一个任期最多只有一个领导人。

image.png

2.4 RPC

Raft 算法中服务器节点之间通信使用远程过程调用(RPCs)，并且基本的一致性算法只需要两种类型的 RPCs。请求投票(RequestVote) RPCs

由候选人在选举期间发起，然后附加条目(AppendEntries)RPCs

由领导人发起，用来复制日志和提供一种心跳机制。为了在服务器之间传输快照增加了第三种 RPC。当服务器没有及时的收到 RPC 的响应时，会进行重试，

并且他们能够并行的发起 RPCs 来获得最佳的性能。

RPC有三种：1.RequestVote RPC：候选人在选举期间发起

2.AppendEntries RPC：领导人发起的一种心跳机制，复制日志也在该命令中完成

3.InstallSnapshot RPC: 领导者使用该RPC来发送快照给太落后的追随者。

超时设置：1.BroadcastTime : 领导者的心跳超时时间

2.Election Timeout: 追随者设置的候选超时时间

3.MTBT :指的是单个服务器发生故障的间隔时间的平均数

Raft协议对物理是时钟一致性没有要求，不需要通过原子钟NTP来校准时间，但是对于超时时间的设置有要求，具体规则如下：

BroadcastTime << ElectionTimeout << MTBF

两个原则：1. BroadcastTime应该比ElectionTimeout小一个数量级，为的是使领导人能够持续发送心跳信息(heartbeat)来阻止追随者们开始选举；

2. ElectionTimeout也要比MTBF小几个数量级，为的是使得系统稳定运行。

一般BroadcastTime大约为0.5毫秒到20毫秒，ElectionTimeout一般在10ms到500ms之间。大多数服务器的MTBF都在几个月甚至更长。