CN103473318A - 一种面向内存数据网格的分布式事务保障方法 - Google Patents

Abstract

一种面向内存数据网格的分布式事务保障方法，首先是服务节点选定，即在客户端发出事务请求后，内存数据网格首先为该事务选定对应的服务节点；然后事务启动，将服务节点作为事务协调者，利用客户端的源地址和线程ID等信息为标识为该事务请求创建并保存事务上下文和事务ID。接着进入内存数据网格两阶段提交协议的第一阶段，进行数据操作后，进入内存数据网格两阶段提交协议的第二阶段，进行事务提交或事务回滚。本发明采用多个事务协调者，避免单节点瓶颈，并且不需要远程调用第三方事务管理器，可以避免产生额外的通信代价,同时降低事务协调和事务状态维护的代价。

Description

一种面向内存数据网格的分布式事务保障方法

技术领域

本发明涉及一种分布式事务保障方法，尤其针对一种面向内存数据网格的分布式事务保障方法，属于软件技术领域。 

背景技术

在线事务处理(OLTP,Online Transaction Processing)是指通过信息系统、计算机网络、数据库等基础设施，以事务为基本操作单位来处理实时性作业任务。图1描述了传统在线事务处理应用的传统运行环境，根据模块的不同功能可以分为展示层、业务层和数据层等。前端采用集群技术，由负载均衡器、Web服务器和应用服务器组成。在后端通常采用分布式缓存加快数据读取速度。分布式缓存是一种简单的内存键值对存储系统，不保障数据操作的事务性，仅可以提高数据读操作的速度，并且增加了应用业务逻辑的复杂度。 

内存数据网格是新型的内存键值对存储系统，可替代传统的分布式缓存，其运行环境如图2。内存数据网格与分布式缓存在使用上的最大不同在于内存数据网格提供了事务保障机制，并且可以简化应用的开发，并提供持久化机制来将内存中的数据自动存储于数据库中。 

由于内存数据网格是分布式的数据访问平台，在该系统中，用户的一个分布式事务包含多条数据操作。由于这些数据分布在不同的内存数据网格节点上，因此各节点的事务参与者在执行局部事务的同时，需要通过事务协调者来负责协调局部事务的处理进度，从而实现OLTP应用的分布式事务保障。 

在现有方案中，Oracle Coherence(http://www.oracle.com/technetwork/middleware/coherence/overview/)和JBoss Infinispan(http://www.jboss.org/infinispan/)等本身都不支持分布式事务，需要集成第三方事务管理器才能实现分布式事务。这种方式使得系统的所有事务都会交给单独的事务协调者进行处理，容易形成单点瓶颈，并且，由于需要远程集成第三方事务管理器，所以会产生额外的通信代价。Hazelcast(http://www.hazelcast.com/)等提供了分布式事务保障机制，但由于采用客户端驱动的数据定位方式，客户端在事务处理过程中需要和多个服务器端节点进行交互，导致事务协调以及状态维护的代价巨大，影响系统性能。 

存在一些针对键值对存储的事务保障机制的研究工作。例如，Scatter(Glendenning L,Beschastnikh I,Krishnamurthy A,et al.Scalable consistency in Scatter[C]//Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles.ACM,2011:15-28.)是基于Paxos协议实现的具有两级拓扑结构的存储系统，可以支持同一存储组内部的事务保障，但无法支持跨存储组的事务保障。G-Store(Das S,Agrawal D,El Abbadi A.G-store:a scalable data store for transactional multi key access in the cloud[C]//Proceedings of the1st ACM symposium on Cloud computing.ACM,2010:163-174.)通过数据迁移的方法来避免分布式事务，当服务器端获取到客户事务请求后，把该请求涉及的数据全部迁移到接收请求的节点，然后此节点将负责处理相关数据的访问。该方法是将分布式事务改为局部事务来处理，适用于长事务的场景，且不能解决事务冲突。上述工作适用于对数据一致性要求较弱的应用系统，无法满足OLTP应用的事务保障需求。 

发明内容

本发明的目的在于：克服现有技术的不足，提供一种面向内存数据网格的分布式事务保障方法,采用多个事务协调者，避免单节点瓶颈，并且不需要远程调用第三方事务管理器，可以避免产生额外的通信代价,同时降低事务协调和事务状态维护的代价。 

本发明技术解决方案：一种面向内存数据网格的分布式事务保障方法，其特点在于实现步骤如下： 

（1）服务节点选定 

客户端的每次事务请求被发送给服务器端的某一个特定节点，并将该节点作为本次事务的服务节点及事务协调者。 

（2）事务启动 

在服务节点接收到来自客户端发起的事务启动请求后，事务协调者为该事务创建并保存事务上下文信息以及事务ID信息。 

（3）数据操作 

当事务启动后，后续数据操作遵照内存数据网格两阶段提交协议进行。所有的后续数据操作请求首先进行协议第一阶段处理，然后再进入协议第二阶段。协议第一阶段即请求阶段，在该阶段内，事务协调者首先采用服务器端驱动的数据定位方式进行数据定位，确认数据操作的目标数据所在的内存数据网格节点，并将这些节点作为事务参与者。然后，事务协调者将数据操作请求转发给事务参与者。事务参与者在接收到来自事务协调者的数据操作请求后，首先尝试封锁相关数据，若封锁数据成功，则以事务操作日志的形式记录数据操作请求的内容，然后向事务协调者确认可以执行数据操作，若封锁数据失败，则告知事务协调者无 法执行数据操作。事务协调者判断事务参与者的数据操作请求应答，当出现失败应答时，则进入步骤（5），若所有应答均为成功应答，则进入步骤（4）。 

（4）事务提交 

在完成所有数据操作请求的处理后，客户端发送事务提交请求。在事务协调者接收到事务提交请求后，进入内存数据网格两阶段提交协议的第二阶段，即提交阶段。事务协调者通知所有事务参与者进行事务提交操作。事务参与者根据事务操作日志信息修改实际数据，然后解除数据封锁并清除日志。接着，事务参与者回复确认消息给事务协调者。当所有的事务参与者均确认数据操作执行成功后，事务协调者销毁事务上下文，结束本次事务请求的处理。 

（5）事务回滚 

若事务参与者的数据操作无法成功执行，则进入协议第二阶段，并执行事务回滚操作。在事务协调者接收到事务回滚请求后，通知所有事务参与者解除数据封锁，并清除相关事务操作日志。然后，事务协调者销毁事务上下文，结束本次事务请求的处理。 

与现有技术相比，本发明具有如下技术优势： 

1、传统技术通常采用集成第三方事务管理器的方式，整个系统的所有事务都会交由单独的事务协调者进行处理，易形成单点瓶颈，并给系统带来额外的通信代价。本发明方法采用多个事务协调者，可避免单节点瓶颈，并且，不需要远程调用第三方事务管理器，可以避免产生额外的通信代价。 

2、传统技术通常采用客户端驱动的数据定位方式，事务的协调工作需要在客户端与服务器端之间频繁的交换事务状态和并发控制状态，给系统带来额外的通信和计算代价。本发明采用服务器端驱动的数据定位方式，事务请求由接收事务的服务节点负责协调，每次数据定位至多需要两次数据转发，可以有效降低事务协调和事务状态维护的代价。 

附图说明

图1为在线事务处理应用的传统运行环境。 

图2为内存数据网格部署图。 

图3为本发明方法的流程图。该流程图中包含内存数据网格两阶段提交协议的流程。其中，第一阶段为数据操作的请求阶段，并不会发生对数据的修改操作；第二阶段进行为事务提交或回滚阶段，最终修改数据或者回滚所有操作。 

图4为事务启动操作的处理流程图。其中服务节点在接收到客户端的事务启动请求后，创建并保存事务上下文以及事务ID。 

图5为数据操作的处理流程图。首先事务协调者检查并更新事务上下文信息；然后事务参与者根据请求消息查找对应上下文，对相关数据进行封锁，进行相关访问操作，返回相应 结果到事务协调者；最后事务协调者根据来自事务参与者的处理结果，生成最终结果并返回给客户端。 

图6为事务提交操作的处理流程图。其中事务协调者负责通知事务参与者提交数据更改、解除封锁以及销毁本地事务上下文等操作；事务参与者则根据相关请求消息执行对应操作；当事务协调者接收来自所有事务参与者的消息后，清除当前事务上下文信息，最后返回对应请求消息。 

图7为事务回滚操作的处理流程图。其中事务协调者查找相关事务上下文，若未找到相关事务上下文，则标记处理失败并返回请求，否则根据上下文信息向每个事务参与者发送回滚请求；事务参与者负责处理具体的事务回滚请求，并返回相关确认消息；当事务协调者接收到所有事务参与者的确认消息后，清除当前事务上下文并返回相关请求消息。 

具体实施方式

以下结合具体操作特征和附图对本发明进行详细说明。 

本发明实施的完整过程如图3所示。首先是服务节点选定，即在客户端发出事务请求后，内存数据网格首先为该事务选定对应的服务节点。然后事务启动，将服务节点作为事务协调者，利用客户端的源地址和线程ID等信息为标识为该事务请求创建并保存事务上下文和事务ID。接着进入内存数据网格两阶段提交协议的第一阶段，进行数据操作。最后，进入内存数据网格两阶段提交协议的第二阶段，进行事务提交或事务回滚。 

在上述流程基础上，本发明实施例的具体实现流程如下： 

1、服务节点选定 

首先根据服务器端节点的负载分布情况或者采用随机策略，选择服务器端的特定节点作为本次事务的服务节点及事务协调者。 

2、事务启动 

事务启动请求的处理流程如图4所示，具体步骤如下： 

（1）事务协调者（即服务节点）接收来自客户端的事务启动请求； 

（2）事务协调者解析请求，获取请求中包含的客户端的源地址信息和线程ID信息； 

（3）根据解析的信息，事务协调者创建并保存该事务请求对应的事务上下文及事务ID； 

（4）事务协调者标记事务启动请求处理成功，向客户端返回事务启动成功应答。 

3、数据操作 

在完成事务启动后，进入内存数据网格两阶段提交协议的第一阶段，后续数据操作请求由客户端交由事务协调者处理，事务参与者也将参与到处理的过程中，事务参与者可能与事 务协调者位于同一节点，也可能位于不同节点。数据操作的处理流程如图5所示，具体步骤如下： 

（1）事务协调者接收来自客户端的数据操作请求； 

（2）事务协调者解析发送请求的客户端的源地址和线程ID信息，并根据上述信息获取相应的事务上下文； 

（3）事务协调者采用服务器端驱动的数据定位方式进行数据定位，根据请求的键信息确认事务参与者地址，并将该地址保存在事务上下文中； 

（4）事务协调者将数据操作请求发送给相关事务参与者，并等待来自事务参与者的应答； 

（5）事务参与者接收到来自事务协调者发送的数据操作请求后，具体的数据操作过程包含以下步骤： 

（5.1）事务参与者提取请求消息中的事务ID信息，并根据事务ID查找本地的事务上下文信息； 

（5.2）事务参与者判断数据操作类型，若为读操作，则进入步骤（5.3），若为写操作则进入步骤（5.5）； 

（5.3）事务参与者判断内存数据网格节点是否已经对读操作请求的目标数据进行封锁。如果尚未将该数据封锁，则创建相关锁对象并设置为共享锁，然后进入步骤（5.4）；如果已经将该数据封锁，则判断锁对象类型，若为共享锁，则进入步骤（5.4），若为排它锁，则标记处理失败，进入步骤（5.7）； 

（5.4）事务参与者获取数据并将数据操作应答返回给事务协调者； 

（5.5）事务参与者判断内存数据网格节点是否已经对写操作请求的目标数据进行封锁。如果尚未将该数据封锁，则创建相关锁对象并设置为排它锁，然后进入步骤（5.6）；如果该数据已经被封锁，则标记处理失败，进入步骤（5.7）； 

（5.6）事务参与者根据操作类型和目标数据信息，创建并保存事务日志； 

（5.7）事务参与者返回数据操作是否成功的应答给事务协调者； 

（6）事务协调者接收事务参与者的应答，若出现失败应答，则标记数据操作处理失败，若应答均为成功应答，则标记数据操作处理成功； 

（7）事务协调者将数据操作处理结果返回给客户端，若处理失败则在客户端抛出异常，则进入步骤4，执行协议第二阶段的事务回滚操作，否则进入步骤5，执行协议第二阶段的事务提交操作。 

4、事务提交 

在成功完成后续数据操作后，进入内存数据网格两阶段提交协议的第二阶段。事务提交的处理流程如图6所示，具体步骤如下： 

（1）事务协调者接收来自客户端的事务提交请求； 

（2）事务协调者解析发送请求的客户端的源地址和线程ID信息，并根据上述信息获取相应的事务上下文； 

（3）事务协调者从该事务上下文中提取事务参与者的相关信息； 

（4）事务协调者将事务提交请求发送给相关事务参与者，并等待来自事务参与者的应答； 

（5）事务参与者接收到来自事务协调者发送的事务提交请求后，具体的事务提交过程包含以下步骤： 

（5.1）事务参与者提取事务提交请求消息中的事务ID信息，并判断相应数据操作类型。若为读操作，则进入步骤（5.2），若为写操作，则进入步骤（5.3）； 

（5.2）事务参与者解除相关数据的封锁，然后进入步骤（5.6）； 

（5.3）事务参与者根据事务提交请求消息中的事务ID信息，从本地存储中提取与该事务相关的日志记录集合； 

（5.4）事务参与者针对日志集合中的每一条日志，执行相应读写操作。每次处理完一条日志，事务参与者将该日志从日志集合中删除； 

（5.5）事务参与者解除相关数据的封锁，并清除当前事务上下文信息； 

（5.6）事务参与者返回事务提交是否成功的应答给事务协调者； 

（6）事务协调者收所有事务参与者的应答，清除当前事务上下文信息； 

（7）事务协调者向客户端返回事务提交应答。 

5、事务回滚 

在分布式事务处理的过程中，很多情况可能导致事务不能按照预期的方式执行，比如在数据操作阶段封锁相关数据失败将导致不能进行后续操作，客户端会抛出异常消息，此时将导致事务的回滚操作。在事务回滚阶段，事务协调者通知各个事务参与者放弃相关数据操作的执行计划，以保证当前事务的数据操作请求没有对数据造成修改，并解除当前事务的所有封锁。事务回滚请求的处理流程如图7所示，具体步骤如下： 

（1）事务协调者接收来自客户端的事务回滚请求； 

（2）事务协调者解析发送请求的客户端的源地址和线程ID信息，并根据上述信息获取相应的事务上下文； 

（3）事务协调者从已保存的事务上下文中提取出所有事务参与者的信息； 

（4）事务协调者将事务回滚请求发送给所有事务参与者，并等待来自事务参与者的应答； 

（5）事务参与者接收到来自事务协调者发送的事务回滚请求后，具体的事务回滚执行包含以下步骤： 

（5.1）事务参与者提取事务回滚请求消息中的事务ID信息，并判断相应数据操作类型，若为写操作，则进入步骤（5.2），若为读操作，则进入步骤（5.3）； 

（5.2）事务参与者根据此事务ID信息查看本地事务上下文中参与此事务操作的日志记录集合，并清除对应日志信息，进入步骤（5.3）； 

（5.3）事务参与者解除相关数据的封锁，并清除当前事务的上下文信息； 

（5.4）事务参与者返回事务回滚成功应答给事务协调者； 

（6）事务协调者收到所有事务参与者的应答消息后，清除当前事务的上下文信息； 

（7）事务协调者向客户端返回事务回滚应答。 

本发明未详细阐述部分属于本领域技术人员的公知技术。 

以上所述，仅为本发明中的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉该技术的人在本发明所揭露的技术范围内，可理解想到的变换或替换，都应涵盖在本发明的包含范围之内，因此，本发明的保护范围应该以权利要求书的保护范围为准。 

Claims (5)

1.一种面向内存数据网格的分布式事务保障方法，其特征在于实现步骤如下：

（1）服务节点选定

客户端的每次事务请求被发送给服务器端的某一个节点，并将该节点作为本次事务的服务节点及事务协调者；

（2）事务启动

在服务节点接收到来自客户端发起的事务启动请求后，事务协调者为该事务创建并保存事务上下文信息以及事务ID信息；

（3）数据操作

当事务启动后，后续数据操作遵照内存数据网格两阶段提交协议进行，所有的后续数据操作请求首先进行协议第一阶段处理，然后再进入协议第二阶段；协议第一阶段即请求阶段，在该阶段内，事务协调者首先采用服务器端驱动的数据定位方式进行数据定位，确认数据操作的目标数据所在的内存数据网格节点，并将这些节点作为事务参与者，然后事务协调者将数据操作请求转发给事务参与者；事务参与者在接收到来自事务协调者的数据操作请求后，首先尝试封锁相关数据，若封锁数据成功，则以事务操作日志的形式记录数据操作请求的内容，然后向事务协调者确认可以执行数据操作，若封锁数据失败，则告知事务协调者无法执行数据操作；事务协调者判断事务参与者的数据操作请求应答，当出现失败应答时，则进入步骤（5），若所有应答均为成功应答，则进入步骤（4）；

（4）事务提交

在完成所有数据操作请求的处理后，客户端发送事务提交请求；在事务协调者接收到事务提交请求后，进入内存数据网格两阶段提交协议的第二阶段，即提交阶段；事务协调者通知所有事务参与者进行事务提交操作，事务参与者根据事务操作日志信息修改实际数据，然后解除数据封锁并清除日志，接着事务参与者回复确认消息给事务协调者；当所有的事务参与者均确认数据操作执行成功后，事务协调者销毁事务上下文，结束本次事务请求的处理；

（5）事务回滚

若事务参与者的数据操作无法成功执行，则进入协议第二阶段，并执行事务回滚操作；在事务协调者接收到事务回滚请求后，通知所有事务参与者解除数据封锁，并清除相关事务操作日志，然后事务协调者销毁事务上下文，结束本次事务请求的处理。

2.根据权利要求1所述的面向内存数据网格的分布式事务保障方法，其特征在于：所述步骤（1）中，根据服务器端节点的负载分布情况或者采用随机策略，选择服务器端的特定节点作为本次事务的服务节点及事务协调者。

3.根据权利要求1所述的面向内存数据网格的分布式事务保障方法，其特征在于：所述步骤（3），在完成事务启动后，后续数据操作请求由事务协调者与事务参与者处理，其中事务参与者负责的数据操作的具体步骤如下：

（3.1）事务参与者提取请求消息中的事务ID信息，并根据事务ID查找本地的事务上下文信息；

（3.2）事务参与者判断数据操作类型，若为读操作，则进入步骤（3.3），若为写操作则进入步骤（3.5）；

（3.3）事务参与者判断内存数据网格节点是否已经对读操作请求的目标数据进行封锁。如果尚未将该数据封锁，则创建相关锁对象并设置为共享锁，然后进入步骤（3.4）；如果已经将该数据封锁，则判断锁对象类型，若为共享锁，则进入步骤（3.4），若为排它锁，则标记处理失败，进入步骤（3.7）；

（3.4）事务参与者获取数据并将数据操作应答返回给事务协调者；

（3.5）事务参与者判断内存数据网格节点是否已经对写操作请求的目标数据进行封锁；如果尚未将该数据封锁，则创建相关锁对象并设置为排它锁，然后进入步骤（3.6）；如果该数据已经被封锁，则标记处理失败，进入步骤（3.7）；

（3.6）事务参与者根据操作类型和目标数据信息，创建并保存事务日志；

（3.7）事务参与者返回数据操作是否成功的应答给事务协调者。

4.根据权利要求1所述的面向内存数据网格的分布式事务保障方法，其特征在于：所述步骤（4），在成功完成后续数据操作后，事务参与者提交的具体步骤如下：

（4.1）事务参与者提取事务提交请求消息中的事务ID信息，并判断相应数据操作类型；若为读操作，则进入步骤（4.2），若为写操作，则进入步骤（4.3）；

（4.2）事务参与者解除相关数据的封锁，然后进入步骤（4.6）；

（4.3）事务参与者根据事务提交请求消息中的事务ID信息，从本地存储中提取与该事务相关的日志记录集合；

（4.4）事务参与者针对日志集合中的每一条日志，执行相应读写操作；每次处理完一条日志，事务参与者将该日志从日志集合中删除；

（4.5）事务参与者解除相关数据的封锁，并清除当前事务上下文信息；

（4.6）事务参与者返回事务提交是否成功的应答给事务协调者。

5.根据权利要求1所述的面向内存数据网格的分布式事务保障方法，其特征在于：所述步骤（5），事务回滚请求的具体步骤如下：

（5.1）事务参与者提取事务回滚请求消息中的事务ID信息，并判断相应数据操作类型，若为写操作，则进入步骤（5.2），若为读操作，则进入步骤（5.3）；

（5.2）事务参与者根据此事务ID信息查看本地事务上下文中参与此事务操作的日志记录集合，并清除对应日志信息，进入步骤（5.3）；

（5.3）事务参与者解除相关数据的封锁，并清除当前事务的上下文信息；

（5.4）事务参与者返回事务回滚成功应答给事务协调者。

Images