raft协议学习笔记

注,需要注意的是raft是个默认消息可靠,但是不提防消息有害的系统。

(一). 共识机制有2种:
一种是leader-less(对称的),即没有leader,大家都是平等的,客户端可以连接任意的节点。
一种是leader-base(非对称的),即有leader,在任意的某个时间点,只有一个leader,其他的节点接受leader的决定。客户端只和leader 节点发生交互。

raft是属于leader-base的共识机制。注意raft是一种协议,那么它就不是一种公式,而是一种分布式系统达成共识的各种条件的约定。

(二)节点状态:
Server states
节点的状态有3种,一个是叫follower,一个是candidate,一个是叫leader。各自角色的作用,有如下约定:
(1)leader:会处理来自所有客户端的交互请求,会记录复制的进度,同一时刻,集群中只会有一个leader。
(2)follower:完全被动,不发起RPC请求(Remote Procedure Call,即远程过程调用请求),只是回应RPC请求。
(3)candidate:用于选举leader。

开始的时候,所有节点的状态为follower(后续简称为F),节点在规定的时间内,没有收到来自leader(后续简称为L)的RPC请求,发起投票,先是让自己成为candidate(后续简称C)。
在某一时刻,可能存在多个C,这些C是从F变过来的,从C变成F的时间,各个节点也不尽相同,有些可能久一点,有些可能短一点;各个C也会在不同的瞬间发起投票;而发给F的路径长度不一样,可能收到F的反馈的时间点也不一样。
如果在某个选举的时间单位内,C收到了大部分节点的同意的信息,那么C就变成L,如果没有收到信息,那么发起下来一轮任期的投票。

(三)任期(Term)
raft将时间划分成一个一个的任期。一个是选举期间,一个是常规操作的时间(此时只有一个L)。
有些term是没有L的,
每个节点都保留这当前的任期值。
raft term
所以,一开始,大家都是F,一开始是出于选举阶段的(蓝色),等选出了L,进入了常规操作时间(绿色),当出现超时或者故障的时候,此时就进入了投票阶段,节点们会发起投票,最后投票结束,又进入了常规操作阶段。
在Term1,需要从F开始选举,所以蓝色部分比较长;在Term2,此时已经有了L,所以只需要确认L和F之间的心跳,所以蓝色比较短;在Term3,L挂掉需要重新投票,新节点获取投票成为L后,进入Term4;Term5和Term2一样。

(四)节点信息持久化
1. 每个节点会以同步的方式,在回应RPC之前,持久化如下信息:
Persistent state
这个可以看出是不是像一个小型的数据库?有日志(记录历史term和command),有数据(current term和votefor)?

2. 不用持久化的信息:
Non-persistent state

(五)心跳和timeout:
1. RPC请求包括两种类型的RPC请求,一种是AppendEntries,如写日志,如发送心跳,是有L发出来的;一种是VOTE,是由C发出来的。
timeout分成两种,第一种是(待补充,见http://thesecretlivesofdata.com/raft/)
2. 初始状态,大家都是F
3. F期望收到的是来自C或L的RPC请求
4. L必须不停的发送AppendEntries来维持自己的领导地位
5. 如果在选举时间(通常是100-500ms)内,L没有收到RPC请求,那么F就认为L已经死掉,F会开始一个新的选举。

(六)选举:
F选举时,会先设定一个超时的时间,是∆election到2倍的∆election时间之间。
会递增当前的Term的值。
F的状态会变成C。并且投票的第一票是给自己。并且给其他所有的节点发送VOTE的RPC请求。然后:
1. 如果在timeout内收到了大部分节点的回应,则这自己成为L。并且发送AppendEntries 给其他所有节点。
2. 如果别的节点已经成为了L,此时从别的节点收到AppendEntries的请求,则自己降成F。
3. 如果从其他节点没有收到任何消息,timeout,则重新发起选举。
4. 当选举完成之后,如果保证选举正确?
4.1 Safty(允许在一个Term内,最多只有一个L):
(a)每个节点在每次term内,只投出一票。
(b)2个不同的C,不能在同一个的term内累积“大多数”的投票。
4.2 Liveness(一些C必须最终获胜)
(a)election timeouts是随机的,(在∆election到2倍的∆election之间)
(b)在其他节点醒来之前,一个先发起的节点通常会timeout,并且赢得选举。
(c)如果∆election >> broadcast time,这种Liveness的机制将会工作的很好。

(七)日志的结构:
1. log是被持久化在磁盘上,用于crash恢复
2. commited的意思是,被大多数节点已经写入。
3. 最终一致性
Log structure
可以从上图看到日志的结构,包含2部分,一部分是term的值,一部分是command的历史信息。

(八)常规操作:
1. 客户端将command传给L
2. L将command写日志
3. L将AppendEntries的RPC请求发给F
4. 一旦新条目commit,L将command传自己的状态机,向客户端返回结果。L在后续AppendEntries的RPC请求中告诉告诉F,被commit的条目。F将commit命令发给自己的状态机。
5. 遇到crash或者slow的客户端,L会一直尝试发送直到成功。通常情况下的性能最佳:一个成功的RPC请求给大多数个节点。

(九)一致性
1. 什么是日志的一致性:所有的节点的日志,都有一样的index和term;如果某个给定的条目是已经commit的了,那么前面的所有的条目也是commit的。
如下图所示,数字123456是代表log index,所有的节点,都有一样的index和term,且某个给定的条目,如index=4,T2的条目,已经是commit的,那么之前的条目也都是commit的。
Consistency in logs

2. 什么是AppendEntries的一致性检查:每个AppendEntries的RPC请求,都包含需要处理的新的index和term;F必须包含有相符合的条目,不然就拒绝新来的AppendEntries请求;将上述步骤实施递归步骤,确保一致性。
如下图所示,每个新来的AppendEntries RPC请求,都包含了index和term,且在下面的第二个图中,由于F包含的条目和L不一致,所以会拒绝log index=5的新的AppendEntries的请求。
AppendEntries Consistency

(十)Leader的产生
1. L产生的开始:
1.1 旧的L可能会留下一下部分被同步的条目
1.2 新的L只是做“常规操作”,并不会做一些特别的动作。
1.3 L的日志,是“真理”,会以L的日志为准。
1.4 F的日志最终会到达和L一致。最终一致性。
1.5 多次崩溃可能会留下许多无关的日志条目。
At beginning of new leader’s term

2. Safty的要求:
2.1. 如果L已确认某个log条目是已经commit了的,则该条目将出现在所有未来L的日志中
2.2. L不会覆盖写日志的条目:只有在L的日志中的条目,才能被commit;日志条目只有commit之后,才会被同步到其他节点。
2.3. 集群成员数量改变,每次只变一台,不同时变多台。即使有,在内部操作时也是拆成一台一台的改变。如果同时改变多台,可能出现脑裂的情况,同一时刻有老配资的leader和新配置的leader,两个leader。

2.4. 集群成员数量改变,采用两阶段方法变动(即存在同时为C-old和C-new,老配置和新配置同时生效的时刻)。

关注dbDao.com的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569