Raft算法之客户端交互篇

Posted 2021-04-27 程序员升级之路

一、客户端如何找到Leader

还有一种情况，如果领导人已经崩溃了，那么客户端的请求就会超时，客户端之后会再次重试随机挑选服务器的过程。

二、如何确保命令只执行1次

Raft算法是可能多次执行同一条命令的，官方也举了一个例子：

如果领导人在提交了这条日志之后，但是在响应客户端之前崩溃了，那么客户端会和新的领导人重试这条指令，导致这条命令就被再次执行了，因为日志已经提交，只是这个响应没有被发送到客户端。

解决方案

客户端对于每一条指令都赋予一个唯一的序列号，状态机跟踪每条指令最新的序列号和相应的响应。如果接收到一条指令，它的序列号已经被执行了，那么就立即返回结果，而不重新执行指令。

即由状态机来保证不重复执行，因为这不是Raft算法中的内容，而是如何保证幂等性了，行业内也有很多方案，大概原理都是为请求生成唯一ID，然后服务端判重，这里不详述了。

三、如何100%保证不脏读

前面说了所有读、写请求都发送Leader，那是不是意味着从Leader发起读请求的时候就不用做什么处理，可以直接返回了？这里可能有脏读的情况，我们来举个例子：

当前集群有5个节点：A、B、C、D、E

假设当前Leader是A，现在因为网络原因导致网络分区，变成如下：

现在分成2个网络：A、B所在网络与C、D、E的网络不通，因为C、D、E与A所在网络不通，因此C、D、E会触发选举，并且节点数为3，满足集群节点多数的条件，因此可以选举出Leader；

如果此时客户端有新的请求发到右边的新集群，假设是一个修改key为test的操作并且提交了，而此时同样一个客户端请求发到A，读取key也为test，因为右边集群已经有新操作了，直接从A的状态机里返回数据就是旧的了。

针对这个问题，官方给的方案是需要额外2个额外的措施来保证：

1、领导人必须有关于被提交日志的最新信息

即在它的任期里必须马上提交一条空白的日志条目，即心跳；

这段话的意思是在一个节点成为Leader之前，至少向多数节点发送一次心跳来进行确认日志情况，在没收到心跳响应之前是不能响应客户端的；

2、领导人在处理只读的请求之前必须检查自己是否已经被废除了

具体实现是Leader在响应只读请求之前，先和集群中的大多数节点交换一次心跳信息来处理这个问题，即发送一次心跳的RPC，收到响应无误之后才能返回给客户端，即每次读请求要和多数成员做一次心跳以确认自己仍然是 Leader。 

回到上面的案例，因为网络分区了，客户端请求A的时候，A向成员发送心跳时，只有B能响应，没有达到多数成员的要求，因此不能响应给客户端。

上面这种情况也叫ReadIndex，有兴趣的同学可以了解下相关实现。

四、一次请求完整交互

最后以一次完整的客户端请求来总结整个过程，包括客户端发送请求和Leader在什么时候响应；假设集群有3个节点：A、B、C，其中A当前为Leader，一次完整的请求的过程如下：

1、客户端提交到请求至Leader；

2、Leader自己先保存日志，注意这里不提交；

3、Leader将日志同步给Follower，这里只画了1条线，即只同步给C，实际上是都会同步；

4、Follower收到日志后保存日志并响应给Leader；

5、Leader只要收到一个Follower的响应后马上将这条日志提交并应用到状态机中；

6、Leader应用到状态机完成后就可以返回给客户端了；

上图中后续的流程没有画，即Follower在什么时候提交日志，答案是Leader在下一次心跳的时候会将最新的commitIndex带上，Follower因此提交日志并应用到状态机中。