基于改进乐观两阶段锁的移动事务处理模型

2019-11-18 05:22任占广李叔繁尚福华
计算机技术与发展 2019年11期
关键词:数据库系统事务服务器

任占广,李叔繁,尚福华

(1.重庆文理学院 软件工程学院,重庆 402160; 2.东北石油大学 计算机与信息技术学院,黑龙江 大庆 163318)

0 引 言

在数据库系统中,传统事务处理模型很好地解决了传统应用环境下事务的并发控制问题。但在移动互联网环境中,由于事务的频繁断接性和长延迟性,传统的事务处理机制已无法满足移动数据库系统的事务处理要求,为此,有必要对移动事务提交和执行策略进行研究。移动事务处理可分为三类,一类是重新定义了事务的ACID(原子性、一致性、隔离线、持续性)特性[1],如集群事务模型[1]、KANGROO模型[2]、MOFLEX模型[3],虽然满足了移动环境,但无法保证事务的可串行性;第二类是将传统数据库事务处理机制引入到移动计算环境中,如文献[4-5],要求移动端必须一次性将完整的事务操作序列提交到数据库服务器,一旦在提交过程中发生网络中断,移动端只能重新提交,所以该模型不是很适合移动数据库系统;第三类是将移动事务分成发送和乐观提交两阶段执行并采用不同的冲突消解机制,如文献[6-7]采用时间戳解决事务冲突问题,文献[8]采用结果集检测的方式消除事务冲突,文献[9]分别针对油田的特定业务,局限性较大。虽然都考虑到了移动事务的不稳定特点,但由于均采用两阶段锁协议,数据可能被长时间封锁,使断接事务或长事务长时间占用资源而最终发生死锁[10]。

鉴于以上分析,文中提出一种基于改进乐观两阶段锁的移动事务处理模型,在保证事务ACID特性的同时降低了断接事务或者长事务对移动数据库系统的影响。

1 乐观两阶段锁事务处理模型

1.1 乐观两阶段锁机制分析

在乐观两阶段锁移动事务处理模型中,移动事务的提交和移动事务的执行采用不同的事务处理模式,前者采用了乐观的并发控制机制,而后者遵循两阶段锁事务执行协议。移动数据库系统的整体架构如图1所示[11-13]。

图1 移动数据库系统整体架构

如图1所示,固定网络拥有多个数据库服务器,每个数据库服务器都有一个本地的数据库,本地的数据库服务器负责读写、预处理、提交、执行等事务的操作[14-15]。每一个移动支持节点相当于移动端与固定网络之间的桥接器,一方面接收移动端发送过来的移动事务操作序列,另一方面将接收来的事务操作序列传递给固定网络中相应的数据库服务器执行,并实时监测执行情况。每一个移动客户端在任一时刻只能启动一个移动事务序列,只有当该移动事务操作序列全部执行完毕后才能启动下一个移动事务操作序列。

1.2 存在的问题

在乐观两阶段锁移动事务处理模型中,移动事务可多次发送给移动支持节点,每次可以发送一个连续的移动事务操作序列,当移动客户端接收到移动支持节点返回的事务序列的执行结果后,可以移动到另一个网络单元继续发送下一个操作序列[7]。但该模型必须保证移动端在移动操作序列提交以及得到操作序列执行结果的整个过程中始终处于强连接状态,一旦发生无线网络断接,就会造成移动事务序列的撤销操作,只能重新提交移动事务操作序列。或由于无线网络信号较差,使移动端发送或接收超时,造成事务堵塞或死锁。而无线网络受环境影响较大,本身具有低带宽、长延迟、频繁断接和资源有限等特性,因此该模型不能很好地支持频繁断接和耗时较长的移动事务。针对这一缺点,文中对乐观两阶段锁的移动事务处理模型进行了有效改进,使改进模型更适合移动数据库系统。

2 改进的移动事务处理模型

2.1 模型机制

为了解决上面提到的问题,在乐观两阶段锁移动事务处理模型的基础上引入了移动事务处理机制(mobile transaction processor mechanism,MTPM)和移动事务协调机制(mobile transaction coordinator mechanism,MTCM)。MTPM负责移动事务操作序列的编辑、生成与发送, MTCM负责识别、接收、组合移动事务操作序列,同时将事务序列提交给数据库服务器,将结果集返回给移动端。改进后的移动事务处理模型如图2所示。

图2 改进后的移动事务处理模型

2.2 MTPM

假设移动事务序列(mobile transaction series,MTS)由多个移动事务子序列组成,分别记为MTSj。

RResultSet(oj)={(ψ,υ)|ψ∈ReadSet(oj)∧υ=ζ(ψ,oj)}

WResultSet(T)={(η,υ)|η∈WSet(T)∧υ=δ(η,T)}

假设,MTSi有如下操作(见表1和表2):

表1 读操作

表2 写操作

设对应的MTS的标识MID为“M01”,所执行的操作序为:r[a=50],w[a=60]。其结果如表3所示。

表3 结果集

2.3 MTCM

MTCM有两种协调方式。当MTS是一个完整的事务操作序列时,整个MTS发送给MTCM时,MTCM将等待MTS全部收到后再执行。当MTS被分成若干个子序列,分别发送给MTCM时,MTCM根据事务识别号,将子事务序列首先存入到事务日志中,如果在这一过程中发生网络中断,那么该事务将处于挂起状态,MTCM继续接收和处理其他的事务。当网络恢复后,继续接收,直到接收到以MTS_end结尾的子序列时,则说明整个移动事务操作序列接收完成,MTCM提取事务日志子序列,合并成一个完整的事务,提交给数据库服务器执行。MTCM一方面负责监听事务执行情况,另一方面接收数据库服务器返回的结果集,并将结果集暂存到该事务的结果集日志中,同时MTCM根据事务标识检测移动端是否处于连接状态,如果状态良好,就将结果集返回给MTPM,如果状态不佳,就继续检测,直到网络正常后再发送。具体流程如图3所示。

图3 MTCM处理流程

3 实 验

3.1 算法实现

该算法由两个阶段完成,第一阶段MTCM接收MTPM发送过来的事务序列,进行识别与编辑;第二阶段MTCM提交组合好的事务给数据库服务器,并将结果集返回给MTPM。

第一阶段:识别与编辑。

一个移动事务序列由n个子序列MTSi构成,在识别阶段,MTCM首先启动一个相应验证事务VMTSi,在执行VMTSi过程中,MTSi采用乐观访问并发控制机制,在访问过程中要检测移动事务的写集冲突。

(∃j∈[1,n])∧(WriteSet(oj)≠Write Set(Voj))或(∃j∈[1,n])∧(∃Ψ∈(Set (oj)与WriteSet(Voj)))∧(ζ(Ψ,oj)≠ζ(Ψ,Voj))

定义6:对于移动事务MTSj,当进行了与之对应的一系列验证操作后,仍然没有检测到移动事务的写集冲突和事务的执行时冲突,则说明验证事务VMTSi执行完毕,事务调度的可串行性没有被破坏;否则MTCM不能提交该事务。

第二阶段:监听与提交。

在规定的时间范围内,如果MTCM验证并接收到所有移动事务子序列后,则提交数据库服务器;反之则通知MTPM,接收超时,终止本次提交。

3.2 实验结果分析

为了分析改进后的模型在移动计算环境下的性能,以“玩课网”平台学习行为数据为基础,通过Java、Android搭建了移动数据库系统。实验中的主要参数有:元组数为20万条,每个移动事务的平均操作数为7;事务处理服务器上并发的移动事务个数为0到1万;事务启动所造成的延迟为10到500毫秒。图4为理想的移动环境下改进前后事务并发量与成活率的关系;图5为连续非并发移动事务访问量为100时,移动环境的变化与事务执行情况的关系。

图4 改进前后移动事务成活率

图5 改进前后移动事务提交量

由图4 可以看出,随着移动事务并发量的增加,移动事务成活率随之降低。而当并发事务量相等时,改进后事务提交的成功率大于改进前的事务提交成功率。当移动事务的并发量越大时,改进后的效果越明显。由图5所示,当移动端与服务器端正常连接时,改进前后事务的成功执行率基本相同,当移动网络处于断接或者弱连接的情况时,改进后的事务的提交并执行成功量明显高于改进前。因此,改进后的模型无论是对移动事务并发控制还是对移动环境的适应能力都有了明显的提升。

4 结束语

文中提出了一种基于改进乐观两阶段锁移动事务处理模型,该模型充分考虑了移动计算机环境弱连接性,并对频繁断接事务和移动长事务有了很好的控制。实验表明,改进模型能更好地适应于移动数据库系统。

猜你喜欢
数据库系统事务服务器
北京市公共机构节能宣传周活动“云”彩纷呈北京市机关事务管理局
Oracle数据库系统的性能优化研究
2018年全球服务器市场将保持温和增长
针对基于B/S架构软件系统的性能测试研究
一种Web服务组合一致性验证方法研究
Hibernate框架持久化应用及原理探析
对分布式数据库系统的安全分析
数据库系统在信息管理中的使用
数据库系统在计算机体系结构中的应用
用独立服务器的站长注意了