CN114579604B

CN114579604B - 一种应用层的数据库事务实现方法和系统

Info

Publication number: CN114579604B
Application number: CN202210251737.5A
Authority: CN
Inventors: 杨万勇; 杨耀庭; 华健; 张兵
Original assignee: Beijing Mengcheng Technology Co ltd
Current assignee: Beijing Mengcheng Technology Co ltd
Priority date: 2022-03-15
Filing date: 2022-03-15
Publication date: 2022-09-20
Anticipated expiration: 2042-03-15
Also published as: CN114579604A

Abstract

本发明提出一种应用层的数据库事务实现方法和系统。其中，方法包括：在数据库基础上在应用层做的一层中间件实现的应用层的数据库事务，使用上开启事务的时候跟传统数据库完全一样上一样，使用者完全不用关心在哪一层实现的事务功能，对他们来说使用事务就是几条简单的sql语句，只要熟悉其它关系数据库的，在使用当前数据库事务时完全没有障碍。本发明提出的方案，在使用该应用层数据框架后，开发人员把原本用于处理数据补偿的那部分时间节省下来，把时间和精力投入到业务功能开发中去，极大的提升了产品开发效率，同时也降低了对开发人员水平的要求。开发同等复杂度的模块，相比之前用时大约缩短了30％的时间，大大节省了开发成本。

Description

一种应用层的数据库事务实现方法和系统

技术领域

本发明属于数据库事务领域，尤其涉及一种应用层的数据库事务实现方法和系统。

背景技术

通常意义上的数据库事务是指包含了一个序列的对数据库的读/写操作。包含有以下两个目的：

为数据库操作序列提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持一致性的方法。

当多个应用程序在并发访问数据库时，可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。

当事务被提交给了数据库管理系统(DBMS)，则DBMS需要确保该事务中的所有操作都成功完成且其结果被永久保存在数据库中，如果事务中有的操作没有成功完成，则事务中的所有操作都需要回滚，回到事务执行前的状态；同时，该事务对数据库或者其他事务的执行无影响，所有的事务都好像在独立的运行。

完备的数据库事务应具有ACID4个特性：

A：Atomic，原子性，将所有SQL作为原子工作单元执行，要么全部执行，要么全部不执行；

C：Consistent，一致性，事务完成后，所有数据的状态都是一致的，即 A账户只要减去了100，B账户则必定加上了100；

I：Isolation，隔离性，如果有多个事务并发执行，每个事务作出的修改必须与其他事务隔离；

D：Duration，持久性，即事务完成后，对数据库数据的修改被持久化存储。

对于单条SQL语句，数据库系统自动将其作为一个事务执行，这种事务被称为隐式事务。

要手动把多条SQL语句作为一个事务执行，使用BEGIN开启一个事务，使用COMMIT提交一个事务，这种事务被称为显式事务

对于两个并发执行的事务，如果涉及到操作同一条记录的时候，可能会发生问题。因为并发操作会带来数据的不一致性，包括脏读、不可重复读、幻读等。数据库系统提供了隔离级别来让我们有针对性地选择事务的隔离级别，避免数据不一致的问题。

SQL标准定义了4种隔离级别，分别对应可能出现的数据不一致的情况，如下表1：

表1

Isolation Level	脏读	不可重复读	幻读
				Read Uncommitted	Yes	Yes	Yes
Read Committed	-	Yes	Yes
				Repeatable Read	-	-	Yes
Serializable	-	-	-

在程序中一个完整的事务包含了开启事务，执行数据库操作，提交事务/回滚事务这几个步骤。其中提交事务和回滚事务在一次事务过程中两者只能出现一次，要么提交成功，要么回滚整个操作。

Impala+Kudu数据库

Impala是用于处理存储在Hadoop集群中的大量数据的MPP(大规模并行处理)SQL查询引擎。它是一个用C++和Java编写的开源软件。在整个Hadoop生态系统中是唯数不多的能提供类似RDBMS的使用体验的，高性能，低延迟的查询引擎。Impala本身不提供存储引擎，目前支持的存储引擎有hive和kudu。

Kudu是围绕Hadoop生态圈建立存储引擎，Kudu拥有和Hadoop生态圈共同的设计理念，它运行在普通的服务器上、可分布式规模化部署、并且满足工业界的高可用要求。其设计理念为fast analytics on fast data。Kudu 的大部分场景和Hbase类似，其设计降低了随机读写性能，提高了扫描性能，在大部分场景下，Kudu在拥有接近Hbase的随机读写性能的同时，还有远超Hbase的扫描性能。kudu与Impala深度集成，相比其它hadoop生态数据库的传统架构，Kudu+Impala在绝大多数场景下拥有更好的性能。

以下为了方便描述，除了特别说明的地方以外，提到Impala时都指代的是Impala+Kudu的数据库

数据库事务可以在数据库内部实现，也可以在应用层实现，例如分布式事务。

由于定位和目标设计上的一些原因，impala并没有实现类似于传统统数据库中的多行事务。

现有技术

Impala作为查询引擎，kudu作为存储引擎的数据库里，impala只提供了单行事务，即只能保证在对一条数据作增删改的时候，能保证ACID 4个特性。如果同一条sql操作了多条数据，或者几条sql要在一个业务过程中执行，这时就无法保证数据一定全部写成功。

Impala数据虽然在大批量数据处理中有明显的性能优势，但因为上述原因限制了其使用场景，在国内各家公司里中仅用于比较简单的业务，或者是一些边缘业务上，更多用于处理一些离线业务分析上。

目前市面上能找到使用impala的方式全都是只实现了普通客户端的功能，仅仅是在应用层实现了连接层身份验证和数据通讯协议。也并没有考虑在应用层实现类似于数据库事务的功能。就连cloudera自身提供的JDBC 客户端对事务这块，也是简单的抛出异常，告诉调用者不支持。可以说在 impala数据库上层完全基于sql的事务实现基本上没有。

与本发明有关联的是apache的flink项目，其核心是用Java和Scala编写的分布式流数据流引擎。Flink以数据并行和管道方式执行任意流数据程序，Flink的流水线运行时系统可以执行批处理和流处理程序。

flink提供的2PC sink需要sink系统提供事务的支持或者可以模拟出事务特性的模块。对于每一个检查点，sink开始一个事务，然后将所有的接收到的数据都添加到事务中，并将这些数据写入到sink系统，但并没有提交(commit)它们。当事务接收到检查点完成的通知时，事务将被commit，数据将被真正的写入sink系统。这项机制主要依赖于一次sink可以在检查点完成之前开始事务，并在应用程序从一次故障中恢复以后再commit的能力。2PC协议依赖于Flink的检查点机制。

该功能类似于事务过程中开启事务，执行sql，提交/回滚的过程。

现有技术的缺陷：

由于flink是一个流式处理框架，需要开发人员对该框架特别熟悉，对使用者来说不是面向sql开发，而是面向流处理引擎开发，入门门槛较高，普通开发者并不能很好的握，开发调试也很困难。

在运行过程中flink把事务过程中用到的所有数据都保存在flink流的内存中，对于一次插入或修改大量数据的业务场景来说，这种方式非常耗费内存资源。并且在提交事务时数据还要从应用服务器传递到数据库服务器，在数据量大的情况下无法在较短时间内完成。

另外在真正提交到数据库之前，对于数据格式，类型，非空等检查都无法一一校验，无法做到提交过程不会因为这些原因导致失败。

还有在删除数据时，由于缺少外键约束，同一条记录不知道会哪些表引用，需要开发人员写代码无法隐式的判断出该条数据是否可以真的，能不能删除。即使开发人员在某个时刻把引用表列全了，写代码全都检查了一遍，也不能保证随着新业务增加和需求的变化，有新的表引用该记录，导致删除时漏检查了，出现数据不一致问题。

发明内容

为解决上述技术问题，本发明提出一种应用层的数据库事务实现方法和系统的技术方案，以解决上述技术问题。

本发明第一方面公开了一种应用层的数据库事务实现方法，所述数据库为不支持多行事务的关系型数据库，所述方法包括：

步骤S1、在应用层与原数据库连接之间实现一层代理，即构建一层代理层，在所述代理层里处理事务相关的处理逻辑；

步骤S2、当开启事务时，所述代理层生成一个与所述事务相关的标识，记录事务进行的信息；

步骤S3、当所述事务开启的过程中，所述代理层通过在原数据库中创建一个特殊的数据存储区，命名为事务库，每生成一张业务表的时候会在所述数据存储区中同样创建一张相同的业务表，命名为事务库业务表，达到对事务外的连接客户端查询隔离；

步骤S4、所述事务开始提交后，所述代理层会先把所述事务的状态标记为COMMITING，表示所述事务正在提交过程中；如果提交成功，接着把所述事务的状态标记为COMMITTED，表示提交完成，并且成功；如果提交失败，把事务状态标记的状态为COMMIT_ERROR此时会立即启动回滚动作，保证事务一致性/原子性。

根据本发明第一方面的方法，在所述步骤S2中，所述事务进行的信息包括：

事务进行的时间、修改了哪些业务表和事务的状态。

根据本发明第一方面的方法，在所述步骤S3中，所述当所述事务开启的过程中，所述代理层通过在原数据库中创建一个特殊的数据存储区，命名为事务库，每生成一张业务表的时候会在所述数据存储区中同样创建一张相同的业务表，命名为事务库业务表，达到对事务外的连接客户端查询隔离的具体方法包括：

给所述事务库业务表增加两个特殊的字段，第一字段和第二字段，新的表的主键被改写为所述第一字段和原业务表的主键拼在一起的联合主键；所述第一字段表示所属事务的标识；所述第二字段表示该记录经过一次或多次操作后，最终生效的操作；数据提交的时候经过所述代理层会把原来对原数据库的业务库的sql操作改成对事务库中相关表的操作。

根据本发明第一方面的方法，在所述步骤S3中，所述第二字段的值为一个枚举，选择项为upsert、insert、delete和update。

根据本发明第一方面的方法，在所述步骤S3中，所述把原来对原数据库的业务库的sql操作改成对事务库中相关表的操作的具体方法包括：

对原数据库的增加操作的改写是直接改写成插入到事务库；

对原数据库的删除操作改写时，为了保存删除前的状态，需要将数据从业务库中复制一份到所述事务库里；

对原数据库的修改的操作，需要从业务库中把要修改的记录提取出来，把需要修改的字段的值改掉，再写入所述事务库里，保存的记录里包含了两条数据，一条原始状态，一条是操作后的状态。

根据本发明第一方面的方法，在所述步骤S4中，所述如果提交失败，所述方法还包括：

检查当前提交过程实际修改了哪几张业务表，然后从事务库中提取缓存的原始数据写回去，直到恢复成最新状态为止。

根据本发明第一方面的方法，在所述步骤S4中，所述回滚动作具体包括：

所述应用层主动发起回滚操作时，所述代理层会先把事务的状态标记为ROLLBACK，同时把事务库中的数据清理掉；

所述保证事务一致性/原子性的方法还包括：

事务超时处理：当所述代理层检查到某个事务超时了，会把所述事务的状态标记为TIMEOUT，此时再执行与所述事务相关的操作都会获取到事务超时的异常信息。

本发明第二方面公开了一种应用层的数据库事务实现系统，所述系统包括：

第一处理模块，被配置为，在应用层与原数据库连接之间实现一层代理，即构建一层代理层，在所述代理层里处理事务相关的处理逻辑；

第二处理模块，被配置为，当开启事务时，所述代理层生成一个与所述事务相关的标识，记录事务进行的信息；

第三处理模块，被配置为，当所述事务开启的过程中，所述代理层通过在原数据库中创建一个特殊的数据存储区，命名为事务库，每生成一张业务表的时候会在所述数据存储区中同样创建一张相同的业务表，命名为事务库业务表，达到对事务外的连接客户端查询隔离；

第四处理模块，被配置为，所述事务开始提交后，所述代理层会先把所述事务的状态标记为COMMITING，表示所述事务正在提交过程中；如果提交成功，接着把所述事务的状态标记为COMMITTED，表示提交完成，并且成功；如果提交失败，把事务状态标记的状态为COMMIT_ERROR此时会立即启动回滚动作，保证事务一致性/原子性。

根据本发明第二方面的系统，第二处理模块，被配置为，所述事务进行的信息包括：事务进行的时间、修改了哪些业务表和事务的状态。

根据本发明第二方面的系统，第三处理模块，被配置为，给所述事务库业务表增加两个特殊的字段，第一字段和第二字段，新的表的主键被改写为所述第一字段和原业务表的主键拼在一起的联合主键；所述第一字段表示所属事务的标识；所述第二字段表示该记录经过一次或多次操作后，最终生效的操作；数据提交的时候经过所述代理层会把原来对原数据库的业务库的sql操作改成对事务库中相关表的操作。

根据本发明第二方面的系统，第三处理模块，被配置为，所述第二字段的值为一个枚举，选择项为upsert、insert、delete和update。

根据本发明第二方面的系统，第三处理模块，被配置为，对原数据库的增加操作的改写是直接改写成插入到事务库；对原数据库的删除操作改写时，为了保存删除前的状态，需要将数据从业务库中复制一份到所述事务库里；对原数据库的修改的操作，需要从业务库中把要修改的记录提取出来，把需要修改的字段的值改掉，再写入所述事务库里，保存的记录里包含了两条数据，一条原始状态，一条是操作后的状态。

根据本发明第二方面的系统，第四处理模块，被配置为，检查当前提交过程实际修改了哪几张业务表，然后从事务库中提取缓存的原始数据写回去，直到恢复成最新状态为止。

根据本发明第二方面的系统，第四处理模块，被配置为，所述应用层主动发起回滚操作时，所述代理层会先把事务的状态标记为ROLLBACK，同时把事务库中的数据清理掉；

所述保证事务一致性/原子性的方法还包括：

本发明第三方面公开了一种电子设备。电子设备包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时，实现本发明公开第一方面中任一项的一种应用层的数据库事务实现方法中的步骤。

本发明第四方面公开了一种计算机可读存储介质。计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时，实现本发明公开第一方面中任一项的一种应用层的数据库事务实现方法中的步骤。

本发明提出的方案，具有如下有益效果，在使用该应用层数据框架后，开发人员把原本用于处理数据补偿的那部分时间节省下来，把时间和精力投入到业务功能开发中去，极大的提升了产品开发效率，同时也降低了对开发人员水平的要求。大家不用再去关心数据被谁引用了，能不能删除，不用关心在执行数据操作时过程中失败了怎么处理等，上线上一段时间内统计，开发同等复杂度的模块，相比之前用时大约缩短了30％的时间，大大节省了开发成本，提升了交付速度。上线后已经在100多个微服务中稳定运行了超过300天时间；业务上以前很多不好实现的功能现在也可以做到，以前用mysql替代实现的那部分功能也都逐步转回到基于impala实现，再也不用定时同步数据，导致实时分析的结果全部转。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为根据本发明实施例的一种应用层的数据库事务实现方法的流程图；

图2为根据本发明实施例的应用层的数据库事务实现方法流程示意图；

图3为根据本发明实施例的一种应用层的数据库事务实现系统的结构图；

图4为根据本发明实施例的一种电子设备的结构图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例只是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

所述数据库为不支持多行事务的关系型数据库，本发明是在原有impala 数据库的基础上用nodejs实现的中间件，impala数据库即为不支持多行事务的关系型数据库。因为原数据库设计规模比较复杂，代码量非常庞大，涉及到impala查询引擎和kudu存储引擎两大块内容，直接去改里面的代码短时间内不容易实现，并且跟后续版本升级维护成本也很高，产品开发对数据库事务这块呼声又较高，最终决定的设计指导思想是采用最小的代价实现目标价值最大化。经过分析，最终决定在应用层与数据库连接之间实现一层代理，接管原本连接到impala的数据库连接，在这一层里处理事务相关的处理逻辑。

本发明第一方面公开了一种应用层的数据库事务实现方法。图1为根据本发明实施例的一种应用层的数据库事务实现方法的流程图，如图1和图2所示，所述数据库为不支持多行事务的关系型数据库，所述方法包括：

在步骤S2，当开启事务时，所述代理层生成一个与所述事务相关的标识，记录事务进行的信息。

在一些实施例中，在所述步骤S2中，所述事务进行的信息包括：事务进行的时间、修改了哪些业务表和事务的状态。

在步骤S3，当所述事务开启的过程中，所述代理层通过在原数据库中创建一个特殊的数据存储区，命名为事务库，每生成一张业务表的时候会在所述数据存储区中同样创建一张相同的业务表，命名为事务库业务表，达到对事务外的连接客户端查询隔离。

在一些实施例中，在所述步骤S3中，所述当所述事务开启的过程中，所述代理层通过在原数据库中创建一个特殊的数据存储区，命名为事务库，每生成一张业务表的时候会在所述数据存储区中同样创建一张相同的业务表，命名为事务库业务表，达到对事务外的连接客户端查询隔离的具体方法包括：

所述第二字段的值为一个枚举，选择项为upsert、insert、delete和 update。

所述把原来对原数据库的业务库的sql操作改成对事务库中相关表的操作的具体方法包括：

对原数据库的增加操作的改写是直接改写成插入到事务库；

具体地，采用的思想借用了大部分数据库事务在这个特性上的实现方式，即把修改的数据暂存到另外的地方，等提交时再一次写入。与背景技术提到的flink相比，当前实现的方式中，暂存的数据不是存储到中间件内部的内存里，而是预先在数据库中创建一个特殊的数据存储区，命名为事务库，每生成一张业务表的时候会在所述数据存储区中同样创建一张相同的业务表，命名为事务库业务表，给所述事务库业务表增加两个特殊的字段，__trans_id和__action，新的表的主键被改写为__trans_id和原业务表的主键拼在一起的联合主键；__trans_id表示所属事务的标识；__action表示该记录经过一次或多次操作后，最终生效的操作；数据提交的时候经过所述代理层会把原来对原数据库的业务库的sql操作改成对事务库中相关表的操作。所述第二字段的值为一个枚举，选择项为upsert、insert、delete 和update。

设置原则如下：

对同一条记录只进行一次操作，__action的值就等于该操作。

对同一条记录先执行insert，再对该记录执行update，则最终操用为 insert。

对同一条记录先执行update或insert再执行delete操作，则最终操作为delete。

对同一条记录先执行delete操作，再执行其它操作，最终状态仍然为 delete。

数据提交的时候经过代理层会把原来对业务库的sql改成对事务库中相关表的操作,同时补全上述两个特殊字段。因为在事务内所操作都是针对当事务库进行的，业务库没有任何修改，这样就达到了对事务外的连客户端查询隔离的目的。

1.事务中的查询语句

事务中的查询语句的改写分为两种情况：

a)在本次查询语句执行的时候，查询语句用到的表在当前事务过程中还没有被修改过

b)在本次查询语句执行的时候，查询语句用到的表在当前事务过程中存在至少一次插入，删除或更新这类修改数据的操作。

情况a)不需要改写，按sql原样执行

情况b)需要考虑已修改的数据对查询结果的影响

单一操作处理：

1)如果是之前存在插入操作，原查询语句改写时需要追加对数据存储区里的这部分数据的查询

2)如果是之前存在删除操作，需要在原来的查询语句增加一项过滤条件，把这部分删除的数据过滤掉

3)如果之前存在修改的操作，查询结果中如果数据记录在数据存储区里有，需要使用数据存储区里的被修改过的字段的值替换

如果存在以上两种或以上的组合，按以下复合处理方式处理：

A.在查询前存在插入操作和删除操作，直接把前面的1)和3)组合一下就可以

B.在查询前存在修改操作和删除操作，直接把前面的2)和3)组合一下就可以

C.在查询前存在插入和更新操作时，可以把之前修改操作和插入操作生在数据存储区生成的数据统一当作插入操作生成的数据处理，同时在原查询语句中增加一项过滤条件，排除数据存储区中已存在的更新操作生成的这部分数据

D.在查询前存在上述三种操作，把复合处理C和单一处理后和前面的3)组合一下就可以

2.事务中的修改

一般来说待执行的修改语句只会修改一张表中部分字段，在改写的时候会把对修改语句改写为保存到数据存储区的插入/替换语句，当前更新语句中修改的字段直保存到数据存储区中对应表的对应字段里，表中未修改的字段会原样复制到数据存储区中对应表中，保证同一条数据的完整性。

3.事务中的删除

执行删除操作语句只需要把需要删除的那条数据所有字段原样复制到数据存储区就可以了。

4.事务中的插入

修改插入的目标表，把数据原样插入到数据存储区中。

这里没有考虑采用其它存储方式来存这部分数据，原因之一是为了验证数据存储到数据库能够满足各项约束性检查，例如字段类型，长度，非空，是否有sql标识符错误等等。原因之二是数据存储在数据库内部，后续提交事务时，只是在数据库内部两张表之间复制数据，性能比从外部其它存储中读出来再转到数据库中的方式要快得多。从业务库中提取数据到事务库的过程中，实际上并没有真正把数据库通过sql读取来在内存中修改再写回去，这种方式效率太低了，实际采用的方式是编写一条sql从业务库复制(含修改)到事务库中。

在步骤S4，所述事务开始提交后，所述代理层会先把所述事务的状态标记为COMMITING，表示所述事务正在提交过程中；如果提交成功，接着把所述事务的状态标记为COMMITTED，表示提交完成，并且成功；如果提交失败，把事务状态标记的状态为COMMIT_ERROR此时会立即启动回滚动作，保证事务一致性/原子性。

在一些实施例中，在所述步骤S4中，所述如果提交失败，所述方法还包括：

所述回滚动作具体包括：

所述保证事务一致性/原子性的方法还包括：

具体地，所述事务开始提交后，所述代理层会先把所述事务的状态标记为COMMITING，表示所述事务正在提交过程中；如果提交成功，接着把所述事务的状态标记为COMMITTED，表示提交完成，并且成功；如果提交失败，把事务状态标记的状态为COMMIT_ERROR此时会立即启动回滚动作，检查当前提交过程实际修改了哪几张业务表，然后从事务库中提取缓存的原始数据写回去，直到恢复成最新状态为止。这个过程比较耗费时间，但是在生成环境中失败的事务毕竟只是少部分，还是可以接受的。

事务库里失效事务的清理是放在一个统一的服务里完成的，这样做的目的是为了减少每个事务单独清理数据时消耗的时间和资源，统一清理可以批量完成，对数据库来说性能会更好一些。该服务会定时监控过去一段时间内发生的事务，检查其状态，清理过时的数据。对于发生超时或失败的事务会发邮件通知。

在一些实施例中，还要考虑的是事务持久性，因为隔着impala查询引擎无法直接接触到持久化存储的kudu引擎，这部分在中间件里其实并没有多少事情可以做的。实际上是间接依赖了kudu层的预写入日志(wal)，一旦写入wal就一定保证成功。

综上，本发明提出的方案能够在使用该应用层数据框架后，开发人员把原本用于处理数据补偿的那部分时间节省下来，把时间和精力投入到业务功能开发中去，极大的提升了产品开发效率，同时也降低了对开发人员水平的要求。大家不用再去关心数据被谁引用了，能不能删除，不用关心在执行数据操作时过程中失败了怎么处理等，上线上一段时间内统计，开发同等复杂度的模块，相比之前用时大约缩短了30％的时间，大大节省了开发成本，提升了交付速度。上线后已经在100多个微服务中稳定运行了超过300天时间；业务上以前很多不好实现的功能现在也可以做到，以前用mysql替代实现的那部分功能也都逐步转回到基于impala实现，再也不用定时同步数据，导致实时分析的结果全部转。

本发明第二方面公开了一种应用层的数据库事务实现系统。图3为根据本发明实施例的一种应用层的数据库事务实现系统的结构图；如图3所示，所述系统100包括：

第一处理模块101，被配置为，在应用层与原数据库连接之间实现一层代理，即构建一层代理层，在所述代理层里处理事务相关的处理逻辑；

第二处理模块102，被配置为，当开启事务时，所述代理层生成一个与所述事务相关的标识，记录事务进行的信息；

第三处理模块103，被配置为，当所述事务开启的过程中，所述代理层通过在原数据库中创建一个特殊的数据存储区，命名为事务库，每生成一张业务表的时候会在所述数据存储区中同样创建一张相同的业务表，命名为事务库业务表，达到对事务外的连接客户端查询隔离；

第四处理模块104，被配置为，所述事务开始提交后，所述代理层会先把所述事务的状态标记为COMMITING，表示所述事务正在提交过程中；如果提交成功，接着把所述事务的状态标记为COMMITTED，表示提交完成，并且成功；如果提交失败，把事务状态标记的状态为COMMIT_ERROR 此时会立即启动回滚动作，保证事务一致性/原子性。

根据本发明第二方面的系统，所述第二处理模块102具体被配置为，所述事务进行的信息包括：事务进行的时间、修改了哪些业务表和事务的状态。

根据本发明第二方面的系统，所述第三处理模块103具体被配置为，所述当所述事务开启的过程中，所述代理层通过在原数据库中创建一个特殊的数据存储区，命名为事务库，每生成一张业务表的时候会在所述数据存储区中同样创建一张相同的业务表，命名为事务库业务表，达到对事务外的连接客户端查询隔离的具体方法包括：

对原数据库的增加操作的改写是直接改写成插入到事务库；

设置原则如下：

对同一条记录只进行一次操作，__action的值就等于该操作。

对同一条记录先执行update或insert再执行delete操作，则最终操作为 delete。

1.事务中的查询语句

事务中的查询语句的改写分为两种情况：

情况a)不需要改写，按sql原样执行

情况b)需要考虑已修改的数据对查询结果的影响

单一操作处理：

2.事务中的修改

3.事务中的删除

4.事务中的插入

修改插入的目标表，把数据原样插入到数据存储区中。

根据本发明第二方面的系统，所述第四处理模块104具体被配置为，所述如果提交失败，所述方法还包括：

所述回滚动作具体包括：

所述保证事务一致性/原子性的方法还包括：

图4为根据本发明实施例的一种电子设备的结构图，如图4所示，电子设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、近场通信(NFC)或其他技术实现。该电子设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该电子设备的输入装置可以是显示屏上覆盖的触摸层，也可以是电子设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图4中示出的结构，仅仅是与本公开的技术方案相关的部分的结构图，并不构成对本申请方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

本发明第四方面公开了一种计算机可读存储介质。计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时，实现本发明公开第一方面中任一项的一种应用层的数据库事务实现方法中的步骤中的步骤。

请注意，以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims

1.一种应用层的数据库事务实现方法，所述数据库为不支持多行事务的关系型数据库，其特征在于，所述方法包括：

具体方法包括：给所述事务库业务表增加两个特殊的字段，第一字段和第二字段，新的表的主键被改写为所述第一字段和原业务表的主键拼在一起的联合主键；所述第一字段表示所属事务的标识；所述第二字段表示该记录经过一次或多次操作后，最终生效的操作；数据提交的时候经过所述代理层会把原来对原数据库的业务库的sql操作改成对事务库中相关表的操作；

所述第二字段的值为一个枚举，选择项为upsert、insert、delete和update；

对原数据库的增加操作的改写是直接改写成插入到事务库；

对原数据库的修改的操作，需要从业务库中把要修改的记录提取出来，把需要修改的字段的值改掉，再写入所述事务库里，保存的记录里包含了两条数据，一条原始状态，一条是操作后的状态；

2.根据权利要求1所述的一种应用层的数据库事务实现方法，其特征在于，在所述步骤S2中，所述事务进行的信息包括：

事务进行的时间、修改了哪些业务表和事务的状态。

3.根据权利要求2所述的一种应用层的数据库事务实现方法，其特征在于，在所述步骤S4中，所述如果提交失败，所述方法还包括：

4.根据权利要求3所述的一种应用层的数据库事务实现方法，其特征在于，在所述步骤S4中，所述回滚动作具体包括：

所述保证事务一致性/原子性的方法还包括：

5.一种用于应用层的数据库事务实现系统，其特征在于，所述系统包括：

具体包括：给所述事务库业务表增加两个特殊的字段，第一字段和第二字段，新的表的主键被改写为所述第一字段和原业务表的主键拼在一起的联合主键；所述第一字段表示所属事务的标识；所述第二字段表示该记录经过一次或多次操作后，最终生效的操作；数据提交的时候经过所述代理层会把原来对原数据库的业务库的sql操作改成对事务库中相关表的操作；

所述把原来对原数据库的业务库的sql操作改成对事务库中相关表的操作，具体包括：

对原数据库的增加操作的改写是直接改写成插入到事务库；

6.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时，实现权利要求1至4中任一项所述的一种应用层的数据库事务实现方法中的步骤。

7.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，实现权利要求1至4中任一项所述的一种应用层的数据库事务实现方法中的步骤。