TIDB-raft学习笔记

1.是什么

raft经过集群的方式为客户提供强一致、高可用的服务。强一致表如今客户端看的都是最新的数据。高可用性表示不论是是网络故障仍是节点宕机都不会影响客户端对最新数据的获取。主要经过副本读取LOG的方式进行，根据日志中记录的操做来更新状态。
复制代码

2.工做状态

Raft在正常工做状态下如上图所示，在一个raft group中只有一个leader，由leader负责客户端对raft数据的读写，当客户端有数据写入需求的时候交给leader，而后leader经过LOG的方式将数据变化发送给其它节点(follower),只有在超过半数以上的节点确认写入的状况下才能commit而且返回给客户端成功的信息。follower和leader之间经过心跳获取各自的状态。

3.选举

在leader由于网络或者主机宕机等缘由发生故障，follower在必定时间内未收到来之leader的心跳信息，follower就会认为leader发生了故障进而启动选举程序进入candidate状态，开启新一轮任期(term=当前term+1)。首先会给本身投票一票，而后向其它节点发送拉票信息，其它的节点判断是否赞成。有以下状况会致使其余节点投拒绝票：

一、已经投过同意票了，一个节点只能投票一次

二、其它节点的term或log比发起拉票节点的高。

根据投票的状况会出现3中结果，本身赢得选举、其它节点赢得选举、未产生结果。

本身赢得选举，当一个candidate节点得到超过半数的同意票时候这个节点就赢得选举成为leader，节点的投票是根据先到先得原则进行投票的，谁先向我拉票就把票给谁。

他人赢得选举，没赢得过半票数，或者在选举的过程当中受到了leader的信息（term比本身大）那么本身就变成follower。

未产生结果，若是两个节点同时发起投票，首先本身给本身投一票，而后就没有票给其它人了，这样产生的结果就是没人得到半数选票，在这种状况下raft会要求各个节点在一个随机时间以后再次发起投票(term+1),由于两个节点发起再次投票的时间不一样，因此就不会出现没票的状况。

4.raft log格式

每条日志保存了对于的数据变动，以及日志编号和term号码。leader在发生log给follower的时候还会发送上一条日志的信息（序号和任期），若是follower发现接收到的log中记录的上一条log的信息和本身当前的不一致，说明中间存在数据差别，这个时候follower就会要求leader发生缺失的log。

5.选举的其它问题

5.1数据不一致问题

备注：不是全部的日志都已经提交 从图中能够看出，在完成了选举以后有的follower比leader的数据多，有的比leader的数据少。用f为列，看看什么状况下会发生这种状况：

在任期2的时候f为leader，这个时候写入了3条数据，可是没有提交就被下线了，在任期3的时候又上线，而后由写入了5条数据，以后由其余节点成为leader。新的leader会检查出这个数据的不一致，而后对这个不一致就行修复，具体的作法的依次向前比对数据，直到找到重合的数据为止，在图中是log=3的位置，而后从新发送log=3~10的全部数据。总结起来就是leader会要求全部的follower和本身的数据保持一致。

5.2数据覆盖

还有一种状况，可能会致使即便多个超过半数的节点已经提交了日志，依然有可能被其余新选的Leader覆盖日志

一、在a状态下，S1为leader，当前的term=2，只是完成了部分日志写入（没有同步到s3/s4/s5）,这个时候S1被下线了。

二、在b中S5被选S四、S3选举为新的leader（由于S5得到了S三、S4的选票就能够成为leader），而且S5在log=2的位置接收到了新的请求（term=3）

三、在c的状况下，S1上线同时有被选举为leader，而且在log=3的时候作了数据的写入(term=4),同时由于leader作数据校验的时候，同步了log=2（term=2）给s3，这个时候log=2的数据已经知足提交的条件了（超过半数），可是这种状况下是不能提交的。

四、假设在上述状况下发生了提交，那么若是S1再次下线，那么S5确定会被选择为leader（由于term最大），S5做为leader以后就会覆盖以前作的提交（log=2的数据）也就形成了数据异常。

五、怎么避免？能够限制leader只能提交当前term的数据，在上述的状况下，不提交log=2的数据（log=2的数据是term=2的时候写入的）提交log=4（term=4）的数据，就能够解决，由于这种状况下就算S1下线，S5也不会被选举为新的leader由于其它的节点的term比S5的term大~

6.参考

1620秒入门Raft - 知乎