Raft & Lease机制

简介: Raft & Lease机制

前言

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

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

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

Raft vs Paxos

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

  • 领导者:处理所有客户端的交互,等于数据真正提交者,一般一次只有一个领导者
  • 选民:完全被动接受通知,告知要进行选举,投票
  • 候选人:选举过程中提名自己的实体,一旦选举成功,就成为领导者


Raft算法分为两个阶段:

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

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

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

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


时序图如下:

image.png

Lease机制

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

image.png

以缓存服务器举例说明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实践

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

image.png

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

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

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

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

image.png

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

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

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

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

image.png

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

《end》

目录
相关文章
|
消息中间件 存储 算法
聊聊raft
聊聊raft
|
3天前
|
消息中间件 算法 网络协议
选举机制理解描述
选举机制理解描述
10 1
选举机制理解描述
|
4月前
|
算法
Bully、Raft、Zab选举算法的差异比较
Bully算法、Raft算法、Zab的差与异。他们如何脱胎于Paxos而成?
|
4月前
|
索引
Etcd/Raft 原理问题之follower会进入StateReplicate状态时的问题如何解决
Etcd/Raft 原理问题之follower会进入StateReplicate状态时的问题如何解决
Etcd/Raft 原理问题之follower会进入StateReplicate状态时的问题如何解决
|
4月前
|
存储 缓存 监控
Etcd/Raft 原理问题之Etcd-Raft节点故障问题如何解决
Etcd/Raft 原理问题之Etcd-Raft节点故障问题如何解决
|
4月前
|
存储 算法 开发工具
Etcd/Raft 原理问题之Etcd-Raft是什么
Etcd/Raft 原理问题之Etcd-Raft是什么
|
4月前
Etcd/Raft 原理问题之etcd/raf配置变更t问题如何解决
Etcd/Raft 原理问题之etcd/raf配置变更t问题如何解决
|
监控 NoSQL 算法
从哨兵Leader选举学习Raft协议实现(上)
从哨兵Leader选举学习Raft协议实现(上)
93 0
Zookeeper Leader选举机制
Zookeeper Leader选举机制
80 0
|
算法
实现分布式 kv—2 raft leader 选举
raft 是一个分布式一致性算法,主要保证的是在分布式系统中,各个节点的数据一致性。raft 算法比较复杂,因为它所解决的分布式一致性问题本来就是一个比较棘手的问题,raft 算法的实现主要可以拆解为三个部分: • 领导选举 • 日志复制 • 安全性
129 2