队列消息一致性的实现方法、装置、设备及存储介质

摘要

本发明公开了队列消息一致性的实现方法、装置、设备及存储介质，其中方法包括：消息发送方开启数据库事务及消息事务，并创建消息，进行数据库事务及消息事务提交，提交成功，将消息发送给消息接收方，消息的头部携带有消息的UUID以及replyTo的队列地址；消息接收方接收到消息后，开启消息事务及数据库事务，将消息的UUID保存到数据库中，并在执行业务逻辑成功后分别提交数据库事务及消息事务，提交成功，根据replyTo的队列地址，向消息发送方返回针对消息的消费成功确认消息。本发明所述方案提供了一个完整的队列消息一致性的框架模型，从而提升了系统性能等。

权利要求

1.一种队列消息一致性的实现方法，其特征在于，包括：消息发送方开启数据库事务及消息事务，并创建消息；

所述消息发送方进行数据库事务及消息事务提交，提交成功，将所述消息发送给消息接收方，所述消息的头部携带有所述消息的通用唯一识别码UUID以及回复replyTo的队列地址，以便所述消息接收方接收到所述消息后，开启消息事务及数据库事务，确定数据库中是否已经保存有所述消息的UUID，若否，将所述消息的UUID保存到数据库中，并在执行业务逻辑成功后分别提交数据库事务及消息事务，提交成功，根据所述replyTo的队列地址，向所述消息发送方返回针对所述消息的消费成功确认消息；若是，关闭数据库事务及消息事务，并直接向所述消息发送方返回针对所述消息的消费成功确认消息。

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

该方法进一步包括：

所述消息发送方创建消息之后，执行保存消息到数据库的操作，待数据库事务提交成功后，将所述消息真正地保存到数据库中；

所述消息发送方执行发送消息的操作，待消息事务提交成功后，将所述消息真正地发送给所述消息接收方。

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

该方法进一步包括：

所述消息发送方执行发送消息的操作之后，执行业务逻辑，执行成功，提交数据库事务；

若在数据库事务提交成功之前的操作出现异常，则所述消息发送方触发消息事务回滚及数据库事务回滚；

若在数据库事务提交成功后，消息事务提交异常，则所述消息发送方触发消息事务回滚。

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

该方法进一步包括：

所述消息发送方执行保存消息到数据库的操作之后，将所述消息的状态设置为已发送待确认RUNNING状态；

若消息事务提交异常，则所述消息发送方将数据库中保存的所述消息的状态修改为未发送WAITING状态；

若获取到所述消息发送方返回的针对所述消息的消费成功确认消息，则所述消息发送方将数据库中保存的所述消息的状态修改为完成SUCCESS状态；

对于处于WAITING状态的消息，所述消息发送方通过定时轮询进行发送；

对于处于RUNNING状态的消息，所述消息发送方通过定时轮询发现超过预定时长仍未获取到消费成功确认消息，则进行消息的重新发送。

5.一种队列消息一致性的实现方法，其特征在于，包括：消息接收方接收消息发送方发送来的消息，所述消息为所述消息发送方数据库事务及消息事务提交成功后发送来的消息，所述消息的头部携带有所述消息的通用唯一识别码UUID以及回复replyTo的队列地址；

所述消息接收方开启消息事务及数据库事务，确定数据库中是否已经保存有所述消息的UUID，若否，将所述消息的UUID保存到数据库中，并执行业务逻辑，执行成功后分别提交数据库事务及消息事务，提交成功，根据所述replyTo的队列地址，向所述消息发送方返回针对所述消息的消费成功确认消息；若是，关闭数据库事务及消息事务，并直接向所述消息发送方返回针对所述消息的消费成功确认消息。

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

所述消息接收方接收消息发送方发送来的消息包括：

所述消息接收方接收所述消息发送方通过消息中间件发送来的消息。

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

该方法进一步包括：

若在数据库事务提交成功之前的操作出现异常，则所述消息接收方触发数据库事务回滚及消息事务回滚，并通知所述消息中间件重新发送所述消息；

若在数据库事务提交成功后，消息事务提交异常，则所述消息接收方触发消息事务回滚，并通知所述消息中间件重新发送所述消息。

8.一种队列消息一致性的实现装置，其特征在于，包括：第一处理单元以及第二处理单元；

所述第一处理单元，用于开启数据库事务及消息事务，并创建消息；

所述第二处理单元，用于进行数据库事务及消息事务提交，提交成功，将所述消息发送给消息接收方，所述消息的头部携带有所述消息的通用唯一识别码UUID以及回复replyTo的队列地址，以便所述消息接收方接收到所述消息后，开启消息事务及数据库事务，确定数据库中是否已经保存有所述消息的UUID，若否，将所述消息的UUID保存到数据库中，并在执行业务逻辑成功后分别提交数据库事务及消息事务，提交成功，根据所述replyTo的队列地址，返回针对所述消息的消费成功确认消息；若是，关闭数据库事务及消息事务，并直接向所述消息发送方返回针对所述消息的消费成功确认消息。

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

所述第二处理单元进一步用于，

创建消息之后，执行保存消息到数据库的操作，待数据库事务提交成功后，将所述消息真正地保存到数据库中；

执行发送消息的操作，待消息事务提交成功后，将所述消息真正地发送给所述消息接收方。

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

所述第二处理单元进一步用于，

执行发送消息的操作之后，执行业务逻辑，执行成功，提交数据库事务；

若在数据库事务提交成功之前的操作出现异常，则触发消息事务回滚及数据库事务回滚；

若在数据库事务提交成功后，消息事务提交异常，则触发消息事务回滚。

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

所述第二处理单元进一步用于，

执行保存消息到数据库的操作之后，将所述消息的状态设置为已发送待确认RUNNING状态；

若消息事务提交异常，则将数据库中保存的所述消息的状态修改为未发送WAITING状态；

若获取到针对所述消息的消费成功确认消息，则将数据库中保存的所述消息的状态修改为完成SUCCESS状态；

对于处于WAITING状态的消息，通过定时轮询进行发送；

对于处于RUNNING状态的消息，若通过定时轮询发现超过预定时长仍未获取到消费成功确认消息，则进行消息的重新发送。

12.一种队列消息一致性的实现装置，其特征在于，包括：第三处理单元以及第四处理单元；

所述第三处理单元，用于接收消息发送方发送来的消息，所述消息为所述消息发送方数据库事务及消息事务提交成功后发送来的消息，所述消息的头部携带有所述消息的通用唯一识别码UUID以及回复replyTo的队列地址；

所述第四处理单元，用于开启消息事务及数据库事务，确定数据库中是否已经保存有所述消息的UUID，若否，将所述消息的UUID保存到数据库中，并执行业务逻辑，执行成功后分别提交数据库事务及消息事务，提交成功，根据所述replyTo的队列地址，向所述消息发送方返回针对所述消息的消费成功确认消息；若是，关闭数据库事务及消息事务，并直接向所述消息发送方返回针对所述消息的消费成功确认消息。

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

所述第三处理单元接收所述消息发送方通过消息中间件发送来的消息。

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

所述第四处理单元进一步用于，

若在数据库事务提交成功之前的操作出现异常，则触发数据库事务回滚及消息事务回滚，并通知所述消息中间件重新发送所述消息；

若在数据库事务提交成功后，消息事务提交异常，则触发消息事务回滚，并通知所述消息中间件重新发送所述消息。

15.一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1～4中任一项所述的方法。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1～4中任一项所述的方法。

17.一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求5～7中任一项所述的方法。

18.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求5～7中任一项所述的方法。

说明书

队列消息一致性的实现方法、装置、设备及存储介质

【技术领域】

[0001] 本发明涉及业务处理技术，特别涉及队列消息一致性的实现方法、装置、设备及存储介质。【背景技术】

[0002] 在业务系统中，两个服务间通常会使用消息中间件来进行通信，如ActiveMQ、RabbittMQ等。消息通常包括队列消息(Queue)和订阅消息(Topic)两种，本发明中主要关注队列消息。

[0003] 在实际应用中，消息发送方通常会执行写数据库和发送消息的操作，消息接收方接收到消息后对消息进行处理，需要确保消息在发送方和接收方的一致性，即双方正确发送和消费了消息，并根据消息正确处理了业务逻辑等。

[0004] 要确保一致性，消息发送方写数据库和发送消息的操作均要成功，消息接收方接收到消息后要保证业务正确运行，消息要保证不丢失，消息接收方一定能够接收到消息，接收方对同一个消息只能消费一次等。上述过程中的任何一个环节出现问题都会导致不一致。

[0005] 目前业界仅存在一些针对单个环节的解决方案，而没有一个完整的解决方案，从而影响了系统性能。【发明内容】

[0006] 有鉴于此，本发明提供了队列消息一致性的实现方法、装置、设备及存储介质。

[0007] 具体技术方案如下：

[0008] 一种队列消息一致性的实现方法，包括：

[0009] 消息发送方开启数据库事务及消息事务，并创建消息；

[0010] 所述消息发送方进行数据库事务及消息事务提交，提交成功，将所述消息发送给消息接收方，所述消息的头部携带有所述消息的通用唯一识别码UUID以及回复replyTo的队列地址，以便所述消息接收方接收到所述消息后，开启消息事务及数据库事务，将所述消息的UUID保存到数据库中，并在执行业务逻辑成功后分别提交数据库事务及消息事务，提交成功，根据所述replyTo的队列地址，向所述消息发送方返回针对所述消息的消费成功确认消息。

[0011] 根据本发明一优选实施例，该方法进一步包括：

[0012] 所述消息发送方创建消息之后，执行保存消息到数据库的操作，待数据库事务提交成功后，将所述消息真正地保存到数据库中；

[0013] 所述消息发送方执行发送消息的操作，待消息事务提交成功后，将所述消息真正地发送给所述消息接收方。

[0014] 根据本发明一优选实施例，该方法进一步包括：

[0015] 所述消息发送方执行发送消息的操作之后，执行业务逻辑，执行成功，提交数据库事务；

[0016] 若在数据库事务提交成功之前的操作出现异常，则所述消息发送方触发消息事务回滚及数据库事务回滚；

[0017] 若在数据库事务提交成功后，消息事务提交异常，则所述消息发送方触发消息事务回滚。

[0018] 根据本发明一优选实施例，该方法进一步包括：

[0019] 所述消息发送方执行保存消息到数据库的操作之后，将所述消息的状态设置为已发送待确认RUNNING状态；

[0020] 若消息事务提交异常，则所述消息发送方将数据库中保存的所述消息的状态修改为未发送WAITING状态；

[0021] 若获取到所述消息发送方返回的针对所述消息的消费成功确认消息，则所述消息发送方将数据库中保存的所述消息的状态修改为完成SUCCESS状态；

[0022] 对于处于WAITING状态的消息，所述消息发送方通过定时轮询进行发送；

[0023] 对于处于RUNNING状态的消息，所述消息发送方通过定时轮询发现超过预定时长仍未获取到消费成功确认消息，则进行消息的重新发送。

[0024] 一种队列消息一致性的实现方法，包括：

[0025] 消息接收方接收消息发送方发送来的消息，所述消息为所述消息发送方数据库事务及消息事务提交成功后发送来的消息，所述消息的头部携带有所述消息的通用唯一识别码UUID以及回复replyTo的队列地址；

[0026] 所述消息接收方开启消息事务及数据库事务，将所述消息的UUID保存到数据库中，并执行业务逻辑，执行成功后分别提交数据库事务及消息事务，提交成功，根据所述replyTo的队列地址，向所述消息发送方返回针对所述消息的消费成功确认消息。

[0027] 根据本发明一优选实施例，该方法进一步包括：

[0028] 所述消息接收方开启消息事务及数据库事务之后，确定数据库中是否已经保存有所述消息的UUID；

[0029] 若否，则将所述消息的UUID保存到数据库中；

[0030] 若是，则关闭数据库事务及消息事务，并向所述消息发送方返回针对所述消息的消费成功确认消息。

[0031] 根据本发明一优选实施例，所述消息接收方接收消息发送方发送来的消息包括：

[0032] 所述消息接收方接收所述消息发送方通过消息中间件发送来的消息。

[0033] 根据本发明一优选实施例，该方法进一步包括：

[0034] 若在数据库事务提交成功之前的操作出现异常，则所述消息接收方触发数据库事务回滚及消息事务回滚，并通知所述消息中间件重新发送所述消息；

[0035] 若在数据库事务提交成功后，消息事务提交异常，则所述消息接收方触发消息事务回滚，并通知所述消息中间件重新发送所述消息。

[0036] 一种队列消息一致性的实现装置，包括：第一处理单元以及第二处理单元；

[0037] 所述第一处理单元，用于开启数据库事务及消息事务，并创建消息；

[0038] 所述第二处理单元，用于进行数据库事务及消息事务提交，提交成功，将所述消息发送给消息接收方，所述消息的头部携带有所述消息的通用唯一识别码UUID以及回复replyTo的队列地址，以便所述消息接收方接收到所述消息后，开启消息事务及数据库事务，将所述消息的UUID保存到数据库中，并在执行业务逻辑成功后分别提交数据库事务及消息事务，提交成功，根据所述replyTo的队列地址，返回针对所述消息的消费成功确认消息。

[0039] 根据本发明一优选实施例，所述第二处理单元进一步用于，

[0040] 创建消息之后，执行保存消息到数据库的操作，待数据库事务提交成功后，将所述消息真正地保存到数据库中；

[0041] 执行发送消息的操作，待消息事务提交成功后，将所述消息真正地发送给所述消息接收方。

[0042] 根据本发明一优选实施例，所述第二处理单元进一步用于，

[0043] 执行发送消息的操作之后，执行业务逻辑，执行成功，提交数据库事务；

[0044] 若在数据库事务提交成功之前的操作出现异常，则触发消息事务回滚及数据库事务回滚；

[0045] 若在数据库事务提交成功后，消息事务提交异常，则触发消息事务回滚。

[0046] 根据本发明一优选实施例，所述第二处理单元进一步用于，

[0047] 执行保存消息到数据库的操作之后，将所述消息的状态设置为已发送待确认RUNNING状态；

[0048] 若消息事务提交异常，则将数据库中保存的所述消息的状态修改为未发送WAITING状态；

[0049] 若获取到针对所述消息的消费成功确认消息，则将数据库中保存的所述消息的状态修改为完成SUCCESS状态；

[0050] 对于处于WAITING状态的消息，通过定时轮询进行发送；

[0051] 对于处于RUNNING状态的消息，若通过定时轮询发现超过预定时长仍未获取到消费成功确认消息，则进行消息的重新发送。

[0052] 一种队列消息一致性的实现装置，包括：第三处理单元以及第四处理单元；

[0053] 所述第三处理单元，用于接收消息发送方发送来的消息，所述消息为所述消息发送方数据库事务及消息事务提交成功后发送来的消息，所述消息的头部携带有所述消息的通用唯一识别码UUID以及回复replyTo的队列地址；

[0054] 所述第四处理单元，用于开启消息事务及数据库事务，将所述消息的UUID保存到数据库中，并执行业务逻辑，执行成功后分别提交数据库事务及消息事务，提交成功，根据所述replyTo的队列地址，向所述消息发送方返回针对所述消息的消费成功确认消息。

[0055] 根据本发明一优选实施例，所述第四处理单元进一步用于，

[0056] 开启消息事务及数据库事务之后，确定数据库中是否已经保存有所述消息的UUID；

[0057] 若否，则将所述消息的UUID保存到数据库中；

[0058] 若是，则关闭数据库事务及消息事务，并向所述消息发送方返回针对所述消息的消费成功确认消息。

[0059] 根据本发明一优选实施例，所述第三处理单元接收所述消息发送方通过消息中间件发送来的消息。

[0060] 根据本发明一优选实施例，所述第四处理单元进一步用于，

[0061] 若在数据库事务提交成功之前的操作出现异常，则触发数据库事务回滚及消息事务回滚，并通知所述消息中间件重新发送所述消息；

[0062] 若在数据库事务提交成功后，消息事务提交异常，则触发消息事务回滚，并通知所述消息中间件重新发送所述消息。

[0063] 一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现如以上所述的方法。

[0064] 一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如以上所述的方法。

[0065] 基于上述介绍可以看出，采用本发明所述方案，消息发送方可开启数据库事务及消息事务，并创建消息，待数据库事务及消息事务均提交成功，将消息发送给消息接收方，消息的头部可携带有消息的UUID以及replyTo的队列地址，这样，消息接收方接收到消息后，可开启消息事务及数据库事务，并可将消息的UUID保存到数据库中，进而在执行业务逻辑成功后分别提交数据库事务及消息事务，提交成功，根据replyTo的队列地址，向消息发送方返回针对消息的消费成功确认消息，即整合了从发送到接收的多个环节，提供了一个完整的队列消息一致性的框架模型，从而克服了现有技术中存在的问题，提升了系统性能等。【附图说明】

[0066] 图1为本发明所述队列消息一致性的实现方法第一实施例的流程图。

[0067] 图2为本发明所述消息发送方的处理流程示意图。

[0068] 图3为本发明所述队列消息一致性的实现方法第二实施例的流程图。

[0069] 图4为本发明所述消息接收方的处理流程示意图。

[0070] 图5为本发明所述方案的整体架构的示意图。

[0071] 图6为本发明所述队列消息一致性的实现装置第一实施例的组成结构示意图。

[0072] 图7为本发明所述队列消息一致性的实现装置第二实施例的组成结构示意图。

[0073] 图8示出了适于用来实现本发明实施方式的示例性计算机系统/服务器12的框图。【具体实施方式】

[0074] 为了使本发明的技术方案更加清楚、明白，以下参照附图并举实施例，对本发明所述方案进行进一步说明。

[0075] 显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

[0076] 图1为本发明所述队列消息一致性的实现方法第一实施例的流程图。如图1所示，包括以下具体实现方式。

[0077] 在101中，消息发送方开启数据库事务及消息事务，并创建消息。

[0078] 在102中，消息发送方进行数据库事务及消息事务提交，提交成功，将消息发送给消息接收方，消息的头部(Header)携带有消息的通用唯一识别码(UUID)以及回复(replyTo)的队列地址，以便消息接收方接收到消息后，开启消息事务及数据库事务，将消息的UUID保存到数据库(DB)中，并在执行业务逻辑成功后分别提交数据库事务及消息事务，提交成功，根据replyTo的队列地址，向消息发送方返回针对消息的消费成功确认消息。

[0079] 本实施例中，消息发送方开启数据库事务及消息事务，并创建消息之后，可执行保存消息到数据库的操作，待数据库事务提交成功后，将消息真正地保存到数据库中，进一步地，执行发送消息的操作，待消息事务提交成功后，将消息真正地发送给消息接收方。其中，消息发送方可通过消息中间件来将消息发送给消息接收方。

[0080] 消息发送方还需要执行业务逻辑，执行成功，提交数据库事务，若在数据库事务提交成功之前的操作出现异常，可触发消息事务回滚及数据库事务回滚，若在数据库事务提交成功后，消息事务提交异常，可触发消息事务回滚。

[0081] 另外，消息发送方在执行保存消息到数据库的操作之后，还可将消息的状态设置为已发送待确认(RUNNING)状态，若消息事务提交异常，则需要将数据库中保存的消息的状态修改为未发送(WAITING)状态，后续，若获取到针对消息的消费成功确认消息，则需要将数据库中保存的消息的状态修改为完成(SUCCESS)状态。

[0082] 对于处于WAITING状态的消息，消息发送方可通过定时轮询进行发送。对于处于RUNNING状态的消息，消息发送方若通过定时轮询发现超过预定时长仍未获取到消费成功确认消息，则可进行消息的重新发送，即若发现消息处理超时，则会重试发送。

[0083] 本发明的框架是以数据库事务为基础来保证一致性的，在消息发送方和消息接收方需要各有一个数据库来保存消息内容。

[0084] 其中，消息发送方保存的消息内容可如表一所示。

[0085]

[0086] 表一消息发送方保存的消息内容

[0087] 上述数据库表用于在消息发送方支持消息内容的持久化，具有通用性，业务可以根据实际情况扩展。

[0088] 现有技术中，消息持久化通常都由消息中间件来完成，而通过上述方式，将消息持久化的任务转移到业务端进行，从而降低了消息中间件的负载，而且，各个业务自行处理持久化也有利于分摊持久化的压力，降低各个业务间的相互影响。

[0089] 基于上述介绍，图2为本发明所述消息发送方的处理流程示意图。

[0090] 如图2所示，在业务操作开始时，开启数据库事务。

[0091] 在业务逻辑中需要发送消息时，开启消息事务，并创建一条消息，执行保存消息到数据库的操作，并将消息的状态设置为RUNNING状态。之后执行发送消息的操作，消息的头部需要携带有消息的UUID以及replyTo的队列地址，UUID是全局唯一的。由于消息事务的特性，消息并没有被真正发送，需要等到消息事务提交成功后才会真正地发送，类似地，待数据库事务提交成功后，才会将消息真正地保存到数据库中，保存方式可参照表一所示。

[0092] 当业务逻辑执行成功后，提交数据库事务，提交成功，所创建的消息被真正地保存到数据库中，若在数据库事务提交成功之前的操作出现异常，可触发消息事务回滚及数据库事务回滚，具体地，可先触发消息事务回滚，进而触发数据库事务回滚，保证原子性。

[0093] 数据库事务成功提交后，进行消息事务提交，提交成功，消息真正地发送给消息接收方，若消息事务提交异常，可触发消息事务回滚，但数据库事务不会回滚，这种情况下，消息虽然未被发送，但由于已经持久化到数据库中，因此消息并不会丢失，进一步地，针对这种情况，还需要执行一次修改消息状态的操作，即将数据库中保存的消息的状态修改为WAITING状态。

[0094] 对于处于WAITING状态的消息，可通过定时轮询进行发送。对于处于RUNNING状态的消息，若通过定时轮询发现超过预定时长仍未获取到消费成功确认消息，则可进行消息的重新发送，即若发现消息处理超时，则会重试发送。若上述将数据库中保存的消息的状态修改为WAITING状态的操作失败，那么消息将会维持原来的RUNNING状态不变，这样，经过一定时长后消息会被重新发送，通过这种机制，保证了如果业务逻辑执行成功，那么消息一定会被成功发送。

[0095] 图3为本发明所述队列消息一致性的实现方法第二实施例的流程图。如图3所示，包括以下具体实现方式。

[0096] 在301中，消息接收方接收消息发送方发送来的消息，所述消息为消息发送方数据库事务及消息事务提交成功后发送来的消息，消息的头部携带有消息的UUID以及replyTo的队列地址。

[0097] 在302中，消息接收方开启消息事务及数据库事务，将消息的UUID保存到数据库中，并执行业务逻辑，执行成功后分别提交数据库事务及消息事务，提交成功，根据replyTo的队列地址，向消息发送方返回针对消息的消费成功确认消息。

[0098] 本实施例中，消息接收方开启消息事务及数据库事务之后，可确定数据库中是否已经保存有消息的UUID，若否，可将消息的UUID保存到数据库中，若是，可关闭数据库事务及消息事务，并直接向消息发送方返回针对消息的消费成功确认消息。

[0099] 另外，若在数据库事务提交成功之前的操作出现异常，消息接收方可触发数据库事务回滚及消息事务回滚，并通知消息中间件重新发送消息。若在数据库事务提交成功后，消息事务提交异常，消息接收方可触发消息事务回滚，并通知消息中间件重新发送消息。

[0100] 基于上述介绍，图4为本发明所述消息接收方的处理流程示意图。

[0101] 如图4所示，消息接收方通过消息中间件接收消息，开启消息事务和数据库事务，消息的头部携带有消息的UUID以及replyTo的队列地址。

[0102] 之后，查询数据库中是否已经保存有消息的UUID，若是，可直接关闭数据库事务及消息事务，并向消息发送方返回消费成功确认消息，若否，可将消息的UUID保存到数据库中，如表二所示。

[0103]字段名 说明
message_id 接收到的消息的UUID
received_time 接收时间

[0104] 表二消息接收方保存的消息内容

[0105] 可以看出，相比于表一，消息接收方需要保存的消息内容较少，只需要保存消息的UUID和接收时间即可，只要在事务内成功保存且事务成功完成，即说明消息已消费成功。

[0106] 正常保存消息的UUID后，开始执行业务逻辑，执行成功，提交数据库事务，若在数据库事务提交成功之前的操作出现异常，可触发数据库事务回滚及消息事务回滚，并通知消息中间件重新发送消息，即通知消息中间件发起消息重试，这种情况下，之前保存的消息的UUID也已经被回滚，因此业务可以正常地通过重新发送的消息再次执行。

[0107] 若数据库事务提交成功，则提交消息事务，若消息事务提交异常，可触发消息事务回滚，并通知消息中间件重新发送消息，当消息接收方接收到重新发送的消息时，会发现数据库中已经保存了消息的UUID，那么业务逻辑将不会被再次执行，而是直接跳转到最后一步，即向消息发送方返回消费成功确认消息，通过这种方式，保证了业务逻辑的幂等性。

[0108] 若消息事务提交成功，可向消息发送方返回消费成功确认消息，具体地，可根据消息头部携带的replyTo的队列地址，向该队列地址发送消费成功确认消息，其中会携带有消息的UUID。如果消费成功确认消息发送失败，那么消息发送方会通过定时轮询发现消息处理超时，从而会进行消息的重新发送，而消息接收方可通过幂等性保证，再次回复消费成功确认消息，通过这种机制保证了回复消息一定会被发送成功。

[0109] 消息发送方会监听指定的replyTo的队列地址，当接收到消费成功确认消息后，会更新消费成功确认消息中携带的UUID对应的消息的状态为SUCCESS状态，至此，一条消息的生命周期结束。若消费成功确认消息重复发送，当检查到消息的状态已经是SUCCESS状态时，消息发送方不会再做任何操作。

[0110] 综合上述介绍，图5为本发明所述方案的整体架构的示意图，具体实现请参照前述各实施例中的相关说明，不再赘述。

[0111] 需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

[0112] 在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

[0113] 总之，采用上述各方法实施例所述方案，整合了从发送到接收的多个环节，充分保证了原子性、幂等性、消息不丢不重等，保证了一致性；而且，具有很强的容错能力，消息在消息中间件和消息发送方都有重试逻辑，可扩展性强；另外，不完全依赖消息中间件，消息中间件无需支持消息的持久化，降低了消息中间件的负载等；总体而言，提升了系统性能。

[0114] 以上是关于方法实施例的介绍，以下通过装置实施例，对本发明所述方案进行进一步说明。

[0115] 图6为本发明所述队列消息一致性的实现装置第一实施例的组成结构示意图。如图6所示，包括：第一处理单元601以及第二处理单元602。

[0116] 第一处理单元601，用于开启数据库事务及消息事务，并创建消息。

[0117] 第二处理单元602，用于进行数据库事务及消息事务提交，提交成功，将消息发送给消息接收方，消息的头部携带有消息的UUID以及replyTo的队列地址，以便消息接收方接收到消息后，开启消息事务及数据库事务，将消息的UUID保存到数据库中，并在执行业务逻辑成功后分别提交数据库事务及消息事务，提交成功，根据replyTo的队列地址，返回针对消息的消费成功确认消息。

[0118] 在第一处理单元601开启数据库事务及消息事务并创建消息后，第二处理单元602可执行保存消息到数据库的操作，并可将消息的状态设置为RUNNING状态，待数据库事务提交成功后，将消息真正地保存到数据库中，另外，还可执行发送消息的操作，待消息事务提交成功后，将消息真正地发送给消息接收方，消息的头部需要携带有消息的UUID以及replyTo的队列地址。

[0119] 第二处理单元602执行业务逻辑，执行成功后，提交数据库事务，提交成功，所创建的消息被真正地保存到数据库中，若在数据库事务提交成功之前的操作出现异常，可触发消息事务回滚及数据库事务回滚，具体地，可先触发消息事务回滚，进而触发数据库事务回滚，保证原子性。

[0120] 数据库事务成功提交后，第二处理单元602可进行消息事务提交，提交成功，消息真正地发送给消息接收方，若消息事务提交异常，可触发消息事务回滚，但数据库事务不会回滚，这种情况下，消息虽然未被发送，但由于已经持久化到数据库中，因此消息并不会丢失，进一步地，针对这种情况，还需要执行一次修改消息状态的操作，即将数据库中保存的消息的状态修改为WAITING状态。

[0121] 对于处于WAITING状态的消息，第二处理单元602可通过定时轮询进行发送。对于处于RUNNING状态的消息，若通过定时轮询发现超过预定时长仍未获取到消费成功确认消息，第二处理单元602可进行消息的重新发送，即若发现消息处理超时，则会重试发送。若上述将数据库中保存的消息的状态修改为WAITING状态的操作失败，那么消息将会维持原来的RUNNING状态不变，这样，经过一定时长后消息会被重新发送，通过这种机制，保证了如果业务逻辑执行成功，那么消息一定会被成功发送。

[0122] 若获取到针对消息的消费成功确认消息，那么第二处理单元602会将数据库中保存的消息的状态修改为完成SUCCESS状态。

[0123] 图7为本发明队列消息一致性的实现装置第二实施例的组成结构示意图。如图7所示，包括：第三处理单元701以及第四处理单元702。

[0124] 第三处理单元701，用于接收消息发送方发送来的消息，所述消息为消息发送方数据库事务及消息事务提交成功后发送来的消息，消息的头部携带有消息的UUID以及replyTo的队列地址。

[0125] 第四处理单元702，用于开启消息事务及数据库事务，将消息的UUID保存到数据库中，并执行业务逻辑，执行成功后分别提交数据库事务及消息事务，提交成功，根据replyTo的队列地址，向消息发送方返回针对消息的消费成功确认消息。

[0126] 第三处理单元701通过消息中间件接收消息发送方发送来的消息，消息的头部携带有消息的UUID以及replyTo的队列地址。

[0127] 第四处理单元702开启消息事务及数据库事务，并确定数据库中是否已经保存有消息的UUID，若否，可将消息的UUID保存到数据库中，若是，可关闭数据库事务及消息事务，并向消息发送方返回针对消息的消费成功确认消息。

[0128] 正常保存消息的UUID后，第四处理单元702开始执行业务逻辑，执行成功，提交数据库事务，若在数据库事务提交成功之前的操作出现异常，可触发数据库事务回滚及消息事务回滚，并通知消息中间件重新发送消息，即通知消息中间件发起消息重试，这种情况下，之前保存的消息的UUID也已经被回滚，因此业务可以正常地通过重新发送的消息再次执行。

[0129] 若数据库事务提交成功，则第四处理单元702提交消息事务，若消息事务提交异常，可触发消息事务回滚，并通知消息中间件重新发送消息，当接收到重新发送的消息时，会发现数据库中已经保存了消息的UUID，那么业务逻辑将不会被再次执行，而是直接跳转到最后一步，即向消息发送方返回消费成功确认消息，通过这种方式，保证了业务逻辑的幂等性。

[0130] 若消息事务提交成功，第四处理单元702可向消息发送方返回消费成功确认消息，具体地，可根据消息头部携带的replyTo的队列地址，向该队列地址发送消费成功确认消息，其中会携带有消息的UUID。如果消费成功确认消息发送失败，那么消息发送方会通过定时轮询发现消息处理超时，从而会进行消息的重新发送，而第四处理单元702可通过幂等性保证，再次回复消费成功确认消息，通过这种机制保证了回复消息一定会被发送成功。

[0131] 消息发送方会监听指定的replyTo的队列地址，当接收到消费成功确认消息后，会更新消费成功确认消息中携带的UUID对应的消息的状态为SUCCESS状态，至此，一条消息的生命周期结束。

[0132] 上述各装置实施例的具体工作流程请参照前述各方法实施例中的相应说明，不再赘述。

[0133] 总之，采用上述各装置实施例所述方案，整合了从发送到接收的多个环节，充分保证了原子性、幂等性、消息不丢不重等，保证了一致性；而且，具有很强的容错能力，消息在消息中间件和消息发送方都有重试逻辑，可扩展性强；另外，不完全依赖消息中间件，消息中间件无需支持消息的持久化，降低了消息中间件的负载等；总体而言，提升了系统性能。

[0134] 图8示出了适于用来实现本发明实施方式的示例性计算机系统/服务器12的框图。图8显示的计算机系统/服务器12仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

[0135] 如图8所示，计算机系统/服务器12以通用计算设备的形式表现。计算机系统/服务器12的组件可以包括但不限于：一个或者多个处理器(处理单元)16，存储器28，连接不同系统组件(包括存储器28和处理器16)的总线18。

[0136] 总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。

[0137] 计算机系统/服务器12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算机系统/服务器12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

[0138] 存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)30和/或高速缓存存储器32。计算机系统/服务器12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图8未显示，通常称为“硬盘驱动器”)。尽管图8中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。

[0139] 具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如存储器28中，这样的程序模块42包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发明所描述的实施例中的功能和/或方法。

[0140] 计算机系统/服务器12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该计算机系统/服务器12交互的设备通信，和/或与使得该计算机系统/服务器12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口22进行。并且，计算机系统/服务器12还可以通过网络适配器20与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图8所示，网络适配器20通过总线18与计算机系统/服务器12的其它模块通信。应当明白，尽管图中未示出，可以结合计算机系统/服务器12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

[0141] 处理器16通过运行存储在存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现图1或3所示实施例中的方法。

[0142] 本发明同时公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时将实现如图1或3所示实施例中的方法。

[0143] 可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

[0144] 计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

[0145] 计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、电线、光缆、RF等等，或者上述的任意合适的组合。

[0146] 可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

[0147] 在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法等，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

[0148] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

[0149] 另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

[0150] 上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

[0151] 以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。