CN108446167A - 一种分布式事务处理方法及系统 - Google Patents

Abstract

本发明公开了一种分布式事务处理方法及系统，方法包括：启动最外层事务，并分配唯一的最外层事务ID；调用多业务配置服务的RPC接口为不同服务分配资源，并将最外层事务ID传递到多业务配置服务中；以外层事务ID为父事务依次嵌套多层新事务ID，每层新事务ID为上一层的子事务；由父事务向子事务方向，依次在每层新事务ID进行多业务配置服务、网元服务、基础服务进行资源分配，并上传对应服务名称和父事务ID；当所有事务中的资源分配操作全部成功时用户在GUI上点击配置提交，调用事务管理器的Commit保存整个事务。本发明保证了数据的最终一致性，避免了全局锁的使用，大大提高了用户操作的并发效率。

Description

一种分布式事务处理方法及系统

技术领域

本发明涉及电信传输网管中业务配置数据技术，具体涉及一种分布式事务处理方法及系统。

背景技术

在电信传输网管中，当配置业务时会涉及到各种资源的锁定、占用、释放和解锁，例如，创建PTN(Packet Transport Network，分组传送网)的 TMP层(Tunnel层)通道时，会涉及到标签的分配；创建E-Line、E-Tree业务时，会涉及到带宽的分配等。在创建过程中，会先将资源设置成锁定，只有所有步骤全部都成功的时候，才会将资源设置成占用，创建过程中的任何一步失败，都需要将锁定了的资源设置成解锁，可见，这种资源状态的控制方案非常复杂，特别容易出现业务配置数据不一致的情况。

随着电信传输网管管理容量扩大，网管发展为分布式架构，创建一条业务涉及各个子系统中资源的分配，当某个子系统处理不正常时，经常会发现资源状态不正常的情况，如某端设备本来可以配置业务，但是网管系统中却显示无可用资源,或者是设备已经无可用资源，但是网管系统中却还可以配置业务，这将导致后续在该设备上继续配置业务时导致资源冲突，甚至影响已经在该设备上面创建好了的业务不通。

有鉴于此，在分布式架构中，亟需一种既能保证各子系统数据的一致性，又可以提高多用户配置业务并发效率的分布式事务处理方案。

发明内容

本发明所要解决的技术问题是在分布式架构电信传输网管系统中，如何实现既能保证各子系统数据的一致性，又可以提高多用户配置业务并发效率的问题。

为了解决上述技术问题，本发明所采用的技术方案是提供一种分布式事务处理方法，包括以下步骤：

步骤S1、GUI启动最外层事务，并调用事务管理器分配一个唯一的最外层事务ID；

步骤S2、GUI多次调用多业务配置服务的RPC接口为不同服务分配资源，并将最外层事务ID传递到多业务配置服务中；

步骤S3、调用多业务配置服务的RPC接口分配资源,事务管理器以外层事务ID作为其父事务ID为每个服务分别分配一个第二层事务ID，并将该第二层事务ID对应的服务名称和其父事务ID传给事务管理器，再为每个服务分配本地资源以及调用网元服务的RPC接口分配资源；

步骤S4、调用网元服务的RPC接口分配资源，事务管理器以第二层事务ID为父事务ID开启一个第三层事务ID，再分配本地资源和调用基础服务的RPC接口分配资源；

步骤S5、调用基础服务的RPC接口实现资源分配，在基础服务中以第三层事务ID为父事务ID开启一个第四层事务ID，并分配本地资源；

步骤S6、判断步骤S5中分配资源是否全部成功，如果成功，调用事务管理器RPC接口Commit，将第四层事务ID的状态修改为Commit；否则，调用事务管理器的RPC接口RollBack，滚回到第四层事务ID，在基础服务中进行资源的释放；

步骤S7、判断在第三层事务ID中的操作是否全部成功，如果全部成功，调用事务管理器RPC接口Commit，将第三层事务ID的事务状态修改为 Commit；否则，回滚到第三层事务ID和第四层事务ID，并进行资源释放；

步骤S8、判断在第二层事务ID中的操作是否全部成功，如果全部成功，调用事务管理器RPC接口Commit，将第二层事务ID的事务状态修改为Commit；否则，回滚到第二层事务ID、第三层事务ID和第四层事务ID，进行资源释放；

步骤S9、当创建业务的所有步骤都成功后，用户在GUI上点击配置提交或者取消，GUI调用事务管理器的Commit或RollBack，保存或释放整个事务。

在上述方法中，多业务配置服务中的任何本地资源分配操作都会加入到第二层事务ID的操作链中，并且在对应服务的RPC接口中多次调用网元服务的资源分配接口。

在上述方法中，在步骤S3、步骤S4和步骤S5中的资源分配，具体包括以下步骤：

步骤S31、资源服务收到资源分配的RPC请求，从RPC接口上、下文中获取得到的外层事务OutterID，并以外层事务OutterID为父事务ID开启一个新事务NewID，并将新事务NewID的服务名称和外层事务OutterID发送给事务管理器；

步骤S32、检查资源是否被加入到锁定区，如果锁定，则执行步骤S33；否则，执行步骤S34；

步骤S33、判断资源是否被本事务锁定，如果是，执行步骤S34；否则，抛异常告知用户。

步骤S34、进行资源分配，并将分配的资源生成一个操作，然后作为事务对象按顺序加入到事务操作链中，并持久化到资源服务的本地文件数据库中；

步骤S35、判断本资源服务中调用其他资源服务获取资源或者获取本地资源是否全部成功，如果成功，执行步骤S36；否则，执行步骤S37；

步骤S36、调用事务管理器的Commit，保存修改的事务；

步骤S37、调用事务管理器的RollBack，回滚到当前层事务ID和其子事务ID，进行资源释放。

在上述方法中，同一事务可以锁定同一资源多次，并记录锁定的次数。

在上述方法中，将对于资源分配的资源提炼成事务对象，每一事务对象都有一个唯一Key，事务对事务对象进行管理；

在锁定区中，记录了事务对象和事务ID之间的关系，控制同一事务对象被一个事务处理时，其他事务不能处理该事务对象。

在上述方法中，

读取事务对象属性时，获取得到的事务对象是只读对象；

修改事务对象属性时，得到的事务对象是被修改对象的拷贝对象，并在修改完成后将最新的事务对象替换到事务管理中；

修改的过程会自动构建成一个操作加入到事务操作链中，并持久化操作到文件数据库；

增加或者删除事务对象时，将被增加或者删除的事务对象构建成一个操作，然后加入或删除事务操作链。

在上述方法中，在步骤S6、步骤S7、步骤S8中事务提交Commit或回滚RollBack逻辑，具体为：

子事务调用事务管理器RPC接口Commit，事务管理器根据事务嵌套关系，发现是内层事务，只是修改事务的状态，而不执行真正的Commit；

子事务中的一个资源分配操作失败，通过异常捕获，会调用事务管理器RPC接口RollBack，事务管理器会根据事务对应的资源服务名称，将 RollBack请求发送到相应资源服务中进行资源的释放；

子事务中也可以嵌套子事务，此时内层事务的状态是由外层事务来控制的。

在上述方法中，在步骤S9中，处理整个最外层事务最终Commit或 RollBack，具体包括以下步骤：

步骤S91、当整个创建过程中所有步骤都成功后，用户点击配置提交或取消，表示提交或撤销最外层事务；

步骤S92、Commit或RollBack请求发送到事务管理器，事务管理器根据事务嵌套关系和事务与资源服务关系进行分解；

步骤S93、事务管理器将Commit或RollBack请求发送到多业务配置服务；

步骤S94、事务管理器将Commit或RollBack请求发送到资源服多网元服务；

步骤S95、事务管理器将Commit或RollBack请求发送到基础服务；

步骤S96、资源服务收到请求后，根据事务ID查询缓存得到对应的操作链，然后对每一操作进行执行Commit或RollBack；

步骤S97、采用先收集后批量入库的方式，持久化资源到资源服务的数据库中存储。

在上述方法中，用户在GUI上点击配置提交有一个预提交，GUI调用事务管理器的Commit，提交最外层事务ID的数据，事务管理器根据最外层事务ID对应的事务关系和各个事务涉及到的资源服务，将Commit请求并发调用到各个资源服务进行最终提交；

在最终提交之前进行一次预提交，如果预提交失败会引起RollBack；如果预提交成功，进行最终提交。

本发名还提供了一种分布式事务处理的实现系统，包括以下模块：

用户事务模块，封装事务相关的接口，用于分布式事务使用者采用开启新事务，并按由外到内的顺序建立事务之间的嵌套关系；并通过RPC接口调用系统其他模块；

事务管理模块，被所述用户事务模块调用在每层开启的新事务时为其分配事务ID，并记录每层事务之间的关系、事务的状态、事务与资源服务关系信息，协调事务机制；

事务资源管理模块，封装事务框架中资源服务相关的处理；所述用户事务模块通过调用其封装的相关接口，多次调用各个所述事务资源管理模块在每层事务开启时为其分配不同的资源，并调用所述事务管理模块进行提交或者回滚。

本发明通过事务管理器管理事务之间的嵌套关系，以及事务和资源服务之间的关系，达到协调控制各个子系统最终的Commit或RollBack目的，保证数据的最终一致性；通过将资源抽象成事务对象，创建对应的事务管理对象，并在Commit或RollBack之前，事务对象都是放在锁定区中，保证了资源被某一事务使用的同时不能被其他事务使用，避免了全局锁的使用，大大提高了用户操作的并发效率。

附图说明

图1为本发明提供一种分布式事务处理方法的数据流程图；

图2为本发明提供一种分布式事务处理方法的时序图；

图3为本发明提供一种分布式事务处理方法的操作流程图；

图4为本发明中步骤3的具体流程图；

图5为本发明中步骤9的具体流程图；

图6为本发明提供的一种分布式事务处理的实现系统的结构示意图。

具体实施方式

下面结合说明书附图和具体实施例对本发明做出详细的说明。

如图1、图2和图3所示，本发明提供的一种分布式事务处理方法，包括以下步骤：

步骤S1、用户通过GUI(图形用户接口)开始业务创建过程，GUI启动最外层事务，调用事务管理器分配一个唯一的最外层事务ID，本步骤的目的在于启动一个最外层的事务，后续所有的子事务都嵌套在这个最外层事务中。

步骤S2、用户在创建过程中，GUI多次调用多业务配置服务的RPC(远程过程调用协议)接口为不同资源服务分配资源，并在每次调用多业务配置服务资源分配的RPC接口时，通过上、下文信息将最外层事务ID传递到多业务配置服务中，目的是建立事务之间的嵌套关系。

步骤S3、调用多业务配置服务的RPC接口实现每个资源服务的资源分配时，将重新调用事务管理器为每个资源服务分别分配一个第二层事务ID(内层事务)，并通过RPC接口上、下文获取其父事务(外层事务)ID，将其父事务ID和该第二层事务ID对应的资源服务的名称传给事务管理器，这样最外层事务ID和每个资源服务对应的第二层事务ID就关联起来，嵌套关系为最外层事务ID(第二层事务ID)，方便事务管理器管理事务之间的嵌套关系，以及事务和资源服务之间的对应关系；然后为每个资源服务分配本地资源和调用网元服务分配资源，多业务配置服务中的任何本地资源分配操作都会加入到第二层事务ID的操作链中，并且在该RPC接口中(对应一个资源服务) 会多次调用网元服务的资源分配接口。可见，本发明的步骤S2和S3表明在资源服务的每个资源分配RPC接口中都会调用事务管理器开启一个子事务，并传入父事务ID和对应服务名称，事务管理器会维护事务之间的嵌套关系以及事务与资源服务的对应关系。

步骤S4、调用网元服务的RPC接口实现资源分配时，调用事务管理器以第二层事务ID为父事务ID开启一个第三层事务ID(第二层事务的内层事务)，然后分配本地资源和调用基础服务分配资源。同多业务配置服务一样，网元服务中的任何资源分配操作都会加入到第三层事务ID的操作链中，最外层事务ID、第二层事务ID和第三层事务ID的嵌套关系为最外层事务ID (第二层事务ID(第三层事务ID))。

步骤S5、网元服务调用基础服务的资源分配RPC接口实现资源分配，在基础服务中以第三层事务ID为父事务ID开启一个第四层事务ID，并分配本地资源，最终整个事务的嵌套关系为最外层事务ID(第二层事务ID(第三层事务ID(第四层事务ID)))。

步骤S6、判断在步骤S5(对应第四层事务ID)基础服务中分配资源是否全部成功，如果成功调用事务管理器RPC接口Commit(提交第四层事务 ID数据)，事务管理器根据事务嵌套关系，发现是第四层事务ID，只是修改第四层事务ID的状态为Commit(每个事务都有三个状态，具体为提交 Commit、回滚RollBack以及准备Prepare)，而不执行真正的Commit；否则，即步骤S5某步分配失败，通过异常捕获，调用事务管理器的RPC接口 RollBack，滚回第四层事务ID，事务管理器会根据第四层事务ID对应的基础服务名称，将RollBack请求发送到基础服务中进行资源的释放；至于由于第四层事务ID的错误是否需要导致第三层事务ID的RollBack，并最终导致第一层事务ID的RollBack，这属于应用处理逻辑，因为虽然第四层事务 ID失败，用户可以尝试重启一个新的内层事务ID例如第五层事务ID，然后分配资源成功，此时事务关系就变成了最外层事务ID(第二层事务ID(第三层事务ID(第五层事务ID)))。

步骤S7、判断在第三层事务ID中的操作是否全部成功，如果全部成功，调用事务管理器RPC接口Commit，只修改第三层事务ID的事务状态；如果第三层事务ID某步操作失败，那么会回滚第三层事务ID和第四层事务ID 的操作(由于内层事务的状态是由其外层事务来控制的，第四层事务ID如果是Commit状态，但是由于第三层事务ID是RollBack状态，第三层事务 ID回滚的同时也会回滚第四层事务ID，并进行资源的释放)。

步骤S8、判断在第二层事务ID中的操作是否全部成功，如果全部成功，调用事务管理器RPC接口Commit，只修改第二层事务ID的事务状态；如果第三层事务ID某步操作失败，那么会回滚第二层事务ID、第三层事务ID 和第四层事务ID的操作。

步骤S9、当创建业务的所有步骤都成功后，用户在GUI上点击配置提交或者取消，GUI调用事务管理器的Commit或RollBack，处理整个事务过程。在本发明中，用户在GUI上点击配置提交有一个预提交的过程，GUI调用事务管理器的Commit，提交最外层事务ID的数据，事务管理器根据最外层事务ID对应的事务关系和各个事务涉及到的资源服务，将Commit请求并发调用到各个资源服务进行最终提交，即同时调用到各个资源服务，保证处理的效率；在最终提交之前会进行一次预提交的检查，保证各个资源服务都正常，如果预提交失败会引起RollBack，预提交成功之后，就认为这个事务一定是可以提交成功的，避免网络超时引起的不一致。对于认为提交成功的事务，如果某个资源服务失败，事务管理器会一直尝试，直到该事务涉及到的资源服务中对应的子事务的操作链中的操作都提交。

在本发明中，步骤S3、步骤S4和步骤S5中涉及到的资源分配，处理的步骤类似，如图4所示，具体包括以下步骤：

步骤S31、每个资源服务在收到资源分配的RPC请求时，都先从RPC接口上、下文中获取得到的外层事务OutterID，然后在该RPC接口中以外层事务OutterID为父事务ID开启一个新事务NewID。调用事务管理器分配新事务ID时，会将外层事务OutterID和开启的新事务NewID的服务名称发送给事务管理器，事务管理器维护事务ID之间的嵌套关系，以及事务ID和资源服务之间的关系；新事务NewID会设置到线程局部存储中，后续所有的资源分配抽象成的操作都会加入到该新事务NewID的操作链中。

步骤S32、资源服务进行本地资源分配时，首先检查资源是否被加入到锁定区，如果锁定，则执行步骤S33；否则，执行步骤S34，直接分配资源。

S33、如果资源被锁定，判断资源是否被本事务锁定，如果是，执行步骤S34，只有没锁定和被本事务锁定才能操作该资源，因为同一事务可以锁定某一资源多次，类似如递归锁，同一线程可以多次获取同一个锁，多次锁定时，会记录锁定的次数；否则，即被其他事务锁定，抛异常告知用户。

步骤S34、进行资源分配，并将资源分配生成操作一个操作，然后按顺序加入到事务操作链中，并保存到资源服务的本地文件数据库中。对于资源分配，需要将资源提炼成事务对象，事务对象被事务管理对象所管理，每一事务对象都有一个唯一Key，在锁定区中，记录了事务对象和事务ID之间的关系，控制同一事务对象被某一事务处理的同时，其他事务不能处理该事务对象，这样采用锁定区就可以避免采用全局锁。事务对象所对应程序语言“类”的方法被分成const方法(即不修改事务对象的方法)和非const方法(即修改事务对象的方法)，读取事务对象属性(事务对象的数据)时，调用const方法，获取得到的事务对象是只读对象；修改事务对象属性时，调用的是非const方法，得到的事务对象是被修改对象的拷贝对象，修改完成后，会将最新的对象替换到事务管理对象中；修改的过程会自动构建成一个操作(记录了对象修改之前和最后的状态)加入到事务操作链中，并持久化操作到文件数据库(当资源服务重启时，会根据事务操作日志执行Redo，恢复已提交的事务，将事务对象恢复到资源服务崩溃之前的状态)；增加或者删除时，通过调用事务管理对象的方法，将被增加或者删除的事务对象构建成一个操作，然后加入到事务操作链中。

步骤S35、判断本资源服务中调用其他资源服务获取资源或者获取本地资源是否全部成功，如果成功，执行步骤S36；否则，执行步骤S37。

在本发明中，本资源服务中调用其他资源服务获取资源或者获取本地资源如果出错，都会导致资源服务本次RPC接口中开启的事务NewID回滚，回滚请求发送到事务管理器后，事务管理器根据事务ID嵌套关系，以及事务 ID和资源服务关系，将RollBack请求发送到具体的资源服务，资源服务根据事务ID回滚事务操作链中的操作，如果是修改操作，需要将操作中保存的旧对象替换到事务管理对象中；如果是增加操作，需要从事务管理对象中删除已经增加了的事务对象；如果是删除操作，需要将操作中保存的事务对象增加到事务管理对象中。本资源服务调用其他资源服务获取资源或者获取本地资源如果都成功，那么本次RPC接口中开启的事务NewID正常提交，提交请求发送到事务管理器后，事务管理器根据事务ID嵌套关系，发现是嵌套的内层事务，那么只是修改事务的状态为Commit即可，内层事务的最终Commit还是RollBack由外层事务来确定。

步骤S36、调用事务管理器的Commit，保存修改的事务。

步骤S37、调用事务管理器的RollBack，回滚到当前层事务ID和其子事务ID，进行资源释放。

在本发明中，步骤S6、步骤S7、步骤S8都是子事务的提交Commit或回滚RollBack逻辑，这里进行详细的说明如下：

(1)子事务(嵌入最外层事务中的所有内层事务)调用事务管理器RPC 接口Commit，事务管理器根据事务嵌套关系，发现是内层事务，只是修改事务的状态，而不执行真正的Commit。

(2)子事务中的某个资源分配操作失败，通过异常捕获，会调用事务管理器RPC接口RollBack，事务管理器会根据事务对应的资源服务名称，将 RollBack请求发送到相应资源服务中进行资源的释放(从锁定区中移除)。

(3)子事务中也可以嵌套子事务，此时内层事务的状态是由外层事务来控制的，例如第四层事务ID如果是Commit状态，但是第三层事务ID是 RollBack状态，那么，第三层事务ID回滚(RollBack)的同时也会回滚第四层事务ID。

在本发明步骤S9中，如图5所示，处理整个最外层事务最终Commit或 RollBack，具体包括以下步骤：

步骤S91、当整个创建过程中所有步骤都成功后，用户点击配置提交或取消，表示提交或撤销最外层事务。

步骤S92、Commit或RollBack请求发送到事务管理器，事务管理器根据事务嵌套关系和事务与资源服务关系进行分解，为了提高处理效率，资源服务之间是并行执行请求的。

步骤S93、事务管理器将Commit或RollBack请求(传入事务ID)发送到多业务配置服务(请求是并行发送到各个资源服务的)。在本发明中，可能某个资源服务中涉及到了一个大事务中的多个子事务，如果是Commit请求，按照嵌套关系，从外层到内层一层一层事务提交，事务中的操作链是按照从前往后的顺序执行各个操作的Commit；如果是RollBack请求，按照嵌套关系，从内层到外层一层一层事务回滚，事务中的操作链是按照从后往前的顺序执行各个操作的RollBack。

步骤S94、事务管理器将Commit或RollBack请求(传入事务ID)发送到资源服多网元服务。

步骤S95、事务管理器将Commit或RollBack请求(传入事务ID)发送到基础服务。

步骤S96、资源服务收到请求后，根据事务ID查询缓存得到对应的操作链，然后对每一操作进行执行Commit或RollBack。

步骤S97、处理操作后，最终采用先收集后批量入库的方式，持久化资源到资源服务的数据库中存储。考虑到某个事务对象可能会被修改多次以及存储效率，因此在Commit时并不马上存储，只是将事务对象进行收集(针对多次修改，当某个事务对象在锁定区中的引用计数减少到1时才需要收集)，当整个事务操作链中的操作都执行Commit成功之后，再调用批量持久化的接口存储本次事务涉及到的事务对象。

如图6所示，本发明提供的一种分布式事务处理的实现系统包括以下模块：

用户事务模块(usertransaction)，封装了事务相关的接口，如 Begin/Commit/RollBack/GetTranscationID等接口，会通过RPC接口调用到 transactionmgrd。

事务资源管理模块(transresourcemgrd)，封装了事务框架中资源服务相关的处理，如事务中操作日志的持久化，将操作加入到事务中，事务管理器调用资源服务后真正Commit和RollBack等的处理。

事务管理模块(transactionmgrd)，即事务管理器，记录了每层事务之间的关系，事务的状态、事务与资源服务关系等信息，是事务机制中的协调者。

分布式事务使用者采用usertransaction开启新事务，并按由外到内的顺序建立事务之间的嵌套关系；usertransaction会调用transactionmgrd 在每层开启的新事务时为其分配事务ID；然后分布式事务使用者通过用户事务模块多次调用各个transresourcemgrd在每层事务开启时为其分配不同的资源，最终调用usertransaction进行提交或者回滚，transactionmgrd协调各个transresourcemgrd进行提交或者回滚。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种分布式事务处理方法，其特征在于，包括以下步骤：

步骤S1、GUI启动最外层事务，并调用事务管理器分配一个唯一的最外层事务ID；

步骤S2、GUI多次调用多业务配置服务的RPC接口为不同服务分配资源，并将最外层事务ID传递到多业务配置服务中；

步骤S3、调用多业务配置服务的RPC接口分配资源,事务管理器以外层事务ID作为其父事务ID为每个服务分别分配一个第二层事务ID，并将该第二层事务ID对应的服务名称和其父事务ID传给事务管理器，再为每个服务分配本地资源以及调用网元服务的RPC接口分配资源；

步骤S4、调用网元服务的RPC接口分配资源，事务管理器以第二层事务ID为父事务ID开启一个第三层事务ID，再分配本地资源和调用基础服务的RPC接口分配资源；

步骤S5、调用基础服务的RPC接口实现资源分配，在基础服务中以第三层事务ID为父事务ID开启一个第四层事务ID，并分配本地资源；

步骤S6、判断步骤S5中分配资源是否全部成功，如果成功，调用事务管理器RPC接口Commit，将第四层事务ID的状态修改为Commit；否则，调用事务管理器的RPC接口RollBack，滚回到第四层事务ID，在基础服务中进行资源的释放；

步骤S7、判断在第三层事务ID中的操作是否全部成功，如果全部成功，调用事务管理器RPC接口Commit，将第三层事务ID的事务状态修改为Commit；否则，回滚到第三层事务ID和第四层事务ID，并进行资源释放；

步骤S8、判断在第二层事务ID中的操作是否全部成功，如果全部成功，调用事务管理器RPC接口Commit，将第二层事务ID的事务状态修改为Commit；否则，回滚到第二层事务ID、第三层事务ID和第四层事务ID，进行资源释放；

步骤S9、当创建业务的所有步骤都成功后，用户在GUI上点击配置提交或者取消，GUI调用事务管理器的Commit或RollBack，保存或释放整个事务。

2.如权利要求1所述的方法，其特征在于，多业务配置服务中的任何本地资源分配操作都会加入到第二层事务ID的操作链中，并且在对应服务的RPC接口中多次调用网元服务的资源分配接口。

3.如权利要求1所述的方法，其特征在于，在步骤S3、步骤S4和步骤S5中的资源分配，具体包括以下步骤：

步骤S31、资源服务收到资源分配的RPC请求，从RPC接口上、下文中获取得到的外层事务OutterID，并以外层事务OutterID为父事务ID开启一个新事务NewID，并将新事务NewID的服务名称和外层事务OutterID发送给事务管理器；

步骤S32、检查资源是否被加入到锁定区，如果锁定，则执行步骤S33；否则，执行步骤S34；

步骤S33、判断资源是否被本事务锁定，如果是，执行步骤S34；否则，抛异常告知用户。

步骤S34、进行资源分配，并将分配资源生成一个操作，然后作为事务对象按顺序加入到事务操作链中，并持久化到资源服务的本地文件数据库中；

步骤S35、判断本资源服务中调用其他资源服务获取资源或者获取本地资源是否全部成功，如果成功，执行步骤S36；否则，执行步骤S37；

步骤S36、调用事务管理器的Commit，保存修改的事务；

步骤S37、调用事务管理器的RollBack，回滚到当前层事务ID和其子事务ID，进行资源释放。

4.如权利要求3所述的方法，其特征在于，同一事务可以锁定同一资源多次，并记录锁定的次数。

5.如权利要求3所述的方法，其特征在于，将对于资源分配的资源提炼成事务对象，每一事务对象都有一个唯一Key，事务对事务对象进行管理；

在锁定区中，记录了事务对象和事务ID之间的关系，控制同一事务对象被一个事务处理时，其他事务不能处理该事务对象。

6.如权利要求5所述的方法，其特征在于，

读取事务对象属性时，获取得到的事务对象是只读对象；

修改事务对象属性时，得到的事务对象是被修改对象的拷贝对象，并在修改完成后将最新的事务对象替换到事务管理中；

修改的过程会自动构建成一个操作加入到事务操作链中，并持久化操作到文件数据库；

增加或者删除事务对象时，将被增加或者删除的事务对象构建成一个操作，然后加入或删除事务操作链。

7.如权利要求3所述的方法，其特征在于，在步骤S6、步骤S7、步骤S8中事务提交Commit或回滚RollBack逻辑，具体为：

子事务调用事务管理器RPC接口Commit，事务管理器根据事务嵌套关系，发现是内层事务，只是修改事务的状态，而不执行真正的Commit；

子事务中的一个资源分配操作失败，通过异常捕获，会调用事务管理器RPC接口RollBack，事务管理器会根据事务对应的资源服务名称，将RollBack请求发送到相应资源服务中进行资源的释放；

子事务中也可以嵌套子事务，此时内层事务的状态是由外层事务来控制的。

8.如权利要求7所述的方法，其特征在于，在步骤S9中，处理整个最外层事务最终Commit或RollBack，具体包括以下步骤：

步骤S91、当整个创建过程中所有步骤都成功后，用户点击配置提交或取消，表示提交或撤销最外层事务；

步骤S92、Commit或RollBack请求发送到事务管理器，事务管理器根据事务嵌套关系和事务与资源服务关系进行分解；

步骤S93、事务管理器将Commit或RollBack请求发送到多业务配置服务；

步骤S94、事务管理器将Commit或RollBack请求发送到资源服多网元服务；

步骤S95、事务管理器将Commit或RollBack请求发送到基础服务；

步骤S96、资源服务收到请求后，根据事务ID查询缓存得到对应的操作链，然后对每一操作进行执行Commit或RollBack；

步骤S97、采用先收集后批量入库的方式，持久化资源到资源服务的数据库中存储。

9.如权利要求1所述的方法，其特征在于，用户在GUI上点击配置提交有一个预提交，GUI调用事务管理器的Commit，提交最外层事务ID的数据，事务管理器根据最外层事务ID对应的事务关系和各个事务涉及到的资源服务，将Commit请求并发调用到各个资源服务进行最终提交；

在最终提交之前进行一次预提交，如果预提交失败会引起RollBack；如果预提交成功，进行最终提交。

10.一种分布式事务处理的实现系统，其特征在于，包括以下模块：

用户事务模块，封装事务相关的接口，用于分布式事务使用者采用开启新事务，并按由外到内的顺序建立事务之间的嵌套关系；并通过RPC接口调用系统其他模块；

事务管理模块，被所述用户事务模块调用在每层开启的新事务时为其分配事务ID，并记录每层事务之间的关系、事务的状态、事务与资源服务关系信息，协调事务机制；

事务资源管理模块，封装事务框架中资源服务相关的处理；所述用户事务模块通过调用其封装的相关接口，多次调用各个所述事务资源管理模块在每层事务开启时为其分配不同的资源，并调用所述事务管理模块进行提交或者回滚。