CN106254466A - 基于局域网的hdfs分布式文件共享方法 - Google Patents

Abstract

本发明公开了一种基于局域网的HDFS分布式文件共享方法，包括以下步骤：1)将HDFS部署在局域网上，使用一台服务器作为主节点，即应用的监控服务器；使用其他N个服务器作为从节点，即应用的存储服务器；2)在服务器端，主节点将文件分成固定大小的多个块并存储于不同的从节点存储服务器上，且每个数据块均有2‑3个备份。本发明可以实现局域网内HDFS的社区化文件共享功能，能够大幅提高文件上传速率并降低流量资费。

Description

基于局域网的HDFS分布式文件共享方法

技术领域

本发明涉及一种基于局域网的HDFS分布式文件共享系统，属于互联网技术领域。

背景技术

在大数据的时代背景下，云存储应用日渐广泛，如微云、百度云盘等都是较为成熟的存储工具。但是由于网络带宽的限制，对于较大文件的上传耗时耗流量，同时无法及时获取其他用户的文件分享情况。当需要相应的文件资料时，需要通过相对复杂的途径去获取。

而将文件保存于某一硬件设备上，数据安全依赖于硬件设备，随着云计算技术在国内外的高速发展，基于HDFS的技术得到了广泛的应用。

HDFS(Hadoop Distributed File System分布式文件系统)的设计理念是存储超大文件，所述超大文件是指数量级相对较大的文件，包括MB、GB、TB级。流式数据访问：能够进行高效的读取，即一次写入、多次读取的方式，便于进行相应的Hadoop分析对象。在数据集生成以后，可以长时间在数据集上进行相应的分析工作。每一次分析会读取该数据集的大部分甚至全部的数据，所以读取所有的数据集时间上要比第一次记录的时间要长。HDFS可以运行在普通廉价的服务器上，在硬件出现故障的情况下，也可以通过容错策略来保证数据的高可用。

HDFS具有的特点包括：(1)HDFS将文件保存成多个副本，提供了很好的容错机制，副本丢失或者宕机的时候能够进行自动恢复。默认保存三个副本。(2)能够运行在廉价的机器上。(3)适合大数据的处理。Hadoop2.x中采用128M作为一个Block的块大小。

发明内容

本发明所要解决的技术问题是：实现文件的高速低费传输、存储与分享。

为解决上述技术问题，本发明提供一种基于局域网的HDFS分布式文件共享方法，包括以下步骤：

1)将HDFS部署在局域网上，使用一台服务器作为主节点(NameNode)，即应用的监控服务器；使用其他N个服务器作为从节点(DataNode)，即应用的存储服务器；

2)在服务器端，主节点将文件分成固定大小的多个块并存储于不同的从节点存储服务器上，且每个数据块均有2-3个备份，保证了文件的安全性，同时系统可以很方便地增加从节点以实现横向扩展，提高性能。

稳定高效的传输与存储是指在局域网范围内部署HDFS，文件上传后，主节点将文件分成多个副本存储在不同的从节点服务器，实现分布式文件存储的基本架构，将文件分片区、副本进行存储，保证存储文件不丢失。

进一步地，将HDFS文件系统与WEB容器保存文件作为一个二级缓存，所有文件暂存到web服务器上，同时文件保存到HDFS上，读取文件信息时，直接从web服务器上进行查找；若文件丢失，从HDFS上加载文件到web服务器上，以保证正常业务的进行。本发明实现了文件毫秒级查询速度，系统采用二级文件系统，参照缓存机制的原理，二级文件系统保证了文件读取的效率，使文件能够稳定快速的进行增删改查的操作，提高了系统的读写效率和用户体验。

进一步地，本发明的基于局域网的HDFS分布式文件共享方法包括用户功能服务和文件功能服务：功能是在服务器端实现的，但是是通过webservice的方式开放接口供客户端使用。

所述用户功能服务包括用户注册、登陆、好友管理；

所述文件功能服务包括文件上传、文件分享、文件管理；

所述文件分享，用户在客户端发布一个分享文件的消息到服务器端，然后存入MongoDB数据库，并允许用户指定分享文件集的封面、描述以及文件列表等，数据通过客户端上传服务器，经服务器处理后存入MongoDB数据库。

所述文件管理，包括新建目录、上传文件、下载文件、删除文件等基本操作，采用文件操作节点搜索算法(FilePrivateDtoOperate)实现文件管理功能。文件目录与文件的关系由Json的树形格式表示，所以系统采用深度优先遍历算法查询指定的树形节点，查找到相应的树形节点后，对该节点进行相应的操作，即可实现对文件的各种操作，基本操作过程为：

(1)查询得到该用户的原有文件的树形结构；

(2)输入参数，根据操作类型的不同，选择输入文件的源序列码和目标序列码；

(3)采用深度优先搜索方法(DFS)找到目标节点；

(4)对目标节点进行相应操作。

根据操作的不同，将操作类型分为：新增append、移动remove、查找search、重命名rename。利用四个基本的操作即可组装成所有的文件操作。例如，如果想新增一个文件夹，先使用DFS查找到相应的节点，在该节点下append一个新的序列码，即可完成在文件夹下新增一个文件夹的功能。再例如，如果想查找到某个文件夹下的所有的文件及其目录信息，那么使用search操作，找到指定文件夹的序列码，返回该节点下所有的privateFileDtoList数据结构即可。

进一步地，本发明结合Mysql、MongoDB两者数据库进行不同类别数据的存储：用户数据及好友关系数据存于Mysql数据库，文件地址序列化服务产生的文件地址索引、共有文件索引、文件用户关系、用户文件关系、分享文件等信息存放于MongoDB数据库；同时利用HDFS进行文件数据(包括上传文件、文件地址)的存储，极大提高了数据的存取效率。

由于MongoDB数据库本身不支持类似于关系型数据库的事务，为了能够保证业务的完整性，本发明通过编程逻辑模拟关系型数据库中的事务，从而解决MongoDB数据库中数据一致性的问题。

在MongoDB数据库中建立一张事务表(TRANSACTION表)，事务表存放以下内容：

(1)_id：事务记录唯一的id号，又称transactionId；

(2)dealType：事务状态，取值为0-4，分别表示为：初始态init、运行态process、完成态commit、终止态complete、取消态cancel五个状态；

(3)IsRollBBack：事务回滚标识符，取值0或1，0表示事务不需回滚，1表示事务需回滚；

(4)CreatedData：事务创建时间；

(5)stateDate：上一次状态改变时间；

(6)CriticalDataDtoList：用于支持多节点事务处理，其中stage表示节点，processDataDtoList表示事务所需数据，包括待处理的表名(tableName)、数据主键(primaryKey)、数据内容(data)、操作方式(operType)，operType可取值C(新增数据)、U(修改数据)、D(删除数据)。

为支持事务的多线程使用，提高运行效率，本发明利用一个线程池来管理事务管理器，线程池的本质是一个容器Context，用于保存程序执行的上下文。例如：node1(transactionId)—>nodel2(transactionId)，即第一节点将transactionId传递给第二节点，两个节点共同处理同一条事务记录，提高运行效率。同时用堆栈的方法来存储事务管理器，即put、get、pop、release方法。

建立MongoDB数据库事务框架，MongoDB数据库事务框架建立过程包括以下步骤：

步骤1：初始化事务，在MongoDB数据库中生成一条事务记录，初始化事务的状态(dealType)为init，并通过序列化生成一个唯一的12字节的节点transactionId；

步骤2：将关键数据存入MongoDB数据库事务表的processDataDtoList中，在操作数据表记录后添加节点transactionId，即对该事务进行加锁，其他数据操作等待该事务完成解锁后，才能执行，同时把节点transactionId传给其他节点，进行多线程并行处理；

步骤3：计算上一次状态改变时间(stateDate)和事务创建时间(CreatedData)的时间差，若超过设定值，如100ms，即判断事务失败(部分数据已经成功处理并解锁，但没有完成所有处理)，则执行步骤5，若事务执行成功，即在设定值100ms内事务状态更改为commit态，则执行步骤6；

步骤4：将IsRollBBack置为1，对事务进行回滚，根据事务表processDataDtoList中的数据，找到待操作的所有数据记录，回滚操作即重新对已处理的数据记录重新加锁；

步骤5：若事务不断回滚超过设定次数，如5次，即认为该事务不可完成，将事务状态置为cancel态，还原数据表内容，对数据记录进行解锁，删除该条事务记录，同时在客户端进行提醒；

步骤6：若事务完成，即可将事务状态置为complete状态，并销毁该条事务记录，加快事务查询速率；

步骤7：结束。

本发明达到的有益效果：本发明将HDFS部署在局域网上，局域网上传文件速度快，不费流量，HDFS可以保证在存在故障的情况下也能可靠地存储数据；本发明利用二级文件系统，进一步保证文件安全性，并实现文件的毫秒级查询效率；利用不同类型的数据库存储不同类型的数据，提高数据存取效率，同时利用MongoDB事务框架保证事务数据的完整性；本发明设有界面友好的客户端，方便客户进行个性化的文件管理、文件分享，极大地提高了用户体验。

附图说明

图1系统C/S架构的逻辑调用关系图；

图2系统客户端具体模块功能结构图；

图3系统服务器端框架构图；

图4模块存储位置的逻辑图；

图5系统服务器端MongoDB事务框架建立过程流程图；

图6 MongoDB关键数据的存放方式示意图；

图7系统服务器端文件二级缓存的基本架构图；

图8系统服务器端文件服务类图；

图9系统服务器端深拷贝程序流程图；

图10系统服务器端实体断言测试框架流程图。

具体实施方式

本发明依靠基于局域网的HDFS分布式文件共享系统来实现，本系统包括客户端和服务器端两个部分。下文将结合附图进行详细说明。

根据系统功能的划分，决定使用C/S架构进行实现。如图1所示：

客户端：使用HTTP请求调用相应的服务器端所开放的Webservice接口，达到处理数据的目的。本发明的客户端采用Android系统作为基础，实现服务器端接口调用及用户输入处理的作用。客户端调用服务器端接口都是以HTTP请求的方式，传递数据的格式均为Json格式的数据，采用Android HTTP请求框架okHttp作为基础的开发程序包，封装实现了okHttpUtils的编写。在用户发布或者上传数据时，客户端系统会发送相应的数据到服务器端指定的接口，实现相应的业务逻辑。客户端的模块具体服务功能如图2。

客户端基于Android进行界面设计，文件存储服务作为本系统的核心服务于在客户端中广泛使用，本文展示部分文件功能设计界面。

服务器端：主要用于处理客户端的不同请求，保证事务的完整性与数据的安全性，提供一个能够实现用户与用户之间即时通讯的接口，并提供相应的Webservice接口供客户端进行调用。根据扩展的需求，如图3所示，本发明将系统的服务器端抽象为三层进行设计，主要为操作系统层、服务器层、接口层。对于每一层，基本定位为：

操作系统层：系统所使用的组件相对复杂，所以使用Linux作为底层的操作系统。

应用层：应用层分成了数据库服务器、应用服务器、文件服务器以及监控日志服务器等。其中数据库服务器选择使用MySQL数据库与MongoDB数据库来进行存储，数据存储位置分布如图4：

使用MySQL数据库保存用户数据以及用户好友关系，即在MySQL表中建立用户表(user)和好友关系表(friend)。使用MongoDB数据库保存文件地址序列化服务产生的文件地址索引、公有文件索引、文件用户关系、用户文件关系、分享文件数据数据，数据表建设情况。

由于MongoDB数据库本身不具备事务，为保证MongoDB数据的完整性，本发明设计一个相应的事务框架来保证整个任务在执行的过程中事务具有一致性。

需要在MongoDB数据库中建立一张事务表，事务表主要存放以下内容：

(1)_id：即事务记录唯一的id号，又称transactionId；

(2)dealType：即事务状态，取值为0-4，分别表示init(初始态)、process(运行态)、commit(完成态)、complete(终止态)、cancel(取消态)五个状态；

(3)IsRollBBack：即事务回滚标识符，取值0或1，0表示事务不需回滚，1表示事务需回滚；

(4)CreatedData：事务创建时间；

(5)stateDate：上一次状态改变时间；

(6)CriticalDataDtoList：用于支持多节点事务处理。其中stage表示节点，processDataDtoList表示事务所需数据，包括待处理的表名(tableName)、数据主键(primaryKey)、数据内容(data)、操作方式(operType)，operType可取值C(新增数据)、U(修改数据)、D(删除数据)。

为支持事务的多线程使用，提高运行效率，本发明引入一个线程池来管理事务管理器，线程池的本质是一个容器，用于保存程序执行的上下文，定义为Context。例如：node1(transactionId)—>nodel2(transactionId)，即第一节点将transactionId传递给第二节点，两个节点共同处理同一条事务记录，提高运行效率。同时用堆栈的方法来存储事务管理器，即put、get、pop、release方法。

MongoDB事务框架的建立过程包括以下步骤，MongoDB事务框架建立过程如图5所示：

步骤1：初始化事务，在MongoDB数据库中生成一条事务记录，初始化事务的状态(dealType)为init，并通过序列化生成一个唯一的12字节的transactionId；

步骤2：将关键数据存入事务表processDataDtoList(如图6)中，在操作数据表记录后添加transactionId，即对该事务进行加锁，其他数据操作必须等待该事务完成解锁后，才能执行，同时把transactionId传给其他节点，进行多线程并行处理；

步骤3：计算上一次状态改变时间(stateDate)和事务创建时间(CreatedData)的时间差，若超过100ms，即判断事务失败(部分数据已经成功处理并解锁，但没有完成所有处理)，则执行步骤5；若事务执行成功，即在100ms内事务状态更改为commit态，则执行步骤6；

步骤4：将IsRollBBack置为1，对事务进行回滚，根据processDataDtoList中的数据，找到待操作的所有数据记录，回滚操作即重新对已处理的数据记录重新加锁；

步骤5：若事务不断回滚超过5次，即可认为该事务不可完成，将事务状态置为cancel态，还原数据表内容，对数据记录进行解锁，删除该条事务记录，同时在客户端进行提醒；

步骤6：若事务完成，即可将事务状态置为complete状态，并销毁该条事务记录，加快事务查询速率；

步骤7：结束。

在应用服务器中，根据功能点的要求主要包括Tomcat服务器。其中Tomcat服务器是整个web服务的容器，用于供外部的应用访问服务器的资源。其中包括4个主要的服务，分别为用户服务、文件存储服务、社会化服务、文件地址序列化服务。

在文件存储服务，是本设计的重点，需要实现海量级的文件存储与毫秒级的文件查询，流畅的文件操作时本设计的特点之一。

采用二级缓存的方式实现毫秒级的文件查询。基本构架如图7所示，在本系统中，参照缓存机制的原理，将HDFS文件系统与WEB容器保存文件作为一个二级缓存。保存在WEB服务器上面的文件可能会因为一些特殊情况而被销毁，但是在HDFS上的文件不会被销毁。客户端请求一个相应的文件地址后，服务器端回调用相应的服务，首先到WEB服务器的文件系统上查看该文件是否存在。如果文件存在，将会写回这个文件到客户端。如果文件不存在，将会到MongoDB服务器，根据传入进来的WEB服务器的文件地址而查询到HDFS上(WEB服务器文件地址作为主键，查询效率很高)的文件，从HDFS上加载到WEB服务器。这个过程的加载时间基本可以忽略不计(因为文件可能在同一个ACK上)。加载完成之后，同样的会将这个文件写到客户端。即所有文件会保存到web服务器上，但是同时文件也会保存到HDFS上。针对于web服务器的文件，由于可能丢失，此时可以根据文件的保存地址到HDFS上重新加载相应的文件到web服务器上，通过这样的方式保证了文件的安全性以及毫秒级的查询速度。

流畅的文件操作依靠节点搜索算法实现：文件的操作主要包括新建目录、上传文件、下载文件、删除文件等基本操作。因为本发明采用Json的树形格式去表示文件目录与文件的关系，所以采用深度优先遍历去查询指定的树形节点。在查找到相应的树形节点后，只需要对这个节点进行相应的操作即可。

基本操作过程为：

1、查询得到该用户的原有文件的树形结构。

2、入参，根据操作类型的不同，选择输入文件的源序列码和目标序列码。

3、DFS找到目标节点。

4、对目标节点进行相应操作。

根据操作的不同，将大致的操作类型分为：append、remove、search、rename。利用四个基本的操作即可组装成所有的文件操作需要。例如，想要新增一个文件夹，先使用DFS(类图如图8)查找到相应的节点之后，在该节点下append一个新的序列码，即可完成在文件夹下新增一个子文件夹的功能。再例如，如果想查找到某个文件夹下的所有的文件及其目录信息，则使用search操作，找到指定的文件夹的序列码，返回该节点下的所有的privateFileDtoList的数据结构即可。

针对不同的文件操作，实际操作的过程是需要通过组合来完成的。定义四个基本的操作方法，借助上述DFS的搜索算法，定义出四个基本的操作类型：append、remove、search、rename。在具体操作时，通过搜索可以得到一个查询到的节点的序列码、父节点的序列码，就可以对特定的序列码文件进行相应的操作。

监控与日志的服务器作为保证系统稳定性及可用性的支撑部分，需要建立在应用层的与其他部分平行的部分，但是这一部分与其他的应用服务器没有关联，也就是说能够独立的进行。日志部分采用SLF4J来进行处理，使用Flume进行分析；对于应用服务器的状态，使用Spring-Boot-actuator进行监听。

API Gateway API Hanlder：最上面一层的是开放出去的一些接口及请求的转发器。通过应用服务的构建，本发明已经具备了大量可以供外部使用的接口。需要通过接口层将服务发布到相应的http地址上。本发明采用spring4中的RestController来实现该层，并且通过自定义的Dispather来处理请求的转发，绑定相应的api地址到指定的http地址上，从而在web容器的运行下，使客户端能访问到相应的资源。

由上述的所有组件共同构成了服务器端的完整架构，支撑整个服务器端的执行。

本发明利用深拷贝实现客户端与服务器端的数据交换：通过客户端传递过来的HTTP请求无法根据需要封装成一个完整的对象传递到服务器端。所以，需要用传递过来的键值对类型数据进行封装，使之成为能在服务器端进行操作的实体类对象。但是从上述的情况来看，目前所处理的数据结构相对较多，如果对于每一个数据结构都特化的重写一个封装的方法，那么源码量会过于复杂，不便维护。本发明利用深拷贝的特点，通过反射技术将这些封装的过程抽象成一个通用的方法。

除了通过HTTP请求过来的数据，部分数据也需要进行相应的封装。因为在Java中，当使用另一个对象的数据时，如果不是逐一赋值，将无法得到一个新的对象实例，而是得到一个对象的引用。此时，也需要使用到深拷贝技术。因此，综合上述两点，需要设计一个通用的思路，去处理HTTP与对象之间的深拷贝的工具类。

编码过程中需要使用到Java的反射机制(为一个包)，对于Http请求中的参数，其中包含了一个键值对的Map集合，Map集合中有多个通过Http请求需要的参数，其中包含了封装目标的参数。因此，需要从封装目标的参数中得到相应的数据，然后依次遍历所有的参数，再去Map集合中寻找是否存在相应的字段，如果存在，则通过反射机制对相应的字段进行赋值。程序流程图如图9所示。

在处理两个对象的深拷贝时，需要先对相应的字段进行过滤，即方法中包含get为前缀的字段。则需要设计一个字段的过滤器，该过滤器主要用于过滤方法中不包含get为前缀的方法，剩下的方法即为该方法的字段。

过滤完成后，返回的是一个包含所有get方法的Map集合。下一个阶段对于Http的深拷贝与对象之间的深拷贝有差别，但是处理的过程基本类似，不同点在于入参不同。同一个类型的对象字段一定相同，所以只需要对它们共同的类进行过滤，得到的结果相同。然后使用reflect对它们的所有的字段进行赋值，即可完成这一次的深拷贝。程序的流程仅在处理赋值之前加上过滤操作即可。

整个设计实现后，本发明设计了实体断言测试框架进行系统测试。在进行单元测试时，很难准确判断存储到数据库的数据是否和构造阶段构造出来的数据相同，使用junit进行测试只能对于某一种基本数据类型进行测试，但是无法知道实体对象中每一个字段的数据与数据库中的数据是否相等。此时需要自定义一个测试框架，来对特定的程序对象与数据库对象进行比较。

编写过程同样需要用到深拷贝技术的实现思路。入参为两个实体，这两个实体要求是同一个类型，否则这两个对象的比较没有意义。返回值是一个AssertBeanParam，表示这两个对象数据相同的个数、不同的个数、相同的数据字段及具体值、不同的数据字段及具体值。实现过程不应该借助于其他的框架，采用标准JDK进行编写。服务器端实体断言测试实现的过程为(如图10所示)：

1、实例化一个AssertBeanParam为后续数据返回进行准备；

2、判断输入的两个实体参数的类型是否相同；

3、过滤，使用filterGetMethod，得到所有的字段；

4、通过反射处理，得到这两个对象的具体数据；

5、判断每一个字段的数据是否相等，若相等，则实体内的Map集合中，正确标号successCount加1，并将相等数据存入successMap数据集中；若不相等，则错误标号errorCount加1，并将不相等数据存入errorMap数据集中；对于数值，将数值的返回格式统一定义为：dstValue：dstValue,srcValue：srcValue，数值是一个字符串类型；

6、返回AssertBeanParam。

以上描述了本发明的具体模块设计及优点。本行业的技术人员应该了解，本发明不受上述实例的限制，上述实例和说明书中描述的只是说明本发明的思想，在不脱离本发明技术方案精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (8)

1.一种基于局域网的HDFS分布式文件共享方法，其特征在于：包括以下步骤：

1)将HDFS部署在局域网上，使用一台服务器作为主节点，即应用的监控服务器；使用其他N个服务器作为从节点，即应用的存储服务器；

2)在服务器端，主节点将文件分成固定大小的多个块并存储于不同的从节点存储服务器上，且每个数据块均有2-3个备份。

2.根据权利要求1所述的基于局域网的HDFS分布式文件共享方法，其特征在于：将HDFS文件系统与WEB容器保存文件作为一个二级缓存，所有文件暂存到web服务器上，同时文件保存到HDFS上，读取文件信息时，直接从web服务器上进行查找；若文件丢失，从HDFS上加载文件到web服务器上，以保证正常业务的进行。

3.根据权利要求1所述的基于局域网的HDFS分布式文件共享方法，其特征在于，包括用户功能服务和文件功能服务：

所述用户功能服务用于用户注册、登陆、好友管理；

所述文件功能服务用于文件上传、文件分享、文件管理。

4.根据权利要求3所述的基于局域网的HDFS分布式文件共享方法，其特征在于：所述文件分享，用户在客户端发布一个分享文件的消息到服务器端，然后存入MongoDB数据库，并允许用户指定分享文件集的封面、描述以及文件列表。

5.根据权利要求3所述的基于局域网的HDFS分布式文件共享方法，其特征在于：所述文件管理，包括新建目录、上传文件、下载文件、删除文件，文件目录与文件的关系由Json的树形格式表示，采用深度优先遍历算法查询指定的树形节点，查找到相应的树形节点后，对该节点进行相应的操作，实现对文件的操作，对文件的操作过程为：

(1)查询得到用户的原有文件的树形结构；

(2)输入参数，根据操作类型的不同，选择输入文件的源序列码和目标序列码；

(3)采用深度优先搜索方法找到目标节点；

(4)对目标节点进行相应操作。

6.根据权利要求1所述的基于局域网的HDFS分布式文件共享方法，其特征在于：用户数据及好友关系数据存于Mysql数据库，文件地址序列化服务产生的文件地址索引、共有文件索引、文件用户关系、用户文件关系、分享文件信息存放于MongoDB数据库；同时利用HDFS数据库进行文件数据的存储。

7.根据权利要求6所述的基于局域网的HDFS分布式文件共享方法，其特征在于：在MongoDB数据库中建立一张事务表，事务表存放以下内容：

(1)_id：事务记录唯一的id号，又称transactionId；

(2)dealType：事务状态，取值为0-4，分别表示为：初始态init、运行态process、完成态commit、终止态complete、取消态cancel；

(3)IsRollBBack：事务回滚标识符，取值0或1，0表示事务不需回滚，1表示事务需回滚；

(4)CreatedData：事务创建时间；

(5)stateDate：上一次状态改变时间；

(6)CriticalDataDtoList：用于支持多节点事务处理，其中stage表示节点，processDataDtoList表示事务所需数据。

8.根据权利要求7所述的基于局域网的HDFS分布式文件共享方法，其特征在于：建立MongoDB数据库事务框架，MongoDB数据库事务框架建立过程包括以下步骤：

步骤1：初始化事务，在MongoDB数据库中生成一条事务记录，初始化事务的状态为init，并通过序列化生成一个唯一的12字节的节点transactionId；

步骤2：将关键数据存入MongoDB数据库事务表的processDataDtoList中，在操作数据表记录后添加节点transactionId，即对该事务进行加锁，其他数据操作等待该事务完成解锁后才能执行，同时把节点transactionId传给其他节点，进行多线程并行处理；

步骤3：计算上一次状态改变时间和事务创建时间的时间差，若超过设定值，即判断事务失败，则执行步骤5，若事务执行成功，即在设定值内事务状态更改为commit态，则执行步骤6；

步骤4：将事务回滚标识符IsRollBBack置为1，对事务进行回滚，根据事务表processDataDtoList中的数据，找到待操作的所有数据记录，回滚操作即重新对已处理的数据记录重新加锁；

步骤5：若事务不断回滚超过设定次数，即认为该事务不可完成，将事务状态置为cancel态，还原数据表内容，对数据记录进行解锁，删除该条事务记录，同时在客户端进行提醒；

步骤6：若事务完成，将事务状态置为complete状态，并销毁该条事务记录，加快事务查询速率；

步骤7：结束。