CN105512244A - 基于消息队列实现数据库事务处理的方法及装置 - Google Patents

Abstract

本发明提供一种基于消息队列实现数据库事务处理的方法及装置，能够使指定服务器异步消费和处理消息。该基于消息队列实现数据库事务处理的方法包括：接收数据库访问请求；根据所述数据库访问请求生成有序的消息队列；通过监控机构按顺序执行所述消息队列的处理，直到所述消息队列中所有消息被成功处理或者该消息队列中消息状态为“异常”的消息的重试次数超过预定阈值；当所述消息队列中的消息状态为“异常”的消息的重试次数超过预定阈值，则回退所述消息队列中已执行的消息。

Description

基于消息队列实现数据库事务处理的方法及装置

技术领域

本发明涉及计算机技术领域，特别地涉及一种基于消息队列实现数据库事务处理的方法及装置。

背景技术

在关系型数据库中，当由于数据量特别大，而达到单表或者单库的瓶颈的时候，大都需要对数据库进行分库分表操作。具体的实现方式就是部署多台数据库实例，同时一台数据库服务器中又对数据表进行水平拆分，从而形成多库多表存储多类型数据的结构。

一般对于已进行拆分的数据库或者数据表进行操作的原则是尽量避免同时操作几个数据库的数据。但是随着业务量的逐渐增多，很多情况下，一些业务是需要同时对多个数据库或者数据表进行操作的。例如：现在越来越多的人开始网上购物，电子商务运营的模式发展迅速，当出现一个客户订单中既包括食品，又包括衣服时，大多会因为食品和衣服的分类不同而要从多个数据库中操作数据。目前，对于多库多表中数据的操作，使用较多的方法是通过分布式事务来保证数据的准确性和一致性。

目前，分布式事务的处理比较常用的是两阶段提交协议(Two-phaseCommit,2pc)方法。即：由客户端提交请求到事务协调器(TC)，然后由事务协调器来确认各个事务执行者是否都执行完毕。待全部执行成功后，才能将整个事务提交完成。

但是，在使用过程中，发现现有的两阶段提交的方法具有以下的缺陷：

1、现有的方法需要事务协调器主动确认各个事务执行者的状态，因此涉及多次节点间的网络通信，通信时间长，系统性能消耗大；

2、现有的方法需要各个事务执行者同步执行分配的任务，因此不适合高并发的系统，且数据库实例越多，可用性能越差；

3、现有的方法对线上环境的容错性要求高，一旦一台机器出现问题，整个事务就会执行失败，无法部分重试。

综上，正是由于现有的处理分布式事务的方法存在很严重的性能问题，故而大部分高并发服务器都在尽量避免使用，尤其是那些对时间需求不是很高，但是对性能要求很高的系统。

发明内容

有鉴于此，本发明提供一种基于消息队列实现数据库事务处理的方法及装置，能够通过消息队列使指定服务器异步消费和处理消息，通过记录消息状态解决各事务执行者之间的频繁通信问题，且容错性能强，具有异常重试的功能。

为实现上述目的，根据本发明的一个方面，提供了一种基于消息队列实现数据库事务处理的方法。

一种基于消息队列实现数据库事务处理的方法，包括：接收数据库访问请求，所述数据库访问请求包括一个或多个数据库操作；根据所述数据库访问请求生成有序的消息队列，其中，所述消息队列中的消息对应数据库操作，每个消息包括消息状态和重试次数；通过监控机构按顺序执行所述消息队列的处理，直到所述消息队列中所有消息被成功处理或者该消息队列中消息状态为“异常”的消息的重试次数超过预定阈值；当所述消息队列中的消息状态为“异常”的消息的重试次数超过预定阈值，则回退所述消息队列中已执行的消息。

可选地，所述消息队列的处理包括：按顺序查找所述消息队列中消息状态为初始状态的第一个消息；调用相应的数据库服务来处理该消息对应的数据库操作；根据处理的结果更新该消息的消息状态和重试次数，其中，如果该消息对应的数据库操作成功完成，则修改该消息的消息状态，否则把该消息的消息状态设为“异常”并把该消息的重试次数递增1。

可选地，所述消息队列保存在消息状态表中，所述消息状态表以双向链表形式实现。

可选地，所述消息状态表还保存消息的回退消息。

可选地，回退所述消息队列中已执行的消息包括：从所述消息状态表中倒序读取所述消息队列中已执行消息对应的回退消息并根据所述回退消息执行回退，直至将所述消息队列回退至初始状态。

可选地，所述回退消息根据当前消息的数据库操作类型包括以下情况：若当前消息是做插入操作的，则根据当前消息待执行插入操作对象的标识符生成删除操作指令作为回退消息；若当前消息是做更新操作的，则根据当前消息需要更新的对象及更新前的初始值生成更新操作指令作为回退消息；若当前消息是做删除操作的，则根据当前消息待执行删除操作对象的标识符生成插入操作指令作为回退消息。

根据本发明的另一方面，提供了一种基于消息队列实现数据库事务处理的装置。

一种基于消息队列实现数据库事务处理的装置，包括：访问请求接收模块，用于接收数据库访问请求，所述数据库访问请求包括一个或多个数据库操作；消息队列生成模块，用于根据所述数据库访问请求生成有序的消息队列，其中，所述消息队列中的消息对应数据库操作，每个消息包括消息状态和重试次数；监控机构，用于按顺序执行所述消息队列的处理，直到所述消息队列中所有消息被成功处理或者该消息队列中消息状态为“异常”的消息的重试次数超过预定阈值；回退模块，用于当所述消息队列中的消息状态为“异常”的消息的重试次数超过预定阈值时回退所述消息队列中已执行的消息。

可选地，所述监控机构还用于：按顺序查找所述消息队列中消息状态为初始状态的第一个消息；调用相应的数据库服务来处理该消息对应的数据库操作；根据处理的结果更新该消息的消息状态和重试次数，其中，如果该消息对应的数据库操作成功完成，则修改该消息的消息状态，否则把该消息的消息状态设为“异常”并把该消息的重试次数递增1。

可选地，所述消息队列保存在消息状态表中，所述消息状态表以双向链表形式实现。

可选地，所述消息状态表还保存消息的回退消息。

可选地，所述回退模块还用于：从所述消息状态表中倒序读取所述消息队列中已执行消息对应的回退消息并根据所述回退消息执行回退，直至将所述消息队列回退至初始状态。

可选地，所述回退消息根据当前消息的数据库操作类型包括以下情况：若当前消息是做插入操作的，则根据当前消息待执行插入操作对象的标识符生成删除操作指令作为回退消息；若当前消息是做更新操作的，则根据当前消息需要更新的对象及更新前的初始值生成更新操作指令作为回退消息；若当前消息是做删除操作的，则根据当前消息待执行删除操作对象的标识符生成插入操作指令作为回退消息。

根据本发明的技术方案，将接收到的数据库访问请求生成消息队列，并将消息数据写在zookeeper服务器的节点上，然后通过zookeeper的监听回调机制来通知注册在各节点上的业务服务器异步消费、处理消息，从而实现数据库分布式事务的处理。通过使用消息队列来处理数据库事务，可以对消息进行异步处理，当一条消息出现重试预定次数仍未能处理的异常时，将会执行消息回退直至初始状态，相应消息队列中未处理的消息便不再执行，从而节省了系统资源；且通过消息状态对消息的处理过程进行管理避免了上下级系统间的频繁通信，从而极大地提高了系统的性能。同时本发明的技术方案还具有较强的容错性，当一台业务服务器出现故障时，会有其他的业务服务器来接手处理未完成的任务，且可以部分重试，从而节约了系统资源，并且保证了数据处理的准确性。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的基于消息队列实现数据库事务处理的方法的主要步骤示意图；

图2是根据本发明实施例的基于消息队列实现数据库事务处理的装置的主要模块示意图；

图3是根据本发明实施例的实现数据库事务处理的系统的架构图；

图4是根据本发明实施例的分布式事务实现流程图；

图5是根据本发明实施例的分布式事务自动回退功能实现流程图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的基于消息队列实现数据库事务处理的方法的主要步骤示意图。如图1所示，本发明的基于消息队列实现数据库事务处理的方法主要包括如下的步骤S11至步骤S14。

步骤S11：接收数据库访问请求，所述数据库访问请求包括一个或多个数据库操作；

步骤S12：根据所述数据库访问请求生成有序的消息队列，其中，所述消息队列中的消息对应数据库操作，每个消息包括消息状态和重试次数；

步骤S13：通过监控机构按顺序执行所述消息队列的处理，直到所述消息队列中所有消息被成功处理或者该消息队列中消息状态为“异常”的消息的重试次数超过预定阈值；

步骤S14：当所述消息队列中的消息状态为“异常”的消息的重试次数超过预定阈值，则回退所述消息队列中已执行的消息。

根据本发明的技术方案，所述消息队列的处理包括：按顺序查找所述消息队列中消息状态为初始状态的第一个消息；调用相应的数据库服务来处理该消息对应的数据库操作；根据处理的结果更新该消息的消息状态和重试次数，其中，如果该消息对应的数据库操作成功完成，则修改该消息的消息状态，否则把该消息的消息状态设为“异常”并把该消息的重试次数递增1。

其中，所述消息队列保存在消息状态表中，所述消息状态表以双向链表形式实现。并且，所述消息状态表还保存消息的回退消息。

如上所述的步骤S14中回退所述消息队列中已执行的消息在具体操作时，可按照以下方法来执行：从所述消息状态表中倒序读取所述消息队列中已执行消息对应的回退消息并根据所述回退消息执行回退，直至将所述消息队列回退至初始状态。

其中，回退消息根据当前消息的数据库操作类型包括以下情况：

若当前消息是做插入操作的，则根据当前消息待执行插入操作对象的标识符生成删除操作指令作为回退消息；

若当前消息是做更新操作的，则根据当前消息需要更新的对象及更新前的初始值生成更新操作指令作为回退消息；

若当前消息是做删除操作的，则根据当前消息待执行删除操作对象的标识符生成插入操作指令作为回退消息。

图2是根据本发明实施例的基于消息队列实现数据库事务处理的装置的主要模块示意图。如图2所述，本发明的基于消息队列实现数据库事务处理的装置20主要包括访问请求接收模块21、消息队列生成模块22、监控机构23和回退模块24。

访问请求接收模块21用于接收数据库访问请求，所述数据库访问请求包括一个或多个数据库操作。

消息队列生成模块22用于根据所述数据库访问请求生成有序的消息队列，其中，所述消息队列中的消息对应数据库操作，每个消息包括消息状态和重试次数。

监控机构23用于按顺序执行所述消息队列的处理，直到所述消息队列中所有消息被成功处理或者该消息队列中消息状态为“异常”的消息的重试次数超过预定阈值。

回退模块24用于当所述消息队列中的消息状态为“异常”的消息的重试次数超过预定阈值时回退所述消息队列中已执行的消息。

所述监控机构还可以用于按顺序查找所述消息队列中消息状态为初始状态的第一个消息；调用相应的数据库服务来处理该消息对应的数据库操作；以及根据处理的结果更新该消息的消息状态和重试次数，其中，如果该消息对应的数据库操作成功完成，则修改该消息的消息状态，否则把该消息的消息状态设为“异常”并把该消息的重试次数递增1。

根据本发明的技术方案，所述消息队列保存在消息状态表中，所述消息状态表以双向链表形式实现。并且，所述消息状态表还保存消息的回退消息。

回退模块24还可以用于从所述消息状态表中倒序读取所述消息队列中已执行消息对应的回退消息并根据所述回退消息执行回退，直至将所述消息队列回退至初始状态。

其中，回退消息根据当前消息的数据库操作类型包括以下情况：

若当前消息是做插入操作的，则根据当前消息待执行插入操作对象的标识符生成删除操作指令作为回退消息；

若当前消息是做更新操作的，则根据当前消息需要更新的对象及更新前的初始值生成更新操作指令作为回退消息；

若当前消息是做删除操作的，则根据当前消息待执行删除操作对象的标识符生成插入操作指令作为回退消息。

根据本发明的实施例，通过向zookeeper服务器的节点上写数据来实现分布式消息的生成，通过zookeeper的监听回调机制来通知注册在各节点上的业务服务器异步消费、处理消息，从而实现数据库分布式事务的处理。

图3是根据本发明实施例的实现数据库事务处理的系统的架构图。如图3所示，本发明将实现数据库分布式事务的装置封装成一个组件，与业务系统耦合部署于业务服务器中，可以基于软件项目管理工具maven来实现，且可支持mysql、sqlserver等数据库。该组件的分布式事务实现对上层的业务系统是透明的，业务系统无需关注其内部实现过程，因而具有高可复用性。业务系统通过调用本发明的实现数据库分布式事务的装置来完成同时对多个数据库进行操作。业务系统在对本发明的实现数据库分布式事务的装置进行调用时，仅需将要处理的消息的结构化查询语言SQL语句(包含该SQL语句的标识ID及需要处理的数据库标识ID)传入即可，调用简单、方便。以下为了表述简便，将业务系统和本发明的实现数据库分布式事务的装置作为一个整体，以业务系统代称。

在本发明的实施例中，Zookeeper服务器可以理解为消息的代理中心broker。业务系统将消息直接写到该业务服务器在Zookeeper服务器上注册的node节点上，然后zookeeper服务器通过在其对应节点或者上级节点监听的watcher，来回调对应的服务器消费和解析消息。所有发送或者消费的消息，在整个系统中，被定义为事务凭证。每个事务凭证都有一个唯一编码(transId)，也就是说，每条消息都有一个唯一编码。此处，唯一编码一般是采用增量方式生成的。

图3中所示的DB-1、DB-2、DB-n等表示的是需要操作的数据库。消息状态数据库中保存有消息状态表，用来记录每条消息的状态，可以保证整个系统的高度可靠性，同时可以避免消息的重发，起到判定重复的功能。另外，由于消息量比较大，为了系统的性能，对消息状态也进行了分库分表的操作。根据每条消息需要操作的数据库对消息状态进行分类，可设置与数据库相对应的消息状态数据库，以保证每一类消息状态存储在一个消息状态数据库中。同时，在进行消息状态的读写操作时可根据消息的唯一编码来进行，从而可利用数据库的横向扩容来保证系统的性能。

下面将结合图3中的数据流向来介绍本发明的实施过程。

位于业务服务器中的业务系统接收用户发送的业务请求，此处的业务请求可看作是数据库访问请求，可以包括一个或多个数据库操作。可通过数据库查询(如SQL语句形式的查询)处理技术，产生有序的数据库操作序列。

在业务系统接收到用户发来的业务请求后，首先根据该数据库访问请求包含的数据库操作生成由一个或多个消息构成的消息队列，其中，消息队列中的消息对应数据库操作，例如，每个消息可以对应一个数据库操作，且消息队列中消息的顺序与数据库操作序列的顺序对应一致，从而形成有序的消息队列。另外，每条消息都分配有唯一性编码，例如可根据给定数值增量式生成每个消息的唯一性编码。每个消息还包括消息状态和重试次数两个参数，且消息状态初始设为“未完成”，重试次数初始设为0。

例如，假设业务系统是电商业务系统，用户是网购用户，业务请求是订单。用户通过网络向电商业务系统提交订单。业务系统在接收到用户提交的订单后，首先根据订单中包含的数据库操作SQL语句，获取该订单中包括的订购的商品名称及对应的订货数量。设定订单中每个商品及对应的订货数由一条SQL语句来表示，即可以对应产生一条消息，并为该消息分配唯一性编码，例如可根据给定数值增量式生成每个消息的唯一性编码。

这样，根据订单中的所有商品及对应的订货数生成一系列消息，以构成该订单对应的消息队列。之后，异步地对消息队列中的消息进行处理，并确定消息的状态和重试次数。消息的状态表示该消息对应的数据库操作是否已被成功处理、是否异常等。

消息及其当前状态和重试次数都被保存在消息状态表中，消息状态表位于相应的消息状态数据库中。根据业务请求生成的消息队列以双向链表的形式保存在消息状态数据库中，也就是说，消息队列中的每一条消息有一个指针指向其后一条消息，同时每一条消息也有一个指针指向其前一条消息。

根据本发明，在初始处理消息队列时，业务系统将该消息队列中的第一条状态为“未完成”的消息写到相应的zookeeper节点上。

理想情况是把消息写到接收业务请求的业务服务器对应的节点上，这样可以实现消息的生产者和消费者在同一台机器上，方便日志的定位和预防一些可能出现的权限问题。

当然，也可以把消息写到其他业务服务器对应的节点上，可根据zookeeper的均衡负载功能进行调节。

zookeeper服务器通过在各业务服务器对应节点或者上级节点监听的回调方法watcher，来回调对应的服务器来消费和处理消息。

各个业务服务器一启动就会对zookeeper服务器上该业务服务器对应的节点进行监控。当该节点的数据发生变化的时候，每个机器都会收到通知，并且在该业务服务器接收到zookeeper服务器的回调请求后，会实现回调方法watcher，从zookeeper服务器的节点上取下该消息的数据并进行处理。回调方法watcher会根据消息的SQL语句对数据库中的数据进行操作，并在操作结束后修改对应消息状态数据库中消息的状态。

由于业务系统是将消息队列以双向链表的形式保存在各个消息状态数据库中，也就是说前一条消息有一个指针指向后一条消息，同时后一条消息也有一个指针指向前一条消息，那么当一条消息执行完毕后，zookeeper就会自动生成下一条消息，直至全部处理完成。

在消息执行过程中，会因为各种异常情况出现消息执行失败的情况，这些消息被统称为异常消息，相应地这些消息的状态我们可设定为“异常”。为了更好地监控消息的执行情况，业务系统中设置了一个定时任务，用来专门监控消息状态数据库中的消息状态表，并查找与当前业务服务器相关的异常消息，然后进行重试，当重试次数达到设定的阈值后，意味着该消息存在系统无法处理的问题。此时，将根据双向链表结构的特点执行自动回退到初始状态，并且发出警报以提示人工进行处理，并写入错误日志。最后，将这条消息置为不可用状态，等待查找原因。

每个业务服务器启动后，业务系统中设置的定时任务会首先在消息状态表中查找是否有突然中断的、未处理完成的消息，或者异常消息。然后调用zookeeper服务器的setData功能函数来重新对积压或者中断的消息进行处理。

图4是根据本发明实施例的分布式事务实现流程图。如图4所示，假设一个消息队列中包含两条消息，需要对两个数据库中的数据进行操作。业务系统从zookeeper服务器的节点读取第一条消息后，开始处理第一条消息，修改相应数据库中的数据，如果修改失败，则说明发生了异常，需要执行自动回退流程，将于后续结合图5进行介绍。如果数据修改成功，则通知业务系统数据处理完成。业务系统首先是将该消息及其执行成功的状态标识进行封装，然后修改消息状态数据库中的消息状态信息为“已完成”，待修改完成后，消息状态数据库会返回该条消息的唯一编码。业务系统在收到该条消息的唯一编码后，准备发送消息给zookeeper服务器，以在该业务服务器对应的节点下添加该条消息的信息，从而使zookeeper服务器改变指定业务服务器的树节点信息，即：业务系统提交消息处理成功的信息。之后，根据消息数据保存的双向链表结构的特点，zookeeper服务器会异步触发监听该节点的业务服务器的回调程序，业务服务器便通过解析该节点下的唯一编码，从而获取并处理第二条消息。处理消息时，如前述第一条消息的处理过程，此处不再赘述。待第二条消息处理成功，修改消息状态为“已完成”后，会判断是否还有待执行消息，如果存在，则获取下一条消息并处理，如果没有，则该消息队列中所有消息处理完成，结束本次业务请求的处理。

图5是根据本发明实施例的分布式事务自动回退功能实现流程图。根据功能实现的需要，结合消息对了的异常重试功能，可以设置当消息处理失败时，会自动重试执行一定的次数，也就是重试次数阈值。当重试次数超过设定的阈值后，会执行消息自动回退，直到初始状态，从而保证数据的准确性。

回退消息是根据当前消息的操作情况来自动生成的，在业务系统根据数据库的访问请求生成消息队列时，每条消息对应的回退消息就已经自动生成，并和对应的参数封装在一起后保存在消息状态表中，并持久化保存在消息状态数据库里。根据当前消息的数据库操作类型，当前消息对应的回退消息可以包括以下情况：

1、若当前消息是做插入操作的，则根据当前消息待执行插入操作对象的标识符生成删除操作指令作为回退消息；

2、若当前消息是做更新操作的，则根据当前消息需要更新的对象及更新前的初始值生成更新操作指令作为回退消息。也就是说，若当前消息是做更新操作时，会查询出所有需要被更新的对象，并将相应程序语句中需要改变的字段的初始值与键值对的形式(其中，键名为该消息对应程序语句的标识符，键值为执行操作的更新语句)保存起来，然后生成相应的反向更新语句以作为回退消息；

3、若当前消息是做删除操作的，则根据当前消息待执行删除操作对象的标识符生成插入操作指令作为回退消息。

当需要执行消息自动回退时，首先需要修改消息状态为正在回退，之后获取回退消息和参数，待数据库中执行自动回退完成后，更改当前消息状态为回退完成。由于消息状态记录是以双向链表结构进行存储的，因此可向前获取顺序执行的前一条消息对应的回退消息来执行回退操作，如果存在前一条回退消息，则继续按照上述流程执行回退操作，否则说明消息队列已回退完成。

根据本发明实施例的技术方案，将接收到的数据库访问请求生成消息队列，并将消息数据写在zookeeper服务器的节点上，然后通过zookeeper的监听回调机制来通知注册在各节点上的业务服务器异步消费、处理消息，从而实现数据库分布式事务的处理。通过使用消息队列来处理数据库事务，可以对消息进行异步处理，当一条消息出现重试预定次数仍未能处理的异常时，将会执行消息回退直至初始状态，相应消息队列中未处理的消息便不再执行，从而节省了系统资源；且通过消息状态对消息的处理过程进行管理避免了上下级系统间的频繁通信，从而极大地提高了系统的性能。同时本发明的技术方案还具有较强的容错性，当一台业务服务器出现故障时，会有其他的业务服务器来接手处理未完成的任务，且可以部分重试，从而节约了系统资源，并且保证了数据处理的准确性。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (12)

1.一种基于消息队列实现数据库事务处理的方法，其特征在于，包括：

接收数据库访问请求，所述数据库访问请求包括一个或多个数据库操作；

根据所述数据库访问请求生成有序的消息队列，其中，所述消息队列中的消息对应数据库操作，每个消息包括消息状态和重试次数；

通过监控机构按顺序执行所述消息队列的处理，直到所述消息队列中所有消息被成功处理或者该消息队列中消息状态为“异常”的消息的重试次数超过预定阈值；

当所述消息队列中的消息状态为“异常”的消息的重试次数超过预定阈值，则回退所述消息队列中已执行的消息。

2.根据权利要求1所述的方法，其特征在于，所述消息队列的处理包括：

按顺序查找所述消息队列中消息状态为初始状态的第一个消息；

调用相应的数据库服务来处理该消息对应的数据库操作；

根据处理的结果更新该消息的消息状态和重试次数，其中，如果该消息对应的数据库操作成功完成，则修改该消息的消息状态，否则把该消息的消息状态设为“异常”并把该消息的重试次数递增1。

3.根据权利要求1所述的方法，其特征在于，

所述消息队列保存在消息状态表中，所述消息状态表以双向链表形式实现。

4.根据权利要求3所述的方法，其特征在于，

所述消息状态表还保存消息的回退消息。

5.根据权利要求4所述的方法，其特征在于，回退所述消息队列中已执行的消息包括：

从所述消息状态表中倒序读取所述消息队列中已执行消息对应的回退消息并根据所述回退消息执行回退，直至将所述消息队列回退至初始状态。

6.根据权利要求5所述的方法，其特征在于，所述回退消息根据当前消息的数据库操作类型包括以下情况：

若当前消息是做插入操作的，则根据当前消息待执行插入操作对象的标识符生成删除操作指令作为回退消息；

若当前消息是做更新操作的，则根据当前消息需要更新的对象及更新前的初始值生成更新操作指令作为回退消息；

若当前消息是做删除操作的，则根据当前消息待执行删除操作对象的标识符生成插入操作指令作为回退消息。

7.一种基于消息队列实现数据库事务处理的装置，其特征在于，包括：

访问请求接收模块，用于接收数据库访问请求，所述数据库访问请求包括一个或多个数据库操作；

消息队列生成模块，用于根据所述数据库访问请求生成有序的消息队列，其中，所述消息队列中的消息对应数据库操作，每个消息包括消息状态和重试次数；

监控机构，用于按顺序执行所述消息队列的处理，直到所述消息队列中所有消息被成功处理或者该消息队列中消息状态为“异常”的消息的重试次数超过预定阈值；

回退模块，用于当所述消息队列中的消息状态为“异常”的消息的重试次数超过预定阈值时回退所述消息队列中已执行的消息。

8.根据权利要求7所述的装置，其特征在于，所述监控机构还用于：

按顺序查找所述消息队列中消息状态为初始状态的第一个消息；

调用相应的数据库服务来处理该消息对应的数据库操作；

根据处理的结果更新该消息的消息状态和重试次数，其中，如果该消息对应的数据库操作成功完成，则修改该消息的消息状态，否则把该消息的消息状态设为“异常”并把该消息的重试次数递增1。

9.根据权利要求7所述的装置，其特征在于，

所述消息队列保存在消息状态表中，所述消息状态表以双向链表形式实现。

10.根据权利要求9所述的装置，其特征在于，

所述消息状态表还保存消息的回退消息。

11.根据权利要求10所述的装置，其特征在于，所述回退模块还用于：

从所述消息状态表中倒序读取所述消息队列中已执行消息对应的回退消息并根据所述回退消息执行回退，直至将所述消息队列回退至初始状态。

12.根据权利要求11所述的装置，其特征在于，所述回退消息根据当前消息的数据库操作类型包括以下情况：

若当前消息是做插入操作的，则根据当前消息待执行插入操作对象的标识符生成删除操作指令作为回退消息；

若当前消息是做更新操作的，则根据当前消息需要更新的对象及更新前的初始值生成更新操作指令作为回退消息；

若当前消息是做删除操作的，则根据当前消息待执行删除操作对象的标识符生成插入操作指令作为回退消息。