transaction

定义

transaction是一个英语名词,复数形式为transactions,读音在英式英语中为/trænˈzækʃn/,美式英语中为/trænˈzækʃən/^[1]。其基本含义指一次办理完毕的事务,或一笔买卖、业务^[1]。作为可数名词,它的英英释义包括“在群体内部或之间进行事务的行为,如从事商业活动”^[2]。

形容词形式为transactional,由transaction加后缀-al构成,该形式在1858年已有记录^[3]。除商业义项外,该词的复数形式还指学会、会议等活动的书面记录或已出版的会议录、学报^[4]。在计算机科学中,该词指一项数据的传输与处理,或获取并支付某商品、服务的行为^[4]。

汉语中通常把它译作“交易”或“事务”,具体含义依语境而定。相关义项还延伸到心理学领域,指个体与一个或多个他人之间受各自角色关系影响的互动^[4]。

原理

在数据库系统中,一个事务可定义为一组动作的集合,这些动作共同构成对系统状态的一致性变换,把系统从一个一致状态转到另一个一致状态^[5]。为保证这种变换可靠,事务通常被要求具备原子性、一致性、隔离性和持久性,这4项性质后来被概括为ACID^[6]。

原子性表示事务要么完全发生,要么完全不发生,不允许停在中间状态;一致性要求它遵守合法协议;隔离性允许事务并发执行,但对每个成功的事务而言,其结果须等同于按某一串行顺序执行;持久性则规定事务一旦提交便不能撤回^[5]。事务被中止时,其全部效果需要撤销^[5]。

并非所有动作都能撤销。相关研究把动作分为未受保护、受保护和真实3类:未受保护的动作涉及临时文件等暂态状态,无需重做或撤销;受保护的动作归入事务,其效果必须提交或清除;真实动作涉及数据库之外的传感器、执行器和消息,一旦完成只能通过补偿措施抵消^[7]。

为在出现处理器、内存或存储故障时仍保持持久原子性,需要保留数据的多个副本,并记录受保护动作的序列。前置写日志(Write Ahead Log)协议在改动写回稳定存储之前,先把新旧状态的记录写入稳定日志;事务的提交只需在恢复日志中追加一条提交记录^[7]。

涉及多个资源的事务依靠提交协议协调。两阶段提交协议分投票和决定2个阶段:协调者先请所有参与者表决,任一参与者投否决票或超时即中止;若全部同意则发出提交指令^[8]。在投票结束与收到决定之间,参与者处于不确定状态,只能等待协调者恢复或向其他参与者询问结果;最坏情况下,n 个不确定的参与者询问其余 n-1 个,会产生 O(n²) 条消息^[8]。

发展历程

该词约在15世纪中期以transacciōn的形式出现于英语,当时属民法用语,指双方互相让步以解决争端、经协商达成的协议,或对事务的处理与了结;它借自法语和晚期拉丁语,源头是拉丁语transigere,由trans(穿过、越过)与agere(驱动、做)组合而成,字面意思是“驱动通过”^[3]。

“已办完或已了结的一笔业务”这一含义在17世纪40年代有记录;用transactions指学术团体所收到的多篇论文的报告或出版物,则始于17世纪60年代^[3]。古法语形式transaccion同样含有交换、交易之意^[3]。

20世纪70年代,供职于IBM圣何塞研究实验室的吉姆·格雷(Jim Gray)定义并发展了在线事务处理系统所依赖的基本概念与技术^[7]。1981年,他在第7届超大型数据库会议(VLDB)上发表《事务概念:优点与局限》,把事务表述为具有原子性、持久性和一致性的一种状态变换^[9]。

1983年,特奥·哈德(Theo Härder)与安德烈亚斯·罗伊特(Andreas Reuter)发表论文,用ACID这4个首字母为原子性、一致性、隔离性和持久性命名^[6]。格雷与罗伊特后来合著《分布式事务处理:概念与技术》,系统总结该领域^[10]。1998年,格雷因对数据库与事务处理的贡献获得图灵奖^[7]。

应用

事务处理最典型的应用是在线事务处理,即面向交互式应用、请求收到后较短时间内处理并返回的一类工作负载。IBM的文档把这类商业应用的关键特征列为:参与者众多、过程重复、交互时间短、数据共享、数据完整性要求高、单笔事务成本低^[11]。

为有组织地处理这类事务,业界发展出事务处理监视器,简称TP监视器。它与应用服务器配合,负责在多个用户之间调度和复用服务器进程,并提供启动、结束事务的接口^[12]。商用产品中较为常见的有IBM的CICS、BEA的Tuxedo与WebLogic、微软的事务服务器等^[11]。

当一笔事务需要更新多个资源时,各数据库厂商的专有接口会带来互通困难。为此业界定义了监视器与被访问资源之间的公共接口,即XA接口;采用该接口的监视器称为符合XA的事务管理器,实现该接口的可更新资源称为符合XA的资源管理器^[11]。

银行转账是说明这一机制的常见例子:从甲账户所在数据库扣款、向乙账户所在数据库存款,两者须在同一事务内完成,而这两个数据库可能来自不同厂商^[11]。事务处理监视器作为最古老的中间件形态之一,其早期实现运行于大型机上,为大规模在线事务处理应用提供运行环境^[13]。

局限

ACID性质本身被认为是一种能力上限而非万能保证。格雷在1981年的论文中指出,事务概念仍有若干待研究之处,包括与抽象数据类型的结合、让事务由子事务组合的技术,以及处理持续数天乃至数月之久的极长事务^[9]。

分布式提交协议存在固有的阻塞风险。在两阶段提交中,参与者投票后必须等待协调者的决定,期间会阻塞并锁定资源;加上最坏情况下较高的通信复杂度,该协议在参与服务数量增加时不易扩展^[8]。当协调者本身与已表态可提交的参与者同时发生故障时,阻塞就会发生,被阻塞的事务会一直占用资源,直到协调者恢复并发出最终指令^[14]。

已有研究指出,在同时存在站点故障与链路故障的情况下,不存在既能免于两者影响又非阻塞的提交协议^[15]。针对阻塞问题提出的三阶段提交协议虽然避免了阻塞,但要多一轮消息传递,从而增加开销、延长事务完成时间^[14]。

此外,事务模型对不可撤销的现实动作无能为力。现实中付款、发出确认消息、打印凭证等动作一旦执行便无法回滚,撤销只能抹去记录,不能收回已交付的现金或已发出的通知^[6]。对这类动作,系统只能采用补偿措施,而不是真正的中止^[7]。

术语本身的边界也偏模糊。图灵奖得主格雷曾评论说,如果要评选定义最不严谨的软件术语,事务处理监视器会是有力的竞争者^[13]。

参见

• ACID —— 概括事务原子性、一致性、隔离性与持久性4项性质的一组缩写。

• 两阶段提交 —— 协调分布式事务各参与方一致提交或中止的协议。

• 数据库 —— 事务概念最主要的应用环境。

• 前置写日志 —— 保证事务在故障后可以重做或撤销的日志机制。

• 在线事务处理 —— 以短时交互、重复执行为特征的事务处理应用形态。

• 并发控制 —— 通过锁等手段保证事务隔离性的机制。