Raft & Lease机制

Posted 2021-04-27 进阶架构师

前言

之前我们学习了Paxos，（世界上只有一种一致性协议），虽然大名鼎鼎，但是确实比较难理解。Raft提供了和Paxos一致性算法相同的功能和性能，但它的算法结构更加容易理解并且更加容易构建实际的系统。大量的应用通过Raft实现一致性，像百度的Braft、TiKV-分布式数据库、etcd等等。

Raft将一致性算法分成了几个关键模块，例如领导人选举、事情处理（日志复制）、安全性。同时，包括了新的机制来允许集群成员动态变化，利用大多数保证数据安全性。

Lease机制是一种租约、承诺机制，后续会有详细的介绍与实践操作。

Raft vs Paxos

Paxos与Raft 都是为了实现一致性这个目标，不同点在于Raft在任何时候一个服务器中都可以扮演下面角色之一：

• 领导者：处理所有客户端的交互，等于数据真正提交者，一般一次只有一个领导者

• 选民：完全被动接受通知，告知要进行选举，投票

• 候选人：选举过程中提名自己的实体，一旦选举成功，就成为领导者

Raft算法分为两个阶段：

1）任何一个服务器理论上都是候选人，向其他服务器发出请求选举请求

2）其他服务器同意选举请求，回复ok响应指令。

3）候选者成为领导者，可以真正发送执行指令

4）如果该领导者宕机，则剩下的会进行新一轮选举，新的候选者变成领导者，进入下一轮

时序图如下：

Lease机制

在分布式系统环境中，Lease是授权者授予分布式环境一段时间的租约、承诺。

以缓存服务器举例说明Lease机制原理。

缓存服务器，分发NodeA服务器数据为a，颁布约期12:00,；分发NodeB服务器数据为a，约期为12：00；分发NodeC服务器数据为b，约期为12：10

此时，缓存服务器会有约定，颁发的所有lease，在所有的都失效之前，不会有更新操作。

到了12:05，此时，对于NodeA NodeB，认为数据a，已经不可信，因为缓存服务器颁发的约期已过期。会删除本地存储的数据a

到了12:11，此时，NodeC数据b，也会失效，删除本地数据。缓存服务器，检测到所有的颁发的Lease都失效，允许更新操作。

存在的问题，优化：

1. 已经过期的Lease，像NodeA 在12:05，删除本地数据之后，请求再请求到缓存，此时就查询为空，会造成缓存穿透，容易引发雪崩。我们可以通过，缓存服务器会照常传输数据，但是不颁发Lease去优化这个问题

2. 对于颁发的所有Lease不失效不更新阻塞问题，可以采用主动通知机制，主动失效策略。如果检测到有数据更新，涉及到已经颁发的节点，那么通知失效，重新颁发Lease

3. 基于资源锁定，数据a、数据b应该把资源锁定粒度缩小，控制到数据上。数据a，所有的节点都失效，即可对数据a进行新的操作

Lease实践

分布式系统中，常常通过主备来实现高可用。

如图所示，当主机宕机之后，备机会通过一些策略，进行升级为主机，接受请求者请求。

此时，就会存在一个脑裂问题。

脑裂（split-brain），指的是在一个高可用系统中，两个相互联系的节点断开联系时，本来整体系统变成独立的个体系统，会造成竞争公共资源，导致严重的系统bug。主备系统中，常常通过心跳检测策略，来实行主备机切换。心跳检测，就是造成脑裂的一个重要原因。当备机slave，开始升级成主机，提供服务，此时，主机master复活，就会分割独立，造成竞争共享资源。

有一种解决方案，为设立仲裁机制，告知，判定死亡。类似于，法庭中，案件审理，需要最终判官，裁定最终结果。

设立一个monitor监控，当主机宕机，备机slave想要切换为主机，monitor先对主机进行ping，最终如果判定主机确认死亡，才让备机切换；

主机本身，运行过程中，要短间隔周期内ping monitor slave保证都存活，如果出现异常，则不能进行业务执行，重试多次，若失败，则退出

此时，该解决方案，就会出现monitor高可用的问题。

通过我们上述聊得Lease机制，会进一步处理脑裂问题。

假设，备机已经成功切换，且正在提供服务。利用Lease，备机提供服务，且颁发Lease；此时老主机如果复活，也提供服务，也颁发Lease；此时，server1等接受服务服务器，会对Lease颁发的与本地比较，造成老主机颁发的Lease始终处于失效状态。在频繁失效，可以配置监控点触发报警机制，人工介入，让老主机放弃主机，切换为备机。

《end》