关于Raft的一些问题解答

关于Raft的一些问题解答,第1张

关于Raft的一些问题解答

原文链接:https://segmentfault.com/a/1190000038171007

一、客户端如何找到Leader

Raft算法规定客户端将所有请求发送给Leader。客户端启动的时候,如何知道哪一个节点是Leader呢?具体办法是客户端随机挑选一个服务器进行通信,如果客户端选的服务器不是领导人,那么被挑选的服务器会拒绝客户端的请求,并且提供它最近接收到的领导人的信息,即通过收到Leader发送的心跳的RPC得到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因此提交日志并应用到状态机中。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5654104.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-16
下一篇 2022-12-16

发表评论

登录后才能评论

评论列表(0条)

保存