RAFT 协议---- 在迷茫中找支点

Posted 2021-04-27 AustinDatabases

大脑在一天得忙碌中，好像已经很累了，最近听到一个方法，说是能让大脑放松，当然不是刷抖音。 上面说是学习一种，和平时接触较少的知识，可以让大脑转换思维模式，继而得到休息，我不知道反正试试看了。

所以挑了一个经常挂在嘴边，但实际上一无所知的知识，RAFT。 RAFT RAFT RAFT RAFT,重要的东西说三遍，更重要的那就四遍。RAFT 协议是主导当前分布式数据库的一种新型协议，其实也没多新，相对PASOS 这样的分布式协议来说，RAFT的确属于新协议（也别问我PAXOS协议是什么，我只知道 ACID, CAP 两个理论）。

为什么要学习一下 RAFT，因为柿子的捡软的捏，PAXOS 距今26年了，大部分人给予的评价是  hard to understand , not complete enough for real implementations , 虽然很多当下的分布式系统和数据库的初始设计都是 PAXOS 协议，至少他们是这样说的。

先放弃那个25年都被评论为难缠的家伙。 学习RAFT 协议，也是对大名鼎鼎的 TIDB 的基础理论的一次学习（虽然2年前就用过，但至今没有需求让我把这个大家伙放到我的DATABASE LIST 去PUSH 惭愧）。 STOP 开始正题

首先，为什么会产生RAFT ，先说说他主要的设计目标是，更understandability , 说白了，就是更容易用人话来解释给向我这样的白痴来明白。complete foundation for implementations 具有更完整的化的指导能让他来进行部署和实践。 Different problem decomposition 我理解的就是面对不同的问题，可以做到面面俱到。

看完这些，我怎么觉得是在告诉我，PAXOS 协议就是一个，难懂，难实现，对问题不能全面解决的这么个协议，好吧继续。

RAFT协议主要针对两大块，一块是针对外部的响应的回应，另一块是对内部的一个状态的管理。

RAFT 协议中，要针对一致性来说，要有以下几点来确认

1 通过replicated log 确认所有的协议内部的个体都按照一个次序来执行命令

2 系统中要确认大多数服务单元是在正常工作中的

3 要有一个模块来确认和检验replicated log (个人理解是每个单元都要能去确认，否则就不是分布式协议了)

4 同时也要有一个能处理部分单元的失效，信息丢失，或者单元的彻底无响应

从细节上，RAFT 协议解决了 

1  Leader 选举的问题并且在同一个时间点，只有一个 leader

2  在下一个时间点，如果这个Leader失效了，则会检测并且选举出新的leader

3 Leader 接受从客户端发来的请求，并记录到日志

4 Leader 将日志复制到其他服务端，在日志的复制过程中，将可能存在的不一致情况覆盖掉。

5 保证日志的一致性，并且在一个时间点，只有更新了日志的服务端，才有机会可以在LEADER失效后，可能变为LEADER

画个图来增强理解吧！22点的脑子，的确属猪了。 

1 我们假设我们有5个节点

在第一个时刻，我们设置5个节点都预先知道，集群中有5个节点，（例如我们把IP 或者其他信息，先在每个节点上注册）

2 问题是，我们怎么能在第一时间，选出那个节点为LEADER，我们可以设置一个TIMEOUT 时间点，当然时间刻度的设置的小，例如微妙，毫秒，每个节点在的TIMEOUT 未必一致，或者说必定不一致，因为每个CPU的晶圆都不一致，所以TIMEOUT 时间点设置的足够小，则一定有一个节点会第一个达到TIMEOUT 时间点

3 当达到时间点后，例如T5 达到时间点后，将根据后已经注册号的信息，向其他的节点发送能成为LEARDR的信息申请，在每个节点都接受到后，会给他做响应，这就应验的那句话，早期的鸟儿有食吃，所以必然T5会最先得到其他节点的ACK，并马上判断出多少节点，（是否为集群的大多数节点）已经给自己回应了，则马上他就成为正式的LEARDR，

4 这里可能会有两个疑问，1 其他节点也会在TIMEOUT时发送申请，他们也会受到其他节点发送的ACK。 那他们为什么不能成为LEADER ，或者搅局。 其实还是一个快字，在T5节点得到大家的回应后，马上就自己会发送声称自己是 TEAM LEADER的包，其他节点还是在第一时间受到这个包，然后就俯首称臣了。大哥你好！！ 平身

5 接下来，就是发送REPLICATED LOG 的时间段，发号施令，所有的节点虽然不在同一个时间段接受到大哥的指令，但只要工作正常，其他节点会收到大哥的统一指令。到目前为止，多个节点都一致了。

6 然后这时，大哥突然挂了，然后又是重复上面的事情，到一个TIMEOUT时间点，又一个不怕死的节点开始发送LEADER 申请，然后被响应，最后成为LEADER。这个集群就继续工作了。

所以在这个协议中，时间成为一个节点能不能成为LEADER，一个节点到底失效没有的评判。一个集群中，在一个时间点，只有一个LEADER 其他都是FOLLWER.

根据这个理论，那集群中的LEADER失效的情况下，一定有一个时间段这个集群是没法响应客户端的请求的。

脑子目前处于失灵的 LIMITATION.

这个没有办法处理请求的时间段就是各个节点重新选举和投票的时间段。

当然这里面还有一些其他的问题，例如5个节点，有可能2个节点ACK 给 T5 ，一个节点ACK 给 T3， 那这里就要有一个 majority概念，大多数，在注册的时候，就知晓全部的节点数量，而得到ACK的时候，只要知道目前有5个节点，只要有2个给我回应 ，则我即为 LEADER，不需要在等待就可以在集群中发送确认书了。

Brain offline.