第七章 数据一致性模型

本文详细介绍了分布式计算系统中的数据一致性模型,包括严格一致性、顺序一致性、相关一致性、弱一致性、释放一致性、进入一致性等,并探讨了并发控制中的可串行化调度、基于锁的并发控制,如两阶段封锁,以及原子事务处理的实现和分布式提交协议。同时讨论了多副本更新的管理和一致性控制方法,如主站点、循环令牌、同步表决和法定数方法。
摘要由CSDN通过智能技术生成

第七章 数据一致性模型

分布式计算系统一般有多个数据副本,所以一个重要的问题就是如何保持多个副本的一致性,也就是一个副本更新之后,其他的所有副本也要更新。否则不同副本之间的内容就会不同。

1数据一致性模型

一致性模型是进程和数据存储之间的一个基本约定,只要按照一致性模型进行操作,那么数据存储就能正确的进行,因为分布式系统没有一个全局的时钟,所以很难精确的定义那个写操作是最后一个,所以需要提供一些其他的定义,而不同的定义就对应的不同的一致性模型。

一、严格一致性模型

严格一致性模型是限制最严格的一个一致性模型,对其来说,对一个数据项所进行的任何读操作所返回的值总是对该数据项最近一次进行写操作的结果。

二、顺序一致性(可线性化一致性)

所有进程对数据项的所有操作可以认为是按照某个顺序进行的,任何进程对这个顺序的观点是一样的。当然这个顺序不一定是物理意义上顺序。

这里如果b图的p3先读出a再读出b就也符合顺序一致性了

在这里插入图片描述

三、相关一致性

具有潜在因果关系的所有写操作能够被所有的进程以相同的顺序看见,而并发的写操作可以被不同的进程以不同的顺序看见。

在下面这个图里面 b c是并发的
在这里插入图片描述

在这里插入图片描述

四、FIFO一致性

一个进程中的所有写操作能够以他在该进程中出现的顺序被所有其他的进程看见。但是不同进程中的写操作在不同的进程看来具有不同的顺序。

b肯定在c前 与a随便

在这里插入图片描述

处理机一致性模型:在这种模型中,不仅要求一个进程中的所有写操作能够以它在该进程中出现的顺序被所有其他进程看见还要求不同进程对同一个数据项的写操作,应该被所有进程以相同的顺序看见。

在这里插入图片描述

五、弱一致性

弱一致性模型是使用同步变量实现的一个一致性模型,(就是在顺序一致性的基础上引入了同步变量,因为对于记事本这类的来说,只需要最后的修改结果就可以了,里面的顺序不重要,写完之后调用同步变量synchronize就可以了。)它有以下的特性:

  • 访问与数据存储有关的同步变量的时候,必须遵守顺序一致性
  • 以前的所有写操作在每个副本上没有完成之前,对同步变量进行的写操作不允许执行
  • 以前的所有对同步变量的操作完成之前,对数据项的任何读或写操作不允许执行。

在这里插入图片描述

六、释放一致性

释放一致性为用户提供了这两种同步操作:一种是acquire操作,它用于告诉系统调用进程要进入一个临界区,在这种情况下,其他进程对远程副本的修改应该传播到本地,并且要对本地的副本进行更新;另一种是release操作,用于告诉系统调用进程要离开一个临界区,在这种情况下,本地进程对本地数据副本的修改应该传播到所有的远程副本上。

  • 前面的所有acquire操作完全成功完成以前,对共享数据的读写操作不能执行;

  • 在一个释放操作被允许执行之前,所有以前的读写操作必须完成;

  • 对同步变量的访问必须遵守FIFO一致性模型。

因为p3没有申请临界区,所以读取到a是可能的

在这里插入图片描述

七、进入一致性

每一个共享数据项都有对应的同步变量,而释放一致性是一组共享数据项才有一个

在这种模型中,对于某些共享数据,允许非互斥的并发访问,但这通常是在满足特定条件下才被允许的。例如,一些共享数据可能被标记为只读,从而允许多个进程或线程非互斥地同时访问这些数据。

对于需要修改的共享数据,仍然需要互斥访问来保证数据一致性。

  • 被保护数据的所有更新完成之前,一个进程对相应同步变量的acquire操作不能执行。

  • 如果有其他进程持有某个同步变量,即使是以非互斥的方式持有这个同步变量,一个进程以互斥的方式对这个同步变量的访问不能执行。

  • 当一个对同步变量的互斥方式访问完成以后,其他进程对这个同步变量的非互斥方式的访问也不能立即执行,除非在这个同步变量的所有者的访问完成之后。

在这里插入图片描述

在这里插入图片描述

2并发控制

并发控制的目的就是在由多个用户的情况下允许每个用户像单个用户那样访问共享资源,多个用户同时访问的时候互相不干扰。并发控制要解决多个用户的活动之间的切换,保护一个用户的活动不受另一个用户的活动的影响,以及对相互依赖的若干活动进行同步等问题。

事务处理:在数据库中的事务处理是施加在共享数据上的一组操作,这些操作是结合在一起的,被当作单个活动看待。

在无并发控制的情况下,两个并发的事务处理可能会相互干扰:

  • 丢失更新。多个事务处理同时对一个共同的数据对象进行写操作时,就会有丢失更新的现象发生,并且使数据库处于不一致状态。

  • 检索的不一致。检索的不一致发生在一个事务处理读取数据库中的某些数据对象,但是另一个事务处理对其中一些数据对象的修改还没有完成。

在这里插入图片描述

在这里插入图片描述

一、可串行化调度

并发控制正确性标准有两条:

  • 用户交给系统的每个事务处理最终将被执行,并最终得到完成;
  • 多个事务处理并发执行的结果和这多个事务处理串行执行的结果相同。

但是并发事务处理会出现两个现象:暂时不一致性(某次处理后结果与最终不同,所以事务处理结束之前不要求一致性)、冲突(操作冲突,一般有三种 r-w w-r w-w)。所以为了达到一致性,必须要避免冲突。

**可串行化调度:并发控制就是控制相互冲突操作的相对执行顺序,完成这种控制的算法也叫同步技术。**我们希望使用这样的同步技术,它能使各个非冲突的操作交叠执行,以便进行各事务处理时具有最大的并发性。一组事务处理中各个操作的交叉次序叫做调度。如果一个调度给每个事务处理一个一致的状态观点,则这种调度叫做一致调度。一致调度的充分条件是这种调度执行的结果和所有事务处理串行执行的结果是一样的。满足这个条件的调度叫做可串行化调度或线性化调度。

在这里插入图片描述

两个调度等价:在事务处理系统两个调度等价当且仅当 两个调度中每个对应的读操作读自同一个写操作 两个调度中有同样的最终写

在这里插入图片描述

一组事务处理T={T1,T2,…,Tn},对于一个给定调度L,串行化图定义如下:

对某个x,如果ri(x)<wj(x)、wi(x)<rj(x),或者wi(x)<wj(x),则有一条从Ti到Tj的边。如果从Ti到Tj有一条路径存在,则可以删除从Ti到Tj的边。

如果对应的串行化图是无回路的就证明调度L是可串行的。所以下图中的L1是不可串行的

在这里插入图片描述

二、基于锁的并发控制

锁就是在事务处理中插入一系列封锁和解锁操作。通常,一个封锁的对象是不可以共享的,除非所有的操作都是读操作。读锁是共享锁,写锁是互斥锁。

根据对象的封锁方式和时间,封锁机制可以分为静态封锁动态封锁

在静态封锁方式中,事务处理在执行操作之前,对有需要的数据对象封锁。这个方法相对简单,然而它限制了并发性,因为有冲突的事务处理必须串行执行。在动态封锁方式中,事务处理在执行的不同阶段对不同对象封锁。

封锁的范围越小并发性越好,并且它们是对这个文件的两个不同部分进行修改的话,则可以让他们同时进行。

1、两阶段封锁

一个动态封锁方法是两阶段封锁。两阶段封锁可以保证一致性,实现正确的并发控制。内容如下:

访问一个对象前先封锁它,为此必须先获得锁;对所有要访问的对象封锁前不对任何对象进行解锁;不要封锁已经被封锁的对象,为此不同的事务处理不可同时获得冲突的锁;事务处理执行结束前,为每个被它封锁的对象解锁;一旦一个事务处理释放一个锁,该事务处理就不能再获得另外的锁。每个事务处理锁的过程可分成两个阶段:锁的增长阶段和锁的收缩阶段。增长阶段中事务处理获得所有的锁而不释放任何锁;收缩阶段释放所有的锁而不取得另外的锁。

但是会存在两个问题:

  • 在锁的增长阶段会出现死锁:因为锁是一种竞争的资源,假设有两个事务A和B。事务A持有资源1的锁并请求资源2的锁,同时事务B持有资源2的锁并请求资源1的锁。在这种情况下,A和B都在等待对方释放锁,从而形成了死锁。
  • 在锁的收缩阶段容易出现层叠回退的问题:如果事务A因故障而中止,并且它已经释放了某些锁,其他依赖于这些数据的事务(如事务B)可能已经读取了A所做的修改。因为A的修改被回退了,B读取的数据就不再有效,所以B也必须回退。

层叠回退的问题可以用严格的两阶段封锁方案来解决 :

在这种方案中,事务处理一直占有所有获得的锁直到操作完成,然后在一个单一的原子操作中释放所有的锁,但是它降低了并发程度。因为在任何给定时间点,系统中的事务数量受到限制。其他事务必须等待当前事务释放其锁,才能继续执行。

2、加锁方案
  • 集中式加锁方法。在这种加锁方式中,锁管理是集中进行的。有一个集中的锁管理员,它负责锁的分配和释放。
  • 主站点加锁方法。每个数据对象有一个主站点,所有对数据对象的更新首先定向到主站点。对某个数据对象的加锁和释放锁的管理活动是由该数据对象的主站点上的锁管理员负责的。
  • 分散式加锁方法。锁的管理有所有站点共同完成。事务处理的执行包括许多站点的参与和协作。

3原子事务处理(重点)

事务处理对数据库进行的操作是一种不可分割的操作,也就是具有全有或全无的特性。一个事务处理通常由两种结果:事务处理完全正确地执行完毕、事务处理夭折或取消是相当于该事务处理根本没有执行,不能对数据库产生任何影响,具有这种特性的事务处理称为原子事务处理。

一、原子事务处理的性质

  • ①原子性(Atomicity)。一个原子事务处理的执行必须确保是完全执行完毕或相当于完全没有执行。

  • ②一致性(Consistency)。一个事务处理必须以一致性的状态开始,以一致性的状态结束。不能违背系统的恒定性。不变量在开始之前和结束后不变

  • ③孤立性(Isolation)。原子事务处理所有的中间操作必须以孤立的形式执行。只允许在该事务处理操作的某个数据对象达到一致的状态时才能够被其他事务处理访问。也就是说,并发的事务处理之间不会发生相互干扰。孤立性也称为可串行性。也就是有多个事务处理同时运行的时候,最终结果和这些事务处理穿行运行结果一样。

  • ④持久性(Durability)。一旦事务处理已经被提交,即使在发生系统失效的情况下,结果将永不丢失。

二、事务处理的分类

  • 平面事务处理:事务处理都是由一系列基本的操作所组成;

  • 一个嵌套事务处理是由多个子事务处理组成的,顶层的事务处理产生多个子事务处理,这些子事务处理相互在不同的机器上并行执行。每个子事务处理也可以产生自己的子事务处理;

  • 分布式事务处理也是由一些子事务处理组成的,分布式事务处理在逻辑上是平面的,是施加在分布式数据对象上的一系列在逻辑上不可分的操作组成的;

三、原子事务处理的实现

实现原子事务处理必须提供以下几个组成部分:

①事务处理管理员:负责使该事务处理的各个参加者就该事务处理是否提交或夭折达成一致意见;

②恢复管理员:负责在事务处理失效后恢复状态;

③缓冲器管理员:负责在主存和磁盘间传送数据;

④运行记录(log)管理员:负责各种操作及状态的记录;

⑤锁管理员;负责并发控制;

⑥通信管理员:负责透明的跨网络的通信,在分布式事务处理中通知事务处理的管理部分。

四、原子事务处理的局部恢复技术

1、先写运行记录方法

先写运行记录的方法在事务处理的执行过程中,对数据对象进行了实际的修改。但是在数据对象被修改前,需要在运行记录中写一个记录项,用于告诉事务处理管理员对哪个数据对象进行修改,修改前的值和修改后的值是什么,以便用于失效后的恢复。只有在这个记录项正确地写到运行记录之后,才能对实际的数据对象进行修改。该运行记录是放在坚固存储器之中的。

需要遵守以下两个规则:

  • 在把数据对象的新值写入到运行记录之前,先把数据对象的旧值写入运行记录;

  • 在对数据对象进行实际的更新之前,先把该数据对象的旧值和新值写入到运行记录中。

如果事务处理夭折,运行记录可以用来退回到事务处理执行前的起始状态。从运行记录的末尾往回退的过程中,读取每一个运行记录项,按记录项的内容执行恢复操作,最终会退回到事务处理执行前的状态,这个过程叫做卷回(rollback)。

五、分布式提交协议(重点)

事务处理完成之后,每一个成员需要提交。分布式提交用于保证一个进程组中的每一个成员要么都执行某一个操作,要么都不执行这个操作。分布式提交用于分布式事务处理的全局恢复。

两阶段提交协议2PC是最常用的分布式提交协议:当有多个参与者参加同一个事务处理时,要有一个协议在全网范围内协调这个事务处理的所有参加者的提交活动。在参加者中指定一个协调者,他和所有参加者联系,协调者通常是发起事务请求的节点。

  • 协调者的准备提交阶段

①向所有的参加者广播一个PREPARE(准备)报文;

②等待每一个参加者的回答。

每个参加者仅在完成此事务处理中属于它应该完成的那部分工作,同时写好运行记录之后才发出一个回答报文。

  • 协调者的提交阶段

如果有一个参加者回答一个ABORT(夭折),或者有一个参加者超时未回答,则将ABORT项写入运行记录中,然后向所有参加者广播一个ABORT报文,在收到参加者的承认后,本次协议的执行结束。如果所有参加者发来的PREPARED(准备好了)报文,则进行一下操作:

①在运行记录上写入一个COMMIT项;

②向所有的参加者广播一个COMMIT报文;

③等待每个参加者做出肯定回答ACK-COMMIT;

④将COMPLETE(完成)项记入运行记录,本次协议的执行结束。

  • 参加者的准备提交阶段

①等待协调者的PREPARE报文;

②完成自己的工作,将运行记录项写入运行记录;

③如果成功,则将COMPLETE项记入运行记录,并向协调者发送PREPARED报文;否则发送ABORT报文。

  • 参加者的提交阶段

① 等待协调者的裁决报文;

②向协调者发送回答。如果裁决是ABORT则将事务处理作废,同时将ABORT项写入运行记录中,释放锁,发送夭折承认报文ACK-ABORT;如果裁决是COMMIT,在运行记录上写入一个COMMIT项,释放锁,发送提交承认报文ACK-COMMIT

4多副本更新和一致性管理

一、分布式系统中的系统数据库

系统数据库的分布有三种可能的方式:

  • ①完全分割方式:数据库的各部分分散到各地点,相互都是不重复的;

  • ②完全冗余方式:整个数据库的各个副本分散各处;

  • ③部分冗余方式:数据库分成若干部分,其中有些部分有副本存放在其他地点。

二、兼容可串行化

兼容可串行化是处理分布式系统中并发事务的一种方法,它通过保证不同节点上事务活动的兼容串行顺序来保持全局数据一致性。

**兼容串行化:**设并发事务处理T1和T2分别使存储处理机P和Q产生活动A1§、A1(Q)和A2§、A2(Q),如果A1§→A2§在P处是正确的串行顺序,则在Q处的可兼容串行化应为A1(Q)→A2(Q)。

**复制控制算法就是用来保证兼容可串行化,保证数据库多副本间的相互一致性。**复制控制算法分为两大类:表决法(控制者之间交换报文,对分布式数据库要进行的各事务处理的整个次序达成一致意见。)和非表决法(非表决法使用控制优先权,一种方法是在各控制者之间建立主从关系。)控制者就是负责进行数据库事务处理的服务员

三、主站点方法(非表决方法)

一个节点被指定是主站点,其他是备份的,所有请求直接发送到主站点

读请求:主站点只是简单地读取并返回结果

写请求:当主站点完成更新前收到一个写请求,它就向至少k个备份站点发送更新请求。一旦所有站点已经收到请求,主站点完成操作再送回结果。

四、循环令牌方法(非表决方法)

循环令牌法把全部控制者排成一个虚拟的单向环,给一个控制者分配一个暂时的唯一的控制优先权。有令牌的并且有事务处理的就广播事务。其他控制者承认并处理事务。

①为了在全部控制者/存储处理机上发动执行事务处理,控制者必须等待收到控制令牌。

②令牌携带顺序号,用来给事务处理请求发“票”,每张票上都有顺序号,每发出一张票,就自动增加顺序号。这样,这些票给这些请求建立一个全排序。在这里插入图片描述

五、同步表决方法

有一个报文队列可用来存储请求报文、投票报文和END报文

在这里插入图片描述

在这里插入图片描述

六、活动复制控制方法

在每个时刻维护相互一致性是不可能做到的,一般的复制控制算法只要求顺序一致性,在这里顺序一致性表现为:每个控制者经历同样顺序的修改操作,同时,如果没有新操作时它们的值应该相等。活动复制方法类似于Lamport时间戳互斥算法。每个本地更新加上时间戳后广播到所有其他控制者。每个控制者i有一个队列Qi[j],包含有从控制者j发送来的报文。因为每个队列中的报文是按照它们的发送顺序排列的,所以按顺序查看报文时只需要检查队列头。

七、法定数方法

设具有某文件副本的服务员数目为N。要读取一个文件,必须要得到NR(读定额)个服务员同意。要修改一个文件,需要得到NW(写定额)个服务员同意。NR和NW应满足:NR+NW>N。只有当通过询问知道了有足够多的服务员愿意参加并同意之后,才能进行某种操作。

一般说来,Nr取值小一些可使读操作易于得到满足,但是写操作的执行就难一些,反之亦然。NR,NW的最佳选择取决于读、写操作哪个更频繁。

在这里插入图片描述

如图,N=9 对图a来看 N=9 NR=2 NW=8 假定一个用户获得了服务员A和B的读文件的权利,另一个用户为了能进行修改操作,必须得到8个服务员的统一,但是目前不可能,因为一共只有9个服务员,所以写操作必须等到读用户结束才能开始。

八、分层表决方法

在这里插入图片描述

对于分层表决方法,使用分层的树型结构,还可以减少表决所需的报文数目。例如前面的Holler同步表决方案,完成一次同步表决至少需要2N(N-1)个报文,其中每个控制者需要向所有其他N-1个控制者发送投票报文,每个控制者完成本地副本更新后需要向所有其他N-1个控制者发送END报文。如果16个副本被线性组织,那么完成一次表决至少需要2×16×15=480个报文。如果采用树型结构,那么完成一次表决只需要5×2×4×3=120个报文。

在·

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值