分布式协议与算法实战
2021-06-18 14:25:07 1 举报
AI智能生成
分布式协议
作者其他创作
大纲/内容
分布式协议与算法实战
理论
链路
分布式算法四度空间
拜占庭容错
拜占庭错误是莱斯利兰百特在《拜占庭将军问题》提出一个错误模型,描述了一个完全不可信的场景,除了存在故障的行为,还存在恶意行为,顾名思义,拜占庭容错(Byzantine Fault Tolerance,BFT),就是指能容忍拜占庭错误了
非拜占庭容错,又叫故障容错(Crash Fault Tolerance,CFT),解决的是分布式系统中存在故障,但不存在恶意节点的共识问题,比如进程奔溃,服务器硬件故障等等。
一般而言,在可信环境(比如企业内网)中,系统具有故障容错能力就可以了,常见的算法有二阶段提交协议(2PC)、TCC(Try-Confirm-Cancel)、Paxos 算法、ZAB 协议、Raft 算法、Gossip 协议、Quorum NWR 算法。
而在不可信的环境(比如有人做恶)中,这时系统需要具备拜占庭容错能力,常见的拜占庭容错算法有 POW 算法、PBFT 算法。
一致性
分类
强一致性
保证写操作完成后,任何后续访问都能读到更新后的值
弱一致性:写操作完成后,系统不能保证后续的访问都能读到更新后的值。
最终一致性:保证如果对某个对象没有新的写操作了,最终所有后续访问都能读到相同的最近更新的值。
首先,在埃里克·布鲁尔的猜想中,CAP 中的强一致性(也就是 C)是指 ACID 的 C,系统状态的一致性,而这种一致性,可以通过二阶段提交协议来实现。其次,在 CAP 定理中,CAP 中的强一致性(也就是 C)是指原子一致性(也就是线性一致性)。其中,Paxos、Raft 能实现线性一致性,而 ZooKeeper 基于读性能的考虑,它通过 ZAB 协议提供的是最终一致性。
一般而言,在需要系统状态的一致性时,你可以考虑采用二阶段提交协议、TCC。在需要数据访问是的强一致性时,你可考虑 Raft 算法。在可用性优先的系统,你可以采用 Gossip 协议来实现最终一致性,并实现 Quorum NWR 来提供强一致性。
可用性
可用性说的是任何来自客户端的请求,不管访问哪个非故障节点,都能得到响应数据,但不保证是同一份最新数据,可用性强调的是服务可用。
一般来讲,采用 Gossip 协议实现最终一致性系统,它的可用性是最高的,因为哪怕只有一个节点,集群还能在运行并提供服务。其次是 Paxos 算法、ZAB 协议、Raft 算法、Quorum NWR 算法、PBFT 算法、POW 算法,它们能容忍一定数节点故障。
最后是二阶段提交协议、TCC,只有当所有节点都在运行时,才能工作,可用性最低。
性能
一般来讲,采用 Gossip 协议的 AP 型分布式系统,具备水平扩展能力,读写性能是最高的。其次是 Paxos 算法、ZAB 协议、Raft 算法,因为它们都是领导者模型,写性能受限于领导者,读性能取决于一致性实现。最后是二阶段提交协议和 TCC,因为在实现事务时,需要预留和锁定资源,性能相对低。
拜占庭将军问题:最复杂的分布式容错模型
二忠一叛
故障行为
恶意行为
口信消息型拜占庭问题
n位将军,最多能容忍(n-1)/3位叛将
签名消息型拜占庭问题
通过签名防止信息篡改,来解决问题
拜占庭容错和非拜占庭容错
拜占庭容错算法:PBFT、PoW
POW
通过一定工作量证明你是好人
PBFT
通过签名消息约束叛变行为
故障容错算法(非拜占庭容错算法):Paxos、Raft、ZAB、Quorum NWR、2PC、TCC
CAP理论:酸碱平衡之道
CAP理论
分布式系统PH试纸
CAP三指标
C:数据正确
A:服务可用
P:分区容错
CAP不可能三角
CAP定理
ACID理论
本质
ACID是对事务特性的抽象和总结
分布式事务
二阶段提交协议
二阶段提交协商
提交请求阶段
提交执行阶段
TCC
Try(预留)
Confirm(确认)
Cancel(撤销)
BASE理论
基本可用
流量削峰
延迟响应
体验降级
最终一致性
哪些场景适合最终一致性
到底以什么为准
如何实现最终一致性
自定义写一致性级别
软状态
过渡状态
如何使用BASE理论
实际系统剖析
分布式事务:进退与共
要么全部执行、要么全部不执行,系统状态的一致性
提交请求执行阶段
实现数据层面分布式事务
TCC(Try-Confirm-Cancel)
预留
执行/撤销
实现业务层面的分布式事务
XA规范
事务管理器和资源管理器之间双向通讯的接口规范
实现了二阶段提交协议
通过MySQL XA可以实现多个数据库操作的分布式事务
分布式强一致性:你必须给我最新的数据
强一致性:写操作完成后,任何后续访问都能读到更新后的值
paxos算法
Basic Paxos
实现单值得共识
三种角色,提议值(Proposer)、接受者(Acceptor)、学习者(Learner)
二阶段提交
准备阶段(Prepare)
接受阶段(Accept)
缺少一些编程必须细节,出现众多Paxos变种
Multi-Paxos
Multi-Paxos是Paxos变种,通过多个Basic Paxos实例实现一组数据一致性
Multi-Paxos是一个统称,Chubby的Paxos实现,ZAB协议、Raft算法本质也是Multi-Paxos
Chubby的Paxos实现
引入Master,优化协商效率,提升性能
日志复制和一致性
以Master为准
故障恢复后,通过catch-up机制进行数据恢复
成员变更时,新加入节点,先同步状态和数据,不具有投票权
Chubby能容错(n-1)/2个节点的故障
Raft算法
最常用的一致性算法
最不被当作Paxos变种的Paxos变种
三种角色,领导者、候选人、跟随者
强领导型
选举领导者
节点通讯
请求投票(RequestVote)RPC
日志复制(AppendEntries)RPC
任期
任期编号
Raft算法中任期,不只是时间段,而且,任期编号的大小,会影响领导者选举和请求处理
选举规则
领导者的心跳信息,能阻止跟随着发发起新的选举
指定时间内,未接收到领导者信息,跟随者推荐自己为候选者,发起选举
赢得大多数选票的候选人,将晋升为领导者
在一次选举中,每一个服务器节点,最多会对一个任期编号,投出一张选票
当任期编号相同时,日志完整性高的跟随者,将拒绝投票给日志完整性低的候选人
随机超时时间
第一种
跟随者,等待领导者心跳信息超时,然后选举随机时间间隔
第二种
当没有候选人赢得过半票数,选举无效时,等待选举时,然后再发起新一轮选举的时间间隔
日志,一切“领导者”为准
日志一致性
联合共识
单节点变更
分布式最终一致性:数据旧点没关系
最终一致性:保证如果对某个对象没有新的写操作了,最终所有后续访问都能读到相同的最近更新的值
Gossip协议三板斧
直接邮寄
反熵
谣言传播
Quorum NWR
自定义一致性级别
按需支持强一致性
ZAB协议:ZooKeeper背后的一致性秘密
ZooKeeper是Chubby的开源替代
ZooKeeper基于读性能的考虑,提供最终一致性
ZAB协议
实现操作顺序性
领导者选举
故障恢复
实战
InfluxDB企业版一致性实现剖析
META节点一致性实现
强一致
RAFT
DATA节点一致性实现
Hashicorp Raft
跟着理论理解代码实现
以集群节点为中心的API用法
基于Raft的分布式KV系统开发实战
架构设计
代码实现
0 条评论
下一页