分布式一致性协议三部曲-深入理解一致性协议Paxos

 在理解分析分布式一致性协议前,我们必须先看下CAP理论

CAP

    CAP是指在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)这三个要素最多只能同时实现两点,不可能三者兼顾。

 

 

  • Consistency 一致性

一致性指“all nodes see the same data at the same time”,即更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致。等同于所有节点拥有数据的最新版本。

  • Availability 可用性

可用性指“Reads and writes always succeed”,即服务一直可用,而且是正常响应时间。

对于一个可用性的分布式系统,每一个非故障的节点必须对每一个请求作出响应。如果不考虑一致性,这个是很好实现的,立即返回本地节点的数据即可,而不需要等到数据一致才返回。

  • Partition Tolerance 分区容忍性

        Tolerance也可以翻译为容错,分区容忍性具体指“the system continues to operate despite arbitrary message loss or failure of part of the system”,即系统容忍网络出现分区,分区之间网络不可达的情况,分区容忍性和扩展性紧密相关,Partition Tolerance特指在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。

比如一个服务有3个节点,中国,美国,新加坡,如果数据只有一份,如果数据只在中国,那么美国用户访问数据流程是“美国节点->中国节点->中国数据“来实现的。这时如果美国和中国之间的网络断/高延时了,即出现分区,美国用户就没法访问到该数据。为了解决这个问题,目前都是每个节点都有一份数据备份,即中国,美国,新加坡都有一份数据,这样美国节点和中国节点哪怕临时中断,美国用户还是可以访问美国的数据。但是数据分处不同地区,需要同步,但同步有延时,数据可能不一致。要保障一致,那就必须等写操作在所有节点完成才读,这个时间又是不确定的,又会带来可用性问题,这就是C,A,P不可兼得即CAP理论。

  • 具体工程场景

    • 传统数据库都是假设不保证P的,因为传统数据库都是单机或者很小的本地集群,假设网络不存在问题,出现问题手工修复。所以,损失分区容错(P)只保证CA相当于就是一个单体应用,根本不是分布式,其实在分布式出现之前都是这么搭系统,但是倘若这种系统的节点之一挂了,整个系统就直接宕掉了,不符合目前现实需求(高扩展容错)。分布式是要求单个节点故障(概率太高了)系统仍能完成运行。搭建分布式就是间接要求必须保证P,即P是现实,那C和A就无法同时做到,需要在这两者之间做平衡。

    • 像银行系统,是通过损失可用性(A)来保障CP,银行系统是内网,很少出现分区不可达故障状态,一旦出现,不可达的节点对应的ATM就没法使用,即变为不可用。同时如果数据在各分区未达到一致,ATM也是Loading状态即不可用。

    • 在互联网实践中,可用性又是极其重要的,因此大部分是通过损失一致性(C)来保障AP,当然也非完全牺牲一致性,使用弱一致性,即一定时间后一致的弱一致性,当数据还在同步时(WRITE之后),使用上一次的数据。

    下面我们就来分析讨论今天的重点分布式一致性算法, 在理解Paxos之前我们必须先了解2PC和3PC。

 

二阶段提交协议(2PC)

 

协议详情

 

 

 

改进

    相比一阶段协议,分两步可以让事务先执行然后再提交,让事务在提交前尽可能地完成所有能完成的工作,这样,最后的提交阶段将是耗时极短,耗时极短意味着操作失败的可能性也就降低。

 

缺陷

  • 同步阻塞问题

    执行过程中,所有参与节点都是事务阻塞型的。当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态。

  • 单点故障

    由于协调者的重要性,一旦协调者发生故障,参与者会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的 参与者 还都处于锁定事务资源的状态中,而无法继续完成事务操。尽管协调者挂掉后可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题。

  • 数据不一致

    在P2A中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这会导致只有一部分参与者接受到commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交,于是整个分布式系统便出现了数据不一致性的现象。

三阶段提交(3PC)

协议详情

  • 4
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
分布式系统一致性协议是用于确保在分布式系统中的多个节点之间达成一致状态的协议。在分布式系统中,由于网络延迟、节点故障等原因,节点之间的数据可能会出现不一致的情况。一致性协议的目标是通过协调节点之间的操作,使得系统在面对各种故障和并发操作时能够保持一致性。 常见的分布式系统一致性协议包括: 1. 两阶段提交(Two-Phase Commit,2PC):2PC是一种基于中心协调者的协议,它通过两个阶段的消息交换来实现一致性。第一阶段是准备阶段,协调者向参与者发送准备请求,并等待参与者的响应。第二阶段是提交阶段,协调者根据参与者的响应决定是否提交或中止事务。2PC的缺点是存在阻塞和单点故障问题。 2. 三阶段提交(Three-Phase Commit,3PC):3PC是对2PC的改进,引入了超时机制来解决阻塞问题。它将2PC的准备阶段拆分为canCommit和preCommit两个阶段,并引入超时机制来处理参与者和协调者的故障。 3. PaxosPaxos是一种基于消息传递的一致性协议,用于解决分布式系统中的一致性问题。Paxos通过选举一个提议者和多个接受者来达成一致,它具有高度的容错性和可扩展性。 4. Raft:Raft是一种相对于Paxos更易理解和实现的一致性协议。Raft将一致性问题分解为领导选举、日志复制和安全性三个子问题,并通过选举一个领导者来协调节点之间的操作。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值