一种保证消息数据一致性的方法及装置

技术领域

本发明涉及数据库领域，更具体的说，是涉及一种保证消息数据一致性的方法及装置。

背景技术

在分布式系统中，系统间的通信除了大家所熟知的RPC(远程过程调用，RemoteProcedure Call)外，基于MQ(Message Queue，消息队列)的异步通信也越来越流行，已经成为基础设施的重要组成部分。而MQ的引入对系统间的数据一致性提出了新的挑战，逐渐成为系统稳定性的一大隐患。

为了解决MQ引入后系统间数据一致性的问题，当前存在一种基于消息中间件实现数据一致性的方案，但消息中间件的存在，不仅使得系统更加复杂，且在一些特殊情况下，数据的一致性仍然无法保障。

发明内容

有鉴于此，本发明提供如下技术方案：

一种保证消息数据一致性的方法，包括：

获得业务请求并执行所述业务请求，所述业务请求包括业务对象；

若所述业务请求执行成功，构建表征所述业务请求执行成功的事件对象；

将所述业务对象和所述事件对象封装成一个本地事务并提交数据库；

若提交成功，将与所述本地事务对应的第一消息发送至消息队列。

可选地，所述事件对象中包括业务ID、事件ID、事件类型、构建时间和消息标识，其中，所述消息标识置空。

可选地，所述第一消息中包括事件ID，在所述将与所述本地事务对应的第一消息发送至消息队列后，还包括：

接收所述消息队列返回的确认消息，所述确认消息表征所述消息队列接收到所述第一消息，所述确认消息中包括消息标识数据和事件ID；

将所述消息标识数据写入与所述事件ID对应消息数据中的消息标识。

可选地，还包括：

定时扫描存储事件对象的消息表，确定其中消息标志为空的事件对象；

将与所述标志为空的事件对象所在的本地事务对应的第一消息重新发送。

可选地，所述将所述业务对象和所述事件对象封装成一个本地事务并提交数据库，包括：

将所述业务对象和所述事件对象封装称为一个本地事务；

将所述业务对象的变更数据保存在业务表中；

将所述事件对象对应的数据存储到本地消息表中。

可选地，所述将与所述本地事务对应的第一消息发送至消息队列，包括：

调用消息队列的发送接口，将与所述本地事务对应的第一消息发送至消息队列。

本申请还公开了一种保证消息数据一致性的装置，包括：

请求获得模块，用于获得业务请求并执行所述业务请求，所述业务请求包括业务对象；

对象构建模块，用于在所述业务请求执行成功后，构建表征所述业务请求执行成功的事件对象；

数据提交模块，用于将所述业务对象和所述事件对象封装成一个本地事务并提交数据库；

消息发送模块，用于将与所述本地事务对应的第一消息发送至消息队列。

可选地，所述事件对象中包括业务ID、事件ID、事件类型、构建时间和消息标识，其中，所述消息标识置空。

可选地，所述第一消息中包括事件ID，装置还包括：

消息接收模块，用于接收所述消息队列返回的确认消息，所述确认消息表征所述消息队列接收到所述第一消息，所述确认消息中包括消息标识数据和事件ID；

消息补充模块，用于将所述消息标识数据写入与所述事件ID对应消息数据中的消息标识。

可选地，还包括：

消息扫描模块，用于定时扫描存储事件对象的消息表，确定其中消息标志为空的事件对象；

所述消息发送模块还用于：将与所述标志为空的事件对象所在的本地事务对应的第一消息重新发送。

经由上述的技术方案可知，本发明实施例公开了一种保证消息数据一致性的方法及装置，其中，方法包括：获得业务请求并执行所述业务请求，所述业务请求包括业务对象；若所述业务请求执行成功，构建表征所述业务请求执行成功的事件对象；将所述业务对象和所述事件对象封装成一个本地事务并提交数据库；将与所述本地事务对应的第一消息发送至消息队列。上述方案能够将与业务请求对应的业务对象和事件对象封装成一个本地事务，这样有效保证两者的同步处理，若本地事务提交成功，且第一消息发送成功，则变更数据可供其他业务正常使用；若本地事务提交失败，则对应业务请求的业务变更数据以及相应事件对象的变更数据将会统一被回滚，不会进一步触发第一消息的发送，从而严格保证数据库数据与消息数据的一致性。

附图说明

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

图1为本申请实施例公开的一个数据库数据更新的场景示意图；

图2为本申请实施例公开的一个数据库数据更新的处理方案示例图；

图3为本申请实施例公开的另一个数据库数据更新的处理方案示例图；

图4为本申请实施例公开的另一个数据库数据更新的场景示意图；

图5为本申请实施例公开的一种保证消息数据一致性的方法流程图；

图6为本申请实施例公开的另一个保证消息数据一致性的方法的流程图；

图7为本申请实施例公开的保证消息数据一致性的架构实现示意图；

图8为本申请实施例公开的保证消息数据一致性的装置结构示意图。

具体实施方式

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

为了更好的理解本申请实施例内容，下面对分布式系统引入消息队列MQ的一些背景内容进行相应介绍。

在引入消息队列MQ后，MQ与数据库操作存在一致性要求。但具体如何实现一致性，为领域内技术人员需要着重研究的问题。研究过程中需要考虑的问题诸多。

例如一个业务操作中存在“更新DB(数据库)”和“发送MQ”两个动作，参见图1所示，如果流程正常结束，数据变更保存到DB，变更消息成功发送到MQ，就不存在消息数据不一致的问题。

但如果上述流程中间发生异常情况，一致性就得不到保障。参见图2示例，其中，更新DB和发送MQ封装在一个数据库事务；如果在事务提交前，发送MQ之后出现了异常，将触发数据库事务回滚，此时：DB变更被回滚，MQ无法回滚；结果就是其他业务从MQ中成功获取消息并进行相应业务处理，而DB回滚业务操作已经失败，下游业务处理了一个本不存在的变更。

参见图3，在另一个示例中，数据库事务只对DB更新进行保护，也即仅将数据库变更包在一个数据库事务里；如果在事务提交后，发送MQ前出现了异常，此时：数据库变更已经成功持久化到DB，MQ发送失败，下游业务无法获取变更消息；最终导致丢失变更，未成功触发下游的正常业务。

在一些更加复杂的场景中，如图4所示数据库变更和发送MQ交替出现的场景，消息和数据库数据的一致性更加难以得到保障。

图5为本申请实施例公开的一种保证消息数据一致性的方法流程图。参见图5所示，保证消息数据一致性的方法可以包括：

步骤501：获得业务请求并执行所述业务请求，所述业务请求包括业务对象。

其中的业务请求为外部业务发送的请求，该业务请求可以是请求对本地数据库中存储的数据内容进行写入操作的请求，这里的写入操作可以但不限制为数据插入、数据更新、数据删除等。

所述业务对象用于表征需要执行数据写入操作的目标数据或目标位置。业务对象即为业务表的映射，例如一张订单表映射到一个订单的业务对象上，业务对象包含订单的相关信息，例如订单号，订单创建时间等。再如，所述业务请求表征在第一数据表格插入一条新的数据，则其中的第一数据表格即为对应该业务请求的业务对象。

步骤502：若所述业务请求执行成功，构建表征所述业务请求执行成功的事件对象。

若所述业务请求执行成功，则会构建相应的事件对象，表征数据库中发生了对应的数据变更事件。而若所述业务请求执行失败，相当数据库中的数据没有发生变动，则无需构建事件对象。

步骤503：将所述业务对象和所述事件对象封装成一个本地事务并提交数据库。

将业务对象和事件对象封装成一个本地事务，则可以保证两者的同步性，也即数据库中的数据变更和对应的事件记录数据只能同时存在，或同时被回滚。这样，若数据变更成功，相应的变更数据和事件记录数据会被同时提交到数据库；若提交数据库失败，数据变更内容会被回滚，同时事件记录数据也会被回滚，数据库恢复获得业务请求之前的状态。

步骤504：若提交成功，将与所述本地事务对应的第一消息发送至消息队列。

在本地事务成功提交到数据库后，可以进行后续的消息发送操作，也即将与所述本地事务对应的第一消息发送至消息队列，使得其他业务能够通过消息队列获得数据库中的数据情况，便于其调用相关数据。

本实施例所述保证消息数据一致性的方法能够将与业务请求对应的业务对象和事件对象封装成一个本地事务，这样有效保证两者的同步处理，若本地事务提交成功，且第一消息发送成功，则变更数据可供其他业务正常使用；若本地事务提交失败，则对应业务请求的业务变更数据以及相应事件对象的变更数据将会统一被回滚，不会进一步触发第一消息的发送，从而严格保证数据库数据与消息数据的一致性。

上述实施例中，所述事件对象中可以但不限于包括业务ID、事件ID、事件类型、构建时间、消息标识等。其中，业务ID表征业务类型，事件ID表征唯一的事件编号，事件类型表征数据变更事件的类型，如数据删除、数据更新等，构建时间表征事件对象的构建时间。其中，所述消息标识置空，其内容由消息队列在接收到所述第一消息后返回的确认消息确定。也即，消息队列反馈的确认消息中会携带消息标识的内容。

图6为本申请实施例公开的另一个保证消息数据一致性的方法的流程图。结合图6所示，一个实现中，所述第一消息中包括事件ID，方法可以包括：

步骤601：获得业务请求并执行所述业务请求，所述业务请求包括业务对象。

步骤602：若所述业务请求执行成功，构建表征所述业务请求执行成功的事件对象。

步骤603：将所述业务对象和所述事件对象封装成一个本地事务并提交数据库。

步骤604：若提交成功，将与所述本地事务对应的第一消息发送至消息队列。

步骤605：接收所述消息队列返回的确认消息，所述确认消息表征所述消息队列接收到所述第一消息，所述确认消息中包括消息标识数据和事件ID。

由于每一个事件对象都有自己唯一的事件ID，因此所述确认消息中的事件ID可以用来确认对应的事件对象，也即确定所述消息标识数据应该填写到哪个事件对象置空的消息标识字段。

步骤606：将所述消息标识数据写入与所述事件ID对应消息数据中的消息标识。

本实施例所述方法，通过消息队列返回的确认消息补写对应事物对象中的消息标识字段，这样，通过所有事物对象中消息标识字段是否有数值就能够轻易的确定哪些本地事务对应的消息已经发送成功，或者发送失败或尚未接收到消息队列返回的对应的确认消息。

另一个实现中，保证消息数据一致性的方法还可以进一步包括：定时扫描存储事件对象的消息表，确定其中消息标志为空的事件对象；将与所述标志为空的事件对象所在的本地事务对应的第一消息重新发送。

通过扫描存储事件对象的消息表，就能够确定出对应消息没有发送成功的事物对象，或尚未收到消息队列返回确认消息的事物对象。因此可以控制重新发送标志为空的事件对象所在的本地事务对应的第一消息，确保消息队列中消息的及时更新。

前述实施例中，所述将所述业务对象和所述事件对象封装成一个本地事务并提交数据库，可以包括：将所述业务对象和所述事件对象封装称为一个本地事务；将所述业务对象的变更数据保存在业务表中；将所述事件对象对应的数据存储到本地消息表中。其中，首先将业务对象和事件对象封装称为一个本地事务，然后将业务对象的变更数据保存在业务表，同步的将事件对象对应的数据存储到本地消息表中。只有本地事务提交到数据库后，才可以触发后续的消息发送流程。其中，消息发送流程的具体实现可以是：调用消息队列的发送接口，将与所述本地事务对应的第一消息发送至消息队列。

本申请方案使用本地消息表来记录事件对象内容，不需要使用消息中间件，从而避免了使用消息中间件的复杂流程，能够有效保证数据库中的业务数据与消息数据的一致性。

图7为本申请实施例公开的保证消息数据一致性的架构实现示意图。参见图7所示，保证消息数据一致性的实现逻辑如下：

1、应用程序接收外部业务请求；

2、开启本地事务；

3、执行正常的业务逻辑，例如插入数据、更新数据、删除数据的写操作数据库的逻辑。将业务对象变更保存的业务表，即要将插入、更新、删除的对象保存到数据库表里；

4、构建事件对象，如上面第3步中数据插入成功，构建数据插入完成事件。数据更新完成，构建数据更新事件；数据删除成功，删除数据事件构建为事件对象。例如第3步中一个插入对象保存成功，则构建一个事件对象，构建事件对象包含业务对象的业务id(如订单号)、事件Id、事件类型(插入数据类型)、msgId(也即消息标识，置空，待后续更新)、事件构建的时间等。将构建的事件对象插入到本地消息表；

5、提交本地事务；

6、触发发送流程，调用MQ的发送接口，发送消息。如上图，当执行业务和构建事件逻步骤执行完毕后，调用MQ发送接口，触发发送逻辑，将消息发送到MQ，供下游业务方消费使用，MQ消息必须包含事件Id；

7、消息成功发送后，更新消息表的状态，并补写msgId。将第4步插入本地消息表的数据依据事件Id将msgId更新到本条事件消息，补全信息。

在上述方案基础上，保证消息数据一致性的方法还可以进一步实施补偿流程，补偿流程如下：

Timer周期性触发补偿逻辑。该流程独立与主流程执行，另外启动线程或是另外启动进程，定时执行，例如每1分钟执行一次，定时扫描本地消息表；

1、从消息表中加载未发送或发送失败的消息，查询出上面第7步未补写msgId的数据；

2、调用发送接口，将消息发送至MQ(与上面第6步相同逻辑)；

3、系统发送成功后，更新消息表的状态；(与第7步相同逻辑)。

本申请方案中，若本地事务提交失败，业务表和消息表的变更被回滚，不会触发发送逻辑；若本地事务提交成功，消息发送失败，后台定时器会进行自动补偿。

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

上述本发明公开的实施例中详细描述了方法，对于本发明的方法可采用多种形式的装置实现，因此本发明还公开了一种装置，下面给出具体的实施例进行详细说明。

图8为本申请实施例公开的保证消息数据一致性的装置结构示意图。参见图8所示，保证消息数据一致性的装置80可以包括：

请求获得模块801，用于获得业务请求并执行所述业务请求，所述业务请求包括业务对象。

对象构建模块802，用于在所述业务请求执行成功后，构建表征所述业务请求执行成功的事件对象。

数据提交模块803，用于将所述业务对象和所述事件对象封装成一个本地事务并提交数据库。

消息发送模块804，用于将与所述本地事务对应的第一消息发送至消息队列。

本实施例所述保证消息数据一致性的装置能够将与业务请求对应的业务对象和事件对象封装成一个本地事务，这样有效保证两者的同步处理，若本地事务提交成功，且第一消息发送成功，则变更数据可供其他业务正常使用；若本地事务提交失败，则对应业务请求的业务变更数据以及相应事件对象的变更数据将会统一被回滚，不会进一步触发第一消息的发送，从而严格保证数据库数据与消息数据的一致性。

一个实现中，所述事件对象中包括业务ID、事件ID、事件类型、构建时间和消息标识，其中，所述消息标识置空。

一个实现中，所述第一消息中包括事件ID，装置还可以包括：消息接收模块，用于接收所述消息队列返回的确认消息，所述确认消息表征所述消息队列接收到所述第一消息，所述确认消息中包括消息标识数据和事件ID；消息补充模块，用于将所述消息标识数据写入与所述事件ID对应消息数据中的消息标识。

一个实现中，还可以包括：消息扫描模块，用于定时扫描存储事件对象的消息表，确定其中消息标志为空的事件对象；所述消息发送模块还用于：将与所述标志为空的事件对象所在的本地事务对应的第一消息重新发送。

一个实现中，数据提交模块具体可用于：将所述业务对象和所述事件对象封装称为一个本地事务；将所述业务对象的变更数据保存在业务表中；将所述事件对象对应的数据存储到本地消息表中。

一个实现中，消息发送模块具体可用于：调用消息队列的发送接口，将与所述本地事务对应的第一消息发送至消息队列。

上述实施例中的所述的任意一种保证消息数据一致性的装置包括处理器和存储器，上述实施例中的请求获得模块、对象构建模块、数据提交模块、消息发送模块、消息接收模块、消息补充模块、消息扫描模块等均作为程序模块存储在存储器中，由处理器执行存储在所述存储器中的上述程序模块来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序模块。内核可以设置一个或多个，通过调整内核参数来实现回访数据的处理。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

在示例性实施例中，还提供了一种计算机可读存储介质，可直接加载到计算机的内部存储器，其中含有软件代码，该计算机程序经由计算机载入并执行后能够实现上述保证消息数据一致性的方法任一实施例所示步骤。

在示例性实施例中，还提供一种计算机程序产品，可直接加载到计算机的内部存储器，其中含有软件代码，该计算机程序经由计算机载入并执行后能够实现上述所述的保证消息数据一致性的方法任一实施例所示步骤。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。