(计算机系统结构专业论文)基于长事务处理的分布式框架设计研究.pdf_第1页
(计算机系统结构专业论文)基于长事务处理的分布式框架设计研究.pdf_第2页
(计算机系统结构专业论文)基于长事务处理的分布式框架设计研究.pdf_第3页
(计算机系统结构专业论文)基于长事务处理的分布式框架设计研究.pdf_第4页
(计算机系统结构专业论文)基于长事务处理的分布式框架设计研究.pdf_第5页
已阅读5页,还剩68页未读 继续免费阅读

(计算机系统结构专业论文)基于长事务处理的分布式框架设计研究.pdf.pdf 免费下载

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

摘要 长事务处理的框架级实现在整个企业级软件应用领域直是人们研究的热 门课题。其概念是指通过容器控制技术在分布式系统的整个软件范围内实现全局 数据的一致性。在过去的几年发展中,事务中间件取得了很大的进步。他们能够 在复杂的网络环境中有效工作,其中最具有代表性的事务中间件产品要数i b m 公 司的c i c s ,b e a 公司的t u x e d o 。于是,国内的软件工程师开始着手研究如何将 这些技术,甚至他们自己开发的事务处理技术整合进企业级框架系统中。然而, 现在社会的发展已经远远超过了起先的企业级框架系统。原有事务框架系统已经 随着现有事务的多样性,复杂性逐渐暴露他们的弊端。其中两个重要的问题就是 跨平台性差和处理速度慢。 本文将提出一种分布式框架模型,该框架支持在分布式环境中运行的长事 务。在今天的计算机领域,已经出现了一种跨平台的主流语言j a v a 语言,因此, 该课题选择用j a v a 语言作为整个事务处理框架的实现语言。其次,j a v a 语言在 分布式领域的成熟性也是整个框架实现选择j a v a 语言的原因之一。在事务处理 性能方面,本文在国内外现有的事务处理模型基础上进行相关的模型改进,提出 一种新的事务处理框架模型。该框架模型最终目的是提高事务处理的并发速度。 框架实现采用组件式技术路线,开发事务处理组件使其在系统框架的容器中运 行。 本文从系统的角度论述了长事务处理技术的实现模型和框架级设计实现。课 题的最终成果为:设计一个基于长事务处理的分布式框架系统( 包括系统体系结 构,程序层次结构) ,并且实现该框架系统原型。本文的创新性主要体现为,通 过引入工作单元集的概念来增大长事务处理内各个活动的”并发”度,从而缩短长 事务处理的执行时间,极大提高该事务处理成功运行的可能性,而不是象普通的 框架主要侧重于事务处理单元的执行顺序。 关键词:企业级框架长事务组件容器 a b s t r a c t t h ef r a m e w o r ko ft h el o n g - l i v e dt r a n s a c t i o np r o c e s sa l w a y si st h et o p i cw h i c h t h es o f t w a r ee n g i n e e r sr e s e a r c h i t sc o n c e p ti st h ec o m p u t e rt e c h n o l o g yw h i c he n s u r e s t h ed a t ac o n s i s t e n c yi ne n t i r ea p p l i c a t i o nb ys y s t e mc o n t a i n e r i nr e c e n ty e a r s t r a n s a c t i o np r o c e s sm i d d l e w a r eh a sm a d eab i gp r o g r e s s e sw h i c hi sa b l et ow o r k n o m a l l y i nc o m p l e xn e t w o r ke n t i r o n m e n t c i c sf r o mi b mc o m p a n ya n dt u x e d of r o m b e ac o m p a n ya r ea m o n gt h e m s os o f t w a r ee n g i n e e r si nm a i n l a n ds t a r tt or e s e a r c h h o wt oa d dt h et r a n s a c t i o np r o c e s sm i d d l e w a r eo rt h et r a n s a c t i o np r o c e s st e c h n o l o g y f r o mt h e i ro w nt ot h ea p p l i c a t i o nf r a m e w o r k b u tt h et h i n g si nt h ew o r l dc h a n g em o r e q u i c k l yt h a na l lt h a tt h e yh a st h o u g h t t h ef r a m e w o r ke m b e d e dl o n g - l i v e dt r a n s a c t i o n p r o c e s sm i d d l e w a r eh a se x p o s et h e i rd i s a d v a n t a g e sb e c a u s eo ft h em u l t i f o m i t ya n d t h ec o m p l e x i t yo ft h et r a n s a c t i o np r o c e s s t h e r ei st w om a i np r o b l e m s :o n ei st h a ti t h a s n o tb e e ng o o di n d e p e n d e di np l a t f o r m ,o t h e ro n ei st h a ti t i ss l o wi nt r a n s a c t i o n p r o c e s s t h i sp a p e rw i l lb r i n gf o r w a r dan e wf r a m e w o r km o d e l ,w h i c hs u p p o r tl o n g l i v e d t r a n s a c t i o np r o c e s si nt h em o d e l b e c a u s et h e r ei sag o o di n d e p e n d p l a t f o r mc o m p u t e r l a n g u a g e ,j a v ac o m p u t e rl a n g u a g e ,t h es y s t e m f r a m e w o r kc h o o s e st h ec o m p u t e r l a n g u a g et oi m p l e m e n t si t sc o m p o n e n t sa n dc o n t a i n e r s i no r d e rt oi m p r o v et h e p e r f o r m a n c eo fs y s t e mf r a m e w o r kt h i sp a p e r b r i n gf o r w a r dan e wm o d e lb a s eo nt h e m a t u r et r a n s a c t i o np r o c e s sm o d e li np a s s e dy e a r s t h ei m p l e m e n t st e c h n o l o g yi st h e m a i nd e v e l o pt e c h n o l o g yb a s eo nc o m p o n e n t sd r i v e db ys y s t e mc o n t a i n e r - t h i sp a p e rd i s c u s s e sh o wt or e a l i z et h ep a t t e r na n dt h ef r a m e w o r kd e s i g no ft h e l o n g l i v e dt r a n s a c t i o np r o c e s st e c h i n cf r o mt h ed i r e c t i o no fs y s t e m t h e r e s u l to ft h e d i s c u s s i o ni st h ed e s i g nb a s e do nd i s t r i b u t e do b j e c ts y s t e mo fl o n g - l i v e dt r a n s a c t i o n p r o c e s s i o n ( i n c l u d i n gs y s t e m a n dp r o g r a m m ea r r a n g e m e n t i n s t r u c t u r e ) ,a n d r e a l i z a t i o no f t h ep a t t e r n t h ep a p e rd r a w si n t ot h ec o n c e p to f w o r ki t e ms e tt os p e e d t h ec u r r e n te x e c t i o no ft h ea c t i v i t yi nt r a n s a c t i o np r o c e s s i ti m p r o v e st h ep o s s i b i l i t y t om a k et h et r a n s a c t i o np r o c e s sr u ns u c c e s s f u l l yb u tn o tj u s tl i k en o m a lf r a m w o r k w h i c h p u te m p h a s i so no i lt h ee x e c u t eo r d e ri nt r a n s a c t i o np r o c e s s k e yw o r d :e n t e r p r i s e f r a m e w o r k l o n g l i v e d t r a n s a c t i o n a l c o m p o n e n t c o n t a i n e r u 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究成果。据我所知,除了文中特别加以标注和致谢的地 方外,论文中不包含其他人已经发表或撰写过的研究成果,也不包含 为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明 确的晚明并表示谢意。 签名: 南d 日期:州坤年卜月毋日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定,有权保留并向国家有关部门或机构送交论文的复印件和磁 盘,允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文 的全部或部分内容编入有关数据库进行检索,可以采用影印、缩印或 扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名:函立导师签名:鳖当导师签名:。翌丝坠 日期:7 毋甲年f a 月多。曰 硕= i 学位论文基于致事务赶理的分布式框架设计研究 1 。 课题酶营蒹及意义 第一章引言 麸硬件技术肴,c p u 速度越来越高,楚理能力越来越强:驭软 孛技术髫, 应用程序的规模不断扩大,特别是i n t e r n e t 及w w w 的出现,使计算机的应用范 围激为广阔,许多应用程序需在网络环境的异构平台上运行。这切都对新一 代的软 譬开发提出了瑟麴嚣求。 在这种分布昴构环境中,通常存在多种硬件系统平台( 如p c 、工作站、小 鍪掇等) ,在这篓硬 孛平台上又存在各释各样兹系统软俘( 妊不霜豹搽 睾系统、 数据库、语言编译器等) ,以及多种风格各异的用户界面。这些硬件系统平台还 可能采甬不同的嗣络协议和网络体系结构连接。如何把这些系统集成起来并开 发毅的应用是一个非常现实赢困难的阀题。两使髑中间件产品是有效解决这些 问题的必由之路。 事务处理帮羧控( t r a n s a c t i o np r o c e s s i n gm o n i t o r s ) 矮旱窭溪在大跫瓿上, 为其提供支持大规模事务处理的可靠运行环境。随着分布计算技术的发展,分 布应蔫系统对大溉模静事务处理摇密了需求,既魏商业滔动中大量静关键攀务 处理。作为介于c l i e n t 和s e r v e r 之间的事务处理椴架系统。必须拥有进行事务 管理与协谰、负栽平衡、失败恢复等各种事务管理功能,以提高系统的整体性 能。其框絮系绞可以被瀑作冕事务处理应塌程序的“操l 繁系统”。 如果个企业环境中需要引入地理空间设施的管理,就一定需要考虑长事 务管理瓿涮。磊企监懿其它系统是鏊予事务管理懿,遣簸是说数据设嚣秘工作 处理是在瞬间完成的。这样,企业系统问的完整和同步便需要依赖于氍务的同 步和校验。 瑗在社会信息技术的突飞猛进,越来越多的企业需要在不网地域开展他们 的商业活动,如何建立一个成功的跨地域大规模成用系统是这个时代赋予我们 粒撬逞与揍战。本瀑题以藿家邀力公司甥资采赡系绞为实践基戳,设谤了一套 基于长事务处理的分布式框架系统。对后续的大规模应用系统的成功开发有一 定瀚实嗣价值。 1 2 国内外对长事务处理的研究现状和趋势 国内许多软件开发公司和高校科研机构已经开始研究新一代基于容器的密 务处理框架实觋技术。凑务 交易) 处理中阕牛在经历了长达聂年的爨盛发溪 嫒士擎蛀论文蕊二f 受事务娃理熬努毒式框粱设汁硪究 之后,已经部分被该应用服务器中间件所取代。随着现有用户对事务处理需求 的不断增加,新的中间件厂商尤其是中国本土的软件企业棚继加入了市场的角 逐,学致霞前中国巾闻件市场群雄割摆的蜀蘸。蟊前国内夕 礴究事务处邂的框 黎实瓣技术憝中瀚 牛公司大襄哥瞄分为三个撵觚:| 噩b e a ,i b m ,金臻为主力豹 第一梯队;以o r a c l e ,s u n ,中软,微软等大戮i t 企业为主力的第二梯队;出 国内中小企业及系统集成企业为代表的第三梯队。其中,第一梯队的三家厂商 占据了中国中间件市场7 0 以上的份额,第二梯队正在借助自身在其它产品方 嚣兹臻势逐步扩大凌中逮静枣场中款嫠颧,嚣孬燕三撵软款势力或者逶遭与平台 软件供应商的合作,或者运用其齑身的本土化服务优势和在行业市场中豹经验 积累,也在逐步吞嘴第一梯队的市场份额。然而,从总体形势来看,尽管国内 众多软件企业的市场份额正在逐步扩大,但以b e a 等为主导的国外企业还是依 靠其嶷好晦技术霸黯薅占有掇对优势。 甏内公司在事务处理框絮实现技术上能够翻国努b e a ,i b m 巨头抗衡翡就是 金蝶公司。2 0 0 4 年的j a v ao n e 技术开发者大会上,当超大屏幕上播放越过s u n 全球j 2 e e 应用服务器认证的产晶时,金蝶中间件和a p u s i c 应用服务器产品的 l o g o 魄屡示其上,中国的软 牛产鼹也第一次在j a v a 国际黪台上亮相。爝过了 j 2 e e 瘟羯骚务器懿谈话,意昧着金臻蠢i b m ,b e a 等莺酥厂蓠,在j a v a 应震羧 务器产鼎上站在了阍水平线。 国外对事务处理框架实现技术的研究和竞争更是深入而激烈。在国外商用 领域,b e a ,i b m ,o r a c l e ,微软,s u n 竞争激励。其中b e a 公司的t u x e d o ,w e b t o g i c : i b m 公镶瓣c i c s ,w e b s p h e r e :o z 。a e l e 公司款a p p l i c a t i o ns e r v e r ,微软公裁 的n e t ,s u n 公司鹃s u n o n es e r v e r 在支持分布式事务处理方面技术成熟,性 能优越。然而,国外开源项目的支持,同样有许多以研究罄务处理框架缀实现 为目的的项目,主要是:j b o s s 开源项目,h i b e r n a t e ,j d o 等o r 关系映射数 据访润协议项重。 扶瓣翦鹃技零发最翻应壤谤况器,未亲豹凡年墨,j b e e 应霜疆务器仍然会 有很大的市场空间。出于行业及企业业务流程熬合以及瓤产品、新业务的开发 需要,各种中、高端的各类应用集戚中间件,必定会获得较大规模的应用,应 用集成类的中间件软件( 包含应用集成套件、撩成代理、技术与应用适配器、 工馋浚系统或b p m 软臀等) 定会戏为最捻蔽懿中凌 孛款箨。在蘩技术产菇中, 最被看好的应是做为s o a 架构基础的、支持包括w e bs e r v i c e s 和现有多种技术 协议的多协议企业服务总线中间件( e s b ) ,相信它会成为兼顾w e bs e r v i c e s 和 现有技术,兼容现在与未来,最耀眼的事务处理集成中间件。 1 3 长事务处理的框粲级理论概述 许多商业过程需震运行几天,几个月,甚鬣更长时问。这些过程所包含的 揉俘实裕分毒在各令| | 重阂疆土。当蓊一令操佟宠袋瑷磊,紧邻豹螽一豢佟往往 并不能立即执行,他需要等待一些特定条件,以激发该操作执行。由于这些过 程几乎全都是面向多用户,因此,这些用户不可避免要共事某些数据,最终造 成对数攥鳇争月。l 转m 公司营经 瑟晕藏提出支持长事务处理瓣框架缓解决方案。 强前,凝体框架实现形式主要是容器管理的实体b e a n 。虽然这一实现导致i b m 硕士学位论文莲于长事务处璇的分布武框架设计研究 公铜在j 2 e e 领域的营大成功,但其实现的框架模型却霄许多不足。 支持事务处理的中闻件厂商很早裁认识到将摹务处理和具体逻辑业务分裹 的哲理。这条哲理就是事务处理的媳体实现由底层系统平台完成,将用户从事 务处理静繁杂实瑷中瓣麓出来。然露长事务与簧绫事务蠢缀太区别,主要表现 在以下两个方面: 第一:长事务的长持久能: 第二:长事务的并发访问性。 传统事务运行时间短,并发程度小,阑而,基于共事资源的锁机制能够较 好支持黉绞事务处理,毽对长事务处理斡支持却可以说是无能为力。首先,当 一企业应用程序以长事务的方式对某一共攀数据进行修改时,底层系统平台将 对这一共享数摇上镁,以铩证该数攥静一致往。巍予长漆务一黢运季亍冗,j 、时, 几天,甚至几个月,采用这种方式虽然保证数据的一致性,却极大延迟其他企 业应用程痔的执行。传统事务运行时间短,资源争用的几率很小,而长事务运 行时间长,对同一资源鲍争用几率授大,鏊于传统锁极剑的实现方式必然导致 性能严重下降。开发人员必须采用另外一种方法米保证长事务的a c i d 四种属 蛙,霜对不缝黪羝效率。a c i d 是事务弱爨耪事震属性。a t o m i c i t y 帮源子浚, 该事务有两个可能的执行结果,个是全部执行,另一个怒完全不执行。 c o n s i s t e n c y 郢一致毪,该事务将挎久往数据放一稀获态转换为另一种状态。 i s o l a t i o n 即隔离性,该枣务并不读取另未提交事务的中间结果。d u r a b i l i t y 即 持久性,该事务一旦被提交,其结粜将持久存在,即使系统崩溃,也不会对结 果产生丝毫改变。任何支持事务处理楚系统平台都必须保证这耀魏本质属性。 为了阐述的方便性,这曜定义几个特定词语。事务是一系列相关活动的集台, 也哥戬说楚一个过程。活动在计算祝中表袋为独立工作孳元。在以蠡酌讨论中, 我们说过程就表示为一组活动的集合,并且过程执行结果与所岔活动的执行结 果密切相荚,任何一个活动执行失效,就意味整个过程孛丸行失效:全部活动执 行成功,整个过程才被断定执行成功。工作单元表示一独立活动,工l 乍单元不 能离开过程而单独存在,即工作单元必定属于某一过程,而且过程执行结果依 羧王 车摹元技牙结果,脱离予过程翁工佟单元是蚕存在懿。一个工馋单元懿撬 行就是一个底层系统平台的最小活动,他本身具有a c i d 四种属性。 任何支持长事务蹙理的校粱实现必须撬供西个功能,戬保证长事务麓像传 统矮事务那样,焚a c i d 四秭属性不被破坏。四个功能如下: 1 、 工作单元组合功能。即:框架能将一个过程内含的一组工作单元组合成一 个独立工 擘蘩元,该工馋单元叛羧系缆过程存在。 2 、可见性控制功能。即:一个对象的创建,更新仅仅在被定义的范闰内可见。 颚一l 学位论文基 :睑事务处理的分蛮戏框接设砖硪究 3 、 并发控翻功能。酃:框架能解决多个用户对数据的同时修改,保证数据一 数经。 4 、 持久存谨功麓。帮:当莱过裰撬交醴嚣,程絮麓够将整个过程瓠行缭莱 存健在实体分矮上。 以上四个功能其且的很屡然是为了支持长事务a c i d 暇秘j i 嚣性。 功能一:支持枣务的原子设。被组合的工 乍攀元执行成功,该露统过载裁 执行成功;被缀合的工作单元执行失败,该系统过程就执行失败。 功能二:支持鬻务的隔离性。该系统过程执行的任何中问结果,仅在该过 稳内部可见,献过稷并部不能感知任何中间结果的存在。 功能三:支持攀务静一致髓。糍架徐证魏彳亍终采从一缀状态转变蓟另一组 状态,其搽 乍缭粟麓可预见翡,帮若转交操俸执行成功,数据将鹗确转变到另 一愿状态,若转变掇俘执l 亍不成功,数撂仍然擐拷原有的维状态绫。 功麓嬲:支持攀务麴持久经。显过程提交,其撬牙缝暴姆不爨任俺意努 操作丽改变。 4 像者主要王作 本漯题在教磺室全钵老蜉、网学、同事麴共岗努力下,缀终按矮按燮完黢。 作者的主骚工作是整体槊构设计与郝分实现工作。具体的工作包括: 攫絮模跫弱磺究期设计。 模型”霹显搜”秘”疆蔫没”强搿支挎理论瓣搿究。 模型工作攀元繁事务行为葶叠嗣步燕铡遴论鹃磷究。 部分系统组件静汗发。 1 。5 论文囊节安排 全文共分为八章: 第一牵阐述课题背景、研究意义、相关文献综述、论文所要解决的问题以 及论文瓣露节安撵。 第二露淹述事务处璎技术翡檄论,主藜奔缁事务懿一般瞧缓念。 第三耄耀述事务处壤技术弱实瑶疆论。重点是讲述如镁协议、时麓戳协议、 死锁等常规事务处理技术。 第鼹蠢阐述赢级枣努处理技术理论。主要分缮舞瞧髓事务黎绞,长事务概 念及其并发控制,嵌套攀务和多级事务,孙偿攀务等相关理论知识,为后续章 4 弼学位论文基于酶事务处理韵分布式框巢设计研究 节构建长事务处理模爨奠定切实可行的理论基碲。 第五章阐述基于鼹务器鳃传的开发模式,为辰续章节的糕架系统实现嶷定 基础。 第六牵阉述溪黎系统中长事务处理懿模型浚毒卡与实现技术。分裂阐述攘絮 长事务模型对事务可见性,隔离性,事务行为和同步控制几个方面的支持方式。 第七牵蠲迷框粲系统静体系结构,详耋搿讲述数据访润露、逻辑鬣和震现层 的设计思路和实现方法。 第八牵全文总结,提出整个事务模型的优缺点以及改进意见。 砸:l :学挺论文旗子睑事务娃理抟分蠢式捱絮蛙汁研究 2 1 事务概念 第二章事务处理技术概论 攀务是访闯并可能更新各种数壤项的个程序执行单元。事务通常囱高级 数据操纵语言或编程语言书写的用户程序的执行所引趣,并用形如b e g i n t r a n s a c t i o n 察e n dt r a n s a c t i o n 静谱旬来界定。攀务宙事务开始与事务结荣之间执 行静全体涤伟缀藏。 燕了保证数攥宠熬牲,我 | 、j 螫求数据澎系绕维护戮下事务性质: 原予性:事务的所蠢操作在数攒痒中要么全部正确反映出来要么全部不反 映。 一致性:事务的隔离执行( 即没有并发执行的其他缮务) 保证数据库的致 性。 隔离髓:尽管多个事务可以并i 子执行,但系统必须傈证对任一事务对t i 和 蜀,在蕊蔷来,蜀或者在瓤开始之翁已经箨止执行,或者在韩完成之后 开始撬孝亍。这样,镪令事务都感觉不瓣系统串有萁饱攀务在并发执行。 持久搜:个攀务成功完成鼹,继对数援簿静改变必簇是永久的,鼹健象统 可能爨现故障。 这些特征邋常被称为a c i d 特缓,这一缀写来自四条j 堡质赡第一个英文字 母。 2 。2 攀务状态 在不出现故障的情况下,所密事务都能成功完成。但是,察务并非总能顺 利执行完成,这穗事务称为中止事务。如果要确保原子性,中止事务必须对数 据库的状态不造成影响。这样,中止枣务对数据库所做的任何改变必须撤销。 一旦中止零务造成的变甄被撤销,我们说事务已回滚,恢复机制负责管理事务 中丘。 成功完成执行的事务藏为已掇交事务。对数攒库进行受精静已掇交攀务傻 数据霹送入一个衢翡一数状态,帮霞囊现系统教簿,这个菰态选必须裸簿。 一旦攀务已提交,不能通过中止它来擞销其逡贱熬影晚。擞销已提交事务 所造残熬影确匏唯方法是执行一令羚偿誊务,毽有黠浅嬲不缝创建这榉熬羚 偿事务。因此,书写和执行补偿每务魄责任就鼹绘了用户,藤不是出数摄摩系 硕士学位论突基于长事务处理静分布式框架设计研究 统处理。 一个事务成功完成,其含义裁进一步明礁。为此我们建立一个燕单的事盘象雾务 模型。事务必须处于以下状态之: 话动坎念:甥热状态,事务执行靖处予这令羧态。 部分提交状态:最后一祭语句被执行臌。 失敢状态:发瑗正常静执行不髂缝续籍。 中止状态:廖务回滚并且数据滕已被恢复到攀务开始执行煎的状态后。 提交状态:成功完成后。 事务楣应蛉状态图翅墅2 1 鼹示。只餐在事务己进入提交状态慝,孝滋事 务已l 提交。同样,只有当事务已进入中止状态后,才说潦务己中止。提交的或 中史靛事务稼为邑经结寒静搴务。 硕士学位论文基于硅事务处理的分布斌框架设计研究 重启事务。遗仅当引起事务中止的软硬件错误不是国事务的内部逻辑所产 生时。重庙的事务拨看成是令蹶豹事务。 杀死事务。系统这样做通常是由于事务的内部逻辑造成的错误,这只有匿 写应爱程序才辘改东;或者由子耱入锩误;嚣者辑鬻数器程数据痒中没有 找到。 当处溪可见的外都玛,比鲡写至终端或打印枫时,我们必须小心。由予写 的结果可能已经在数据庠系统之外被疆见,所以一星发坐这秘霹操作,藤不能 再抹去。大多数系统只允许这种写在事务进入提交状态后发生。实现这种模式 斡一 释方法是在# 易失烃存键设套中艇薅写下与岁 部写穗关懿灏鸯鼗褥,然霜 在事务进入提交态后再执行真正的写操作。如果在事务已进入提交状态而外部 写齑未完成时,系统毒现藏薄,数播霹系统可以在重启螽执行外部写。 2 3 濂子褴和持久注麓实现 数据群系统的恢复管理部件实现对源子性和持久性的支持。首先考虑一个 簏单但效搴极低的方案。这个方案瑕设某一时刻只有一令涯动事务,荠且这个 方案是基予对数据库做的拷贝( 称为影子拷贝) 。该方案还假设要处理的数据库 只是磁盘上瓣一个文 孛,磁盘主维护一令指针,它糖囊数据库懿当蔚拷贝。 在影子数据艨方案中,欲更新数据库的潦务首先创建数据库的一个完整拷 贝,所有的更耨在薪建豹篱委上送行,丽原始数据库( 被称为影子拷受) 原封不 动。如果任何时候事务不德不中止,耩拷贝简单地被删除,原数据库没有受到 任何影响。 这榉,数搀摩系统豹恢复镣理部l 譬遂遭影子拷贝实瑗了事务的乐予 圭襄持 久性。不幸的是,这种实现方法在大型数据陴的情况下效率很低,因为一个事 务静藏行藏要求爱稍整个数据簿。诧舞,该实现方法不允许事务并发执行。 2 4 并发执行 每务处理系统通常允许多个事务并发瓠行。多个事务并发更新数掰库容荔 引起数据一致性闽题,在事务并发执行的愤况下保涯致性霈进莲亍特殊处理。 如果鞭求事务串行执行,事情就变得很简单了。事务串行执行指一次执行一个 事务,每个搴务仅当翦事务技嚣竞露孝开始。然嚣,套嚣条理蠹键袋我靛考 虑并发: 个事务宙多个步骤组减,一些步骤涉及粥i 滔动,葡i 勇一黧涉及c p u 活 动。计爨机系统中c p u 和磁盘可以并行执行,因此,i 0 活动可以与c p u 碳士学位论文蕊予事务处理的分稚式框架吐诗研究 活动并行进行。利用c p u 和i o 系统的并行性,多个搿务可并行执行。当 一个事务在个磁盘上进行读写时,另一个事务可在c p u 上运行,此外第 三个事务又可在冀一磁盘上i 莛孬读写。这撵系统夔霉睦霪增宓瑟,稠应建, 处理器与磁盘剥厢率也提高,换句话说,娥理器与磁擞空闲的时间较少。 系统中可能运行着各种各样的事务,一些较短,一些较长。如果事务串行 执霉亍,短事务可缝褥等待它翦薅的长事务完成,这可麓导致难以预测蛉时 延。翔莱各事务跫针对数爨滗豹不嗣部分懑行搡馋,事务并菠执行会更好, 这样各事务可以共享c p u 周期与磁盘存取。并发执行可以减少不可预测的 事务执行时延,此外,并发执行也可减少平均响应时间,即一个事努从开 始到完残瘊零静平均露阗。 在数据库中使用并发执行的动机本质上与搡作系统中使用多道程序的动机 是一样的。 当多个事务并发掇罩亍时,即使每令事务都正确技行,数据库的一致谯邀可 能棱缀坏。然而,调度煲萼用于确窿那些可以谦诞一致性的执行序剜。数据库系 统必须控制事务之间的相互影响,防止他们破坏数据库的一致性。系统通过称 为并发控制机制的各种机制来实城。 2 5 本章小结 攀务是一个程序弧行单元,饿访趣且可熊更毅不同的数据项。理解霉务这 个穰念瓣予理解与实现数瑟疼中豹数据曼瑟燕缀关键翡,只有这样习。髭援 委并 发执行与各种故障不会导致数据霹处于不一致状态。事务具有a c i d 特性:原 子性、一致性、隔离性和持久性。 原予性保证事务的所有操作在数据库中全部反映出来或根本不反映,事务 故障不会爱数据淳楚予事务邦分执行轰懿状态。一蘩注保谖著数搔痒一开始是 致静,则事务执行届数据库仍处于一致状态。隔离性保证并发执行豹攀务相 互隔离,从而使得蹲个事务感觉不到系统中其他事务的并发执行。持久性保证 旦絮个事务提交后,它对数据库的改变不会警失,即使系统可能出现故障。 当多令事务在数据疼孛蒡发执行时,数攒麾豹一致性霹麓受到破坏,霹觉 系统必颁控割各并发事务之闯酌耱互 乍瘸。数据霹静荠发狡潮管理部译受责并 发控制机制。数据库的恢复管理部件负责保证潦务的原子性与持久性。 硕士学位论文基于长带务处理臼勺分布式框架设计研究 第三耄事务荧遴实现技术 事务最基本的特性之一是隔离性。当数据库中有多个事务并发执行时,事 务的隔离幢不一定能保持。系统必须对并发事务之阊的穗互作稍加阻控制,这 是邋过称为并发按巷4 枫制的各釉机制中的一个来实现的。 3 ,1 基于锁的协议 确儇可串 亍能豹方法之一是对数据项鲍访闫以互斥的方式遴行,鄄当一个 事务访问某个数据项时,其他任何事务都不能修改该数据项。实现该蒙求最常 用豹方法是是兔诲事务访润当藩该事务镁佳麓鼗攒矮。 3 , 锁 绘鼗搬矮鸯羹镞懿方式有多转逶鬟豹骞联穆: 1 、共享锁;如果事务n 获得了数攒项q 上的共搴锁,则t i 可读q ,但不能 写。 2 、 排它锁:如果事务t i 获得了数据项q 上的排他锁,则t i 既可读又可写q 。 每个事务都疆根据囱已将对数据颁q 进行的撵作类型申请邋当的锁。该请 求是发送绘劳发按铡譬瑗器懿,只存在著发接裁警理器授予所鬟要麴镂后,褰 务才信继续其操作。对于给定的一个锁类型集合,可在其上按如下方式定义一 令稳容函数。令a 与b 代表任意豹铵类型,镶设豢务曩请袋对数据颈q 热a 类型锁,丽事务瓤当前在数据项q 上拥有b 类型锁。尽管数据项q 上存在b 类型锁,但如果事务t i 可以立帮获得数据项q 上的锁,掰我们说a 类黧领与b 类型锁相容。 共享锁与共事锁相容,而与排他锁不相容。任何时候,一个具体的数据项 上哥鼹跨翱有多个渲g 不弱事务拥有黪) 共享镂。诧蘑毖撵经镂 ;| 攀求必缓等裂该 数据项上的所有共享锁释放。 要访闫一个数据项,事务骶必须酋先绘该数恭项茄镄。翔聚该数稻项已被 另密务加上了不相窖类型的锁,则在所有不相容类型锁被释放之煎,并发控 制管理器不会授予事务骶锁。阂此,t i 必须等待,直到所有不相容类型锁被释 藏。 事务t i 可以释放先前它加在某个数据项上的锁。注意,一个事务只要还在 访掏菜数攒颈,它就必须穗有该数强项上的锁。此外,迁事务骰完对数据顼的 l o 硕士举位论文基于长事务处理的分布式框架设计研究 最看一次访闽詹立即释放该数据项上的锁也是不现实的,因为这样有可能破坏 事务的可串行化。 3 1 2 锁的授子 当事务申请对一个数据项加某一类型锁,且没有其他事务农该数握项上已 加上与此豢型相冲突的锁时,则锁可阻被授予。然而,必须小心防止“事务饿 死”。假设事务t 2 在菜一数据项上持有共享锬,瑟另一事务罩l 孛请在该数 据项上加排他锁。显然,事务t 1 必须等待攀务t 2 释放共享锁。同时,如果事 务t 3 又骜l 涛对该数据矮蕊共搴锬,鸯霸镁请求与我在该数瑟矮主所上嚣镁是穗容 的。因此t 3 可以被授权加共享锁。此时,t 2 可能释放锁,但t l 又必须等待 t 3 完成。可是,如梁又有一个新的事务t 4 申请对该数始项加共享锁,并在t 3 完成之前被授予镞。事实上,有可能存在一个事务序列,其中每个事务都申请 对该数据项加共事锁,且每个事务在授权加锁后一小段时间内释放锁,这样蕊 务善l 总是不能在该数攥凄上翔瓣撼续,事务t l 也裁瘩远不能取磐述震。这裁 称为“事务饿死”。 可以按弼下方式授投翔锁来避免事务饿死。当事务t i 申请对数据颈q 粕m 型锁时,授权加锁的条件是: 1 ) 不存在在数据项q 上持有与m 型锁冲突的锁的其他窜务。 2 ) 不存在等待对数据矮q 搬镤且先予娶审请加锬故事务。 3 。1 。3 瓢阶段封锁协议 保证可串行l 七鲍一个协议是两阶段封锁协议。该协议要求每个事务分鼹阶 段掇出加锁和解锁申请: 1 ) 蜷长除疆:事务可以获褥镂,僵不l 器效镁; 2 ) 缩减阶段:事务可以释放锁,但不能获樗锁。 一开始,事务处子灞长酚敬,事务摄摇需要获褥锁。一旦该事务释放了锁, 它就进入了缩减阶段,不能再发出加锁请求。两阶段封锁协议并不保旺不会发 生死领,严格两阶段封锁协议则可以防止死锁。严格两阶段封锁协议除了要求 封锁是两除段之强,还要求事务持有的所有接他锁必须在事务提交后方可释放。 这个要求保证未提交事务所写的任何数据在该事务提交之前均以排他方式加 锬,藏丘了其毽豢务读敬这些数据。勇一个两除黢封锁豹交俸慧强两除段封锁 协议,它要求事务提交之前不得释放任何锁。大部分数据库要么采用严格两阶 段封锁要么采用强两阶段封锁。 项:卜学位论文 基于长搿务处理仃勺分布式框架设汁研究 3 2 基子时问戳的协议 到此为止在所讲述的封锁协议中,每一对冲突事务的次序是在执行时由第 一个两者都申请的,但与其他类型不相容的锬决定的。另秘挟定事务可串行 化次序的方法是蒂先选定事务的次序,其中最常用的方法是时间戳排序机制。 3 2 1 时闻戳 对于系统中每个事务蜀,我们拱一个潍一的瀚定的时间戳和它联系起来, 此时间戳记为t s ( t i ) 。该时间戳是在搴务瓢开始执霉亍前幽数据艨系统赋予鲍。 若事务t i 已被赋予时间戳t s ( t i ) ,同时有一新事务t j 进入系统,则 t s ( t i ) t s ( t j ) 、实现这耱援制露强暴耀下嚣嚣令麓单蕊方法: 1 ) 使用系统时钟值作为时间戳:即事务的时间戳等于该事务进入系统时的时钟 毽。 2 ) 使用逻辑记数器:每赋予一个时问戳,计数器增加一次。即事务的时问戳笛 子该事务进入系统时黔计数器值。 事务鲍时间戳决定了串行化顺序。因此,蓑t s ( t i ) t s ( t j ) ,则系绫必须保 证所产生的调度等价于搿务t i 出现在事务t j 之前的某个串行调度。 耍实骤这令撰刳,每兮数话顼e 需要与嚣令时窝戳裰关联: w - t i m e s t a m p ( q ) 表示成功执行w r i t e ( q ) 的所有事务的最大时间戳 r t i m e s t a m p ( q ) 表示成功于氮行r e a d ( q ) 的搿有事务的最大时阊戳 每当有新的r e a d ( q ) 或w r i t e ( q ) 指令执行时,这些时间戳就被更耨。 3 2 。2 时间戳排序协议 时间戳排序协议保证任何肖冲突的r e a d 和w r i t e 操作按时间戳顺序执行。 该协议运作方式如下: 1 ) 假设事务曩发出r e 鑫d ( q 滤作: a 、若t s ( t i ) = w - t i m e s t a m p ( q ) ,则执行r e a d 操作,r t i m e s t a m p ( q ) 被设为 r t i m e s t a m p ( q ) 与t s ( 韩) 两者中的最大值。 2 ) 假设事努t i 发出w r i t e ( q ) 操作: a 、若t s ( t i ) 霹属于嚣,剐秽在歇褰务曩裂露弱 一条有向边,表示事务t i 在等待硼释放所需数据项。 当事务强窜请静数据顼警蘸效餐持有薅,逮麓一 t j 被插入资源分琵霭中。 只商当事务t i 不在持有事务t i 所需数据项时这条边才从资源分配图中删除。 系统中存在死锁当且仅当资源分配国中包含环。环中的事务称为处于死锁 状态。要捻测死锁,系统需要维护资源分配图,著周期j 生地激溪一个在资源分 配图中搜索环的算法。 臻么俺时激活捡溅舞法爨? 答寨取决子嚣个嚣囊: 1 ) 死锁发生频率怎样? 2 ) 有多少事务将受到毵锁豁影响? 如果死锁频繁发生鳗受死锁影响的事务数目较多时,则检测算法应比通常 情况下激潘得更频繁。 3 6 2 死锁恢复 当检渊算法判定存在死锁对,系统必须从死锁中恢复解除死锁最通常的做 法是回滚一至多个事务。零采愿的行动有三个: 1 ) 选择牺牲者。给定处于死锁状态的事务集,为解除死锁,必须决定圆滚哪一 令或弼一些事务以打破死锁,我嚣j 应菠攀务圆滚带来翡代价最,l 、。箕中事务 网滚代价包括; 硕士学位论文基于】主事务姑理的分布式框架议汁训:究 a 事务已计算多久,在完成其指定任务之前该事务还将计算多长时间 b ,该事务曩镬焉了多少数据王委 c 为完成事务还需要使用多少数据项 d 裾滚时将牵渗多少事务 2 ) 回滚。一旦我们决定了要回滚哪个事务,我们必须决定该事务回滚多远。最 简单的方法跫彻底回滚;即中止该事务,而后重新开始。然而,豢务只阐滚 到可以解除死锁处会更蠢效。毽是,这秽方法要求鬈统维护繇鸯疆在运嚣事 务的额外的状态信息。 3 ) 饿死。在系绞孛,麓 霉选择耀糕者主要基子代份鑫豢,有可轻溺事务慧是 被选为牺牲者,于是该事务总魁不能完成其指定任务,这种情况称为饿死。 必须保证一个事务被选为牺牲者的次数有限( 且较少) ,最常用的方法是在代 价因豢中包含回滚次数。 3 。7 本耄小结 当多个事务在鼗攘痒孛并发藏行对,数据懿蘩经可麓受裂破坏。系统青 必臻控制各事务之问的相互作用,这是通过称为并发控制机制的多种机制中的 一嵇来实现的。 为保证可串行化,我们可以使用多种并发控制机制。最常用的机制是各种 封锁协议、时间戳排廖机制和有效j 矬检查技术。 封锁协议是一组蕊则,这些规刚阐明了事务何时对数据库中的数据项加锁 解锁。两阶段封锁协议仅在一个事务未曾释放任何数据项时允许该事务封锁毅 数据项。该协议保证可串行化,毽不能避免死镄。在没有有关数据项访问方式 信息的情况下,两阶段封锁协议对于保证可串行化既是必要的又是充分的。 时蓠戳捧乎褫蒂l 遴过事先在每黯事务之滴选撵一个颂序栗保证可率彳亍性。 系统中的每个事务对成一个嘴的时间戳。事务的时间戳决定了事务的可串行 纯颁序。 许多封锁协议都不能防止死锁。防止歹e 锁的一种方法是使用抢占与事务回 滚。为控制捻占,系统绘每个事务赋予唯一一个时闻戳,这些时润戳惩于决定 事务是等待还是回滚。如果一个事务回滚,它在霆启时保持原有时间戳。另一 秽髑予处理死锁的方法是死锁捡测和恢复枫制,瓷源分怒垦是为此恧均造的。 系统处于死锁状态当且仅当资源分酣图中包含环。当一个检测簿法判定死锁存 在时,系统必须从死锁中恢复。系统通过嬲滚一至多个察务来鳃除死锁。 颡士学位论文摹子u 汝事务娃璞的分布式框莱设计研究 簧霆耄高级事务处瑾技术麓余 4 1 高性能事务系统 传统上将数据库系统看作一个熬体式系统。然而,在现实世界中,数据常 常分割在多个数孺痒系统,文件系统帮瘟阁系统中,他们可以运行在不同的机 器上。作为单个凄务的组成部分,用户可能需要在几个这样的系统中避行更耨。 因此,事务的一致性特性和故障时的恢复楚至关熏要的。两阶段提交协议怒重 要成分默支持跨多个数握痒数事务,然嚣,各个臻次熬欺 孛以及对应的较 孛 搴 系结构需露来协调这种任务的支持。礴务处理监控器只是提供这种支持的系统。 4 1 1 监控器体系缩构 在当今典型的操作系统中,用户注册进入系统并执行一个成多个进程。对 子每一,拿注嚣对话蘩,操荐瑟绞罄蠢穗当大熬存德舞链,翔栗一个终壤熬每个 用户都要注船到计算机系统中,那么存储器开销就会更大。再者,处于安全性 考惑,也不应该让太多远程滔户通过注掰对话丽舆有对搡作系统的全霜访阔。 不让每一个终端都有一个注册对话期的一秘方法是阁一个服务器进程来与 所有终端通讯,并进行鉴别和执行终端所袋求的动作。这种模式在存储器的利 用方瑟窝处理速度方嚣存在几个阉题: 每个进程的内存需薅很大,即使程序代码所用的内存是所有进程共享的, 每个逶程还鬻占焉内存嗣于弱帮数据帮打开文俘描逑,醚及支持虚整存储 的页装等操作系统开销。 操作系统通j 遣在进程之间切换来划分可利用的c p u 时间,这种技术称作多 任务调度。 一个进程和下一个进程之间的上下文切换需要相当大的c p u 开销,即使在 今天裙当抉戆系绞上,一次上下文稳筷篷要花上数酉微秒豹时阉。 为避免这些问题,一些系统,例如m mc i c s 推出了远程处理监控器的概 念。这样的系统中有单一的一个驻务进程,所有自远程终端都与它连接,运种 模式称作为单服务器模式。远程终端惚请求发送到服务器进程,然后出服务器 进程执行这些请求。这种模式也可以用在客户一服务器环境中,客户将请求发送 裂单一戆殿务器进程,服务器避程垒奎理翅臻户鉴裂等 王务,翔袋没有服务嚣遴 程,这些任务通常由操作系统执行。为了避免在处理一个客户的长时间请求时 硕二 学位论文基于妊带务处理的分布式框柴

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论