分布式理论 续| 青训营笔记

111 阅读12分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 12 天

前言

今天无课,遂继续对分布式理论的课后问题进行解答,并将其分享如下。

分布式系统有哪些优势和挑战?

优势

1.可用性(容错性)

分布式计算系统中的一个重要的优点是可靠性。一台服务器的系统崩溃并不影响到其余的服务器,仍可以正常对外提供服务。

2.可扩展性

可以通过线性的增加机器资源,来应对不断增长的外部需求。

3.资源共享

共享数据是必不可少的应用,如银行,预订系统。

4.灵活性

由于该系统是非常灵活的,它很容易安装,实施和调试新的服务。

5.更快的速度

多地部署,将用户请求按地理路由到最近机房处理。拥有多台计算机的计算能力,使得它比其他系统有更快的处理速度。

6.开放系统

由于它是开放的系统,本地或者远程都可以访问到该服务。

7.更高的性能

相较于集中式计算机网络集群可以提供更高的性能(及更好的性价比)。

挑战

1.异构的机器与网络:

分布式系统中的机器,配置不一样,其上运行的服务也可能由不同的语言、架构实现,因此处理能力也不一样;节点间通过网络连接,而不同网络运营商提供的网络的带宽、延时、丢包率又不一样。怎么保证大家齐头并进,共同完成目标,这四个不小的挑战。

2.普遍的节点故障:

虽然单个节点的故障概率较低,但节点数目达到一定规模,出故障的概率就变高了。分布式系统需要保证故障发生的时候,系统仍然是可用的,这就需要监控节点的状态,在节点故障的情况下将该节点负责的计算、存储任务转移到其他节点

3.不可靠的网络:

节点间通过网络通信,而网络是不可靠的。可能的网络问题包括:网络分割、延时、丢包、乱序。相比单机过程调用,网络通信最让人头疼的是超时:节点A向节点B发出请求,在约定的时间内没有收到节点B的响应,那么B是否处理了请求,这个是不确定的,这个不确定会带来诸多问题,最简单的,是否要重试请求,节点B会不会多次处理同一个请求。

总而言之,分布式的挑战来自不确定性,不确定计算机什么时候crash、断电,不确定磁盘什么时候损坏,不确定每次网络通信要延迟多久,也不确定通信对端是否处理了发送的消息。而分布式的规模放大了这个不确定性,不确定性是令人讨厌的,所以有诸多的分布式理论、协议来保证在这种不确定性的情况下,系统还能继续正常工作。

CAP理论中,请举例说明可用性和一致性的矛盾?

先看图:

image.png

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

什么是分区?

一个分布式系统里面,节点组成的网络在正常状态下应该是连通的,也就是所有节点出于同一分区中。然而软件、硬件或者网络等故障不可避免,使得分布式系统中的节点之间不连通了,整个网络就分成了几块区域。当系统数据无法在不同分区间传输时,系统就是不可用的,这样的系统就是分区不容忍的系统。

通过增加数据副本的方式可以提高分区容忍性,也就是将同一数据的不同副本存储到分布式系统的不同存储节点中。然而,同一数据拥有多个副本后,副本之间数据在特定阶段、特定时刻,会出现某种程度的数据不一致的问题。

因此,三要素之间有着如上图所示的难以调和的矛盾,鱼与熊掌不可兼得。

另外,在分布式系统中,分区容忍性是必须要具备的特性,是不可放弃的,分布式系统中,要么选择 CP,要么选择 AP,没有 CA 这种选择。

举个简单的例子,在分布式系统中有三个节点 A、B、C,它们都保存着同一数据的不同副本,假设该系统同时满足 C(一致性)、A(可用性),当故障发生时,系统被分成了两个区 {A、B} 和 {C},这种情况下,C 接收到一条更改数据的请求,那么有两种可能的操作:

1.执行更新,那么除非系统从故障中恢复,否则 A,B 无法获悉本次更新;
2.拒绝更新;
总之,要么选择一致性,要么选择可用性,无法同时满足。

三阶段提交缓和两阶段提交的哪两个问题?

什么是2PC?

2PC,即两阶段提交协议的简写,是整个事务过程分为两个阶段,准备阶段(Prepare phase)和提交阶段(Commit phase)

两个阶段过程: 1.准备阶段:事务管理器给每个参与者发送Prepare消息,每个数据库参与者在本地执行事务,并写本地的Undo/Redo日志,此时事务没有提交。 Undo日志是记录修改前的数据,用户数据库回滚. Redo日志是记录修改后的数据,用于提交事务后写入数据文件

2.提交阶段:如果事务管理器接收到了参与者的执行失败或者超时消息时,直接给每个参与者发送回滚(RollBack)消息,否则,发送提交(Commit)消息; 参与者根据事务管理器的指令执行提交或者回滚操作。并且释放事务处理中所需的锁资源。 注意:必须在最后阶段才释放锁资源

2PC执行流程

成功执行事务事务提交流程 ,如下:

image.png

阶段一: 1.事务询问:协调者向所有参与者发送事务内容,询问是否可以执行事务提交操作。 并开始等待各参与者的响应
2.执行事务(写本地的Undo/Redo日志)
3.各参与者向协调者反馈事务询问的响应

总结:各个参与者进行投票是否让事务进行

Tip:什么是Ack
Ack确认字符,在数据通信中,接收站发给发送站的一种传输类控制字符。 表示发来的数据已确认接收无误

阶段二:
1.发送提交请求:
协调者向所有参与者发出Commit请求
2.事务提交
参与者收到Commit请求后,会正式执行事务提交操作,并在完成提交之后释放整个事务执行期间占用的事务资源
3.反馈事务提交结果
参与者在完成事务提交之后,向协调者发送Ack信息
4.完成事务
协调者接收到所有参与者反馈的Ack信息后,完成事务

2PC的优点和缺点:

1.优点:原理简单,实现简单
2.缺点:同步阻塞,单点问题,数据不一样,过于保守

  • 同步阻塞
    这是二阶段提交协议最大最明显的问题,在提交过程中,所有参与该事务操作的逻辑都处于阻塞状态,也就是所有参与者在等待其它参与者相应的过程中,无法进行其它操作。这种同步阻塞极大限制了分布式系统的性能
  • 单点问题
    协调者在二阶段提交协议中十分重要,一旦出现故障,整个流程就无法运转,更重要的是,其它参与者都会处于一个锁定事务的状态中,而无法继续完成该事务
  • 数据不一致
    假设当协调者在给所有参与者发送commit事务后,出现局部网络问题或者协调者在没有发送完所有commit请求的时候突然崩溃,导致最终只有部分参与者收到了Commit请求,这将导致严重的数据不一致问题
  • 过于保守
    如果在二阶段提交的询问阶段中,参与者出现故障或者协调者没有获取到所有参与者的响应信息,这个时候协调者只能依靠自身的超时机制来判断是否需要中断事务。显然,这种策略过于保守。换句话说,二阶段提 交协议没有设计较为完善的容错机制,任意一个节点失败都会导致整个事务的失败。

什么是3PC

3PC是2PC的改进版,将2PC的"提交事务请求"过程一分为二,共形成了由CanCommit,PreCommit和doCommit三个阶段组成的事务处理协议 `

image.png

阶段一:CanCommit
️1:事务询问
协调者向所有的参与者发送一个包含事务内容的canCommit请求,询问是否可以执行事务操作,并开始等待各参与者的响应

2.各参与者向协调者反馈事务询问的响应
参与在接收在接收来自协调者的包含了事务内容的canCommit请求后。 正常情况下,如果自身认为可以顺利执行事务,则反馈Yes响应,并进入预备状态,否则反馈NO响应

阶段二:PreCommit
协调者得到所有事务参与者的响应结果,根据结果的,协调者会出现两种执行情况。执行事务预提交。 或者中间事务,如果接受到都是Yes就执行事务。
1.执行事务预提交分为3个步骤
1.1发送预提交请求:
协调者向所有参与者节点发出preCommit请求,并进入prepared阶段

1.2事务预提交  
	参与者接受到preCommit请求后,会执行事务操作,并将Undo和Redo信息记录到事务日志中
	1.3各参与者向协调者反馈事务执行的结果:
	若参与者成功执行了事务操作,那么反馈Ack

若任一参与者反馈了No相应,或者在等待超时后,协调者还无法接收所有参与者反馈,则中断事务
2.中断事务也分为两个步骤
2.1发送中断请求
协调者向所有参与者发出abort请求
2.2中断事务
无论是收到来自协调的abort请求或者等待协调者请求过程中超时,参与者都会中断事务

阶段三:do commit
该阶段做真正的事务提交或者完成事务回滚,所以就会出现两种情况
1.执行事务提交
1.1发送提交请求
如果协调者处于正常工作状态,并且它接收到了来自所有参与者的Ack响应,那么他将从预提交状态转换为提交状态,并向所有的参与者发送doCommit请求
1.2事务提交
参与者接收到doCommit请求后,会正式执行事务提交操作,并在完成提交之后释放整个事务执行过程中占用的事务资源
1.3反馈事务提交结果
参与者在完成事务提交后,向协调者发送Ack响应
1.4完成事务:协调者接收到所有参与者反馈的Ack消息后,完成事务

2.中断事务
2.1发送中断请求:协调者向所有的参与者节点发送abort请求
2.2事务回滚:参与者收到abort请求后,会根据记录的Undo信息来执行事务回滚。并在完成回滚之后释放整个事务执行期间占用的资源
2.3 反馈事务回滚结果:参与者在完成事务回滚后,向协调者发送Ack消息
2.4中断事务:协调者接收到所有参与者反馈的Ack消息后,中断事务

注意:一旦进入阶段三,可能会出现 2 种故障
1. 协调者出现问题
2. 协调者和参与者之间的网络故障
如果出现了任一一种情况,最终都会导致参与者无法收到 doCommit 请求或者 abort 请求,针对这种情况,参与者都会在等待超时之后,继续进行事务提交

3PC的优点

优点:
1.首先对于协调者和参与者都设置了超时机制(在2PC中,只有协调者拥有超时机制,即如果在一定时间内没有收 到参与者的消息则默认失败),主要是避免了参与者在长时间无法与协调者节点通讯(协调者挂掉了)的情况下,无 法释放资源的问题,因为参与者自身拥有超时机制会在超时后,自动进行本地commit从而进行释放资源。而这种 机制也侧面降低了整个事务的阻塞时间和范围。

2.通过CanCommit、PreCommit、DoCommit三个阶段的设计, 相较于2PC而言,多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的

3.PreCommit是一个缓冲,保证了在最后提交阶段之前各参与节点的状态是一致的