Raft客户端实现要点

Posted 码洞

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Raft客户端实现要点相关的知识,希望对你有一定的参考价值。

消息重复

客户端消息处理最困难的一点在于消息可能会重复。比如客户端向Leader发送了一条指令,Leader收到了这条指令并执行了,但是连接在响应返回之前断开了。客户端没有收到回复,所以接下来会重连然后重新发送这条指令。这时服务器就必须想办法去重。

消息去重

去重意味着客户端的消息必须有编号,服务器会记录这些编号,以便重复消息过来的时候,可以判断是否已经处理过了。
如果已经处理过了,会缓存响应内容。这时重复消息过来了,可以直接将响应内容返回给客户端而不需要进行重复处理。如果消息正在处理中,那么等消息处理结束,直接一块响应即可。

会话

服务器会为每个客户端连接维持一个回话session,记录客户端的交互状态。每个客户端回话会被赋予一个唯一ID。当连接不小心断开,通过重连还可以挂接到之前的session对象,因为客户端会将回话的ID记录在内存中。如果断开的时间较久,服务器的回话会过期,客户端带着回话ID进行再重连交互时,服务器会返回回话过期异常。这时客户端需要再注册一个新回话,并抛弃之前回话中的所有消息,重新进行交互。

回话期间的消息采用序列号进行唯一标识,序列号相同的消息是重复的消息,每生成一个新的消息,序列号递增。

会话过期

回话不可能永远持续下去,考虑到内存的上限,回话是需要过期的。回话的过期也必须通过日志协商,否则系统的一致性就很难满足。比如在一个特定的时间点,某个客户端的回话对象在一个节点上是活的,在另一个节点上是过期的。没有过期的回话对象内部还存储了最近客户端的指令ID。这个时候需要将已经提交的日志apply到状态机。这个apply的过程要检查指令的重复与否。这个重复检查的结果在两个节点上就可能是不一样的,紧接着会导致两节点的状态机数据出现不一致。

回话的过期一般有两种策略。第一种是限定session的数量,通过LRU算法来淘汰陈旧的session。另外一种是通过协商一致的时间源来过期。不同的节点需要在日志的时间上达成一致,这样才可以在apply相同的日志时有相同的时间,回话过期也就会有相同的结果。在时间上达成一致一般是以Leader在日志里放入自身的当前时间戳做到的,其它节点就是通过这个时间戳来作为时间源来决定回话的过期与否。

标准raft协议里没有提到回话的主动过期,比如客户端主动退出,此时应该可以允许客户端在连接断开之前发送一个RemoveClient的指令,注销当前的回话,及时给服务器腾出空间来。

以上是关于Raft客户端实现要点的主要内容,如果未能解决你的问题,请参考以下文章

raft协议的一些要点

从Paxos幽灵复现谈Raft实现原理

raft算法浅析

知识贴:分布式算法Raft

优化一致性算法,从学会Raft开始?

Raft论文