CN111597197B - 数据库之间的数据对账方法和装置、存储介质及电子设备 - Google Patents

Abstract

本发明公开了一种数据库之间的数据对账方法和装置、存储介质及电子设备。其中，该方法包括：获取第一数据库的日志集合中的第一日志集合；获取第二数据库的日志集合中的第二日志集合；根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合；对第一数据集合和第二数据集合进行比对，得到目标比对结果；并根据目标比对结果对第一数据库或第二数据库中的数据进行更新，进而解决了现有技术中，无法实现在不间断业务数据的情况下对数据进行对账的技术问题。

Description

数据库之间的数据对账方法和装置、存储介质及电子设备

技术领域

本发明涉及计算机领域，具体而言，涉及一种数据库之间的数据对账方法和装置、存储介质及电子设备。

背景技术

随着互联网正成为国民生活和经济运转的基础设施，互联网服务的可用性变得越来越重要。而数据的可靠性正是互联网服务运转的重中之重。因此，通过消息队列实现跨地域容灾，变成了很多互联网服务的高可用方案。

虽然消息队列具有消费确认、持久化和多分片等多种可靠性机制，从整个方案实现看，仅靠它无法保证两端数据的一致性，原因如下：

异步的消息写入方式，不保证每个业务事件都能传递：消息***往往会跨地域部署，要提升消息的可靠性，需要进行跨区域的副本同步。如果业务采用了消息队列同步写入的方案，则会大大降低业务的处理性能。因此，业务采用异步投递消息的模式。

消息队列作为中间站，消息都会过期：消息队列作为消息中转站，存在一定的存储规格，因此不可能无限量地保存所有历史消息。当前会按照存储容量和消息期限来进行清理。因此当某个区域与消息队列断联时，无法及时消费到过期的事件。

同步后的业务数据可能丢失：业务***升级或者本地的存储***故障时，存在丢失数据的风险。

当前的对账方案会高度融入和依赖业务***，当发起对账时，会阻塞，甚至争抢业务资源(如内存，线程)影响正常业务处理。当数据修复时，有可能过时的对账结果会覆盖更新的业务数据，造成数据错误。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种数据库之间的数据对账方法和装置、存储介质及电子设备，以至少解决现有技术中，无法实现在不间断业务数据的情况下对数据进行对账的技术问题。

根据本发明实施例的一个方面，提供了一种数据库之间的数据对账方法，包括：获取第一数据库的日志集合中的第一日志集合，其中，所述第一日志集合中的每个日志具有对应的日志序列号，所述第一日志集合中的每个日志包括对所述第一数据库中的数据进行修改的记录；获取第二数据库的日志集合中的第二日志集合，其中，所述第二数据库用于从所述第一数据库中同步数据，所述第二日志集合中的每个日志具有对应的日志序列号，所述第二日志集合中的每个日志包括对所述第二数据库中的数据进行修改的记录，所述第二日志集合中的日志对应的日志序列号与所述第一日志集合中的日志对应的日志序列号相同；根据所述第一日志集合获取所述第一数据库在目标状态下的第一数据集合，根据所述第二日志集合获取所述第二数据库在所述目标状态下的第二数据集合；对所述第一数据集合和所述第二数据集合进行比对，得到目标比对结果；在所述目标比对结果表示所述第一数据集合和所述第二数据集合不相同的情况下，根据所述目标比对结果对所述第一数据库或所述第二数据库中的数据进行更新。

根据本发明实施例的另一方面，还提供了一种数据库之间的数据对账装置，包括：第一获取单元，用于获取第一数据库的日志集合中的第一日志集合，其中，所述第一日志集合中的每个日志具有对应的日志序列号，所述第一日志集合中的每个日志包括对所述第一数据库中的数据进行修改的记录；第二获取单元，用于获取第二数据库的日志集合中的第二日志集合，其中，所述第二数据库用于从所述第一数据库中同步数据，所述第二日志集合中的每个日志具有对应的日志序列号，所述第二日志集合中的每个日志包括对所述第二数据库中的数据进行修改的记录，所述第二日志集合中的日志对应的日志序列号与所述第一日志集合中的日志对应的日志序列号相同；第三获取单元，用于根据所述第一日志集合获取所述第一数据库在目标状态下的第一数据集合，根据所述第二日志集合获取所述第二数据库在所述目标状态下的第二数据集合；对比单元，用于对所述第一数据集合和所述第二数据集合进行比对，得到目标比对结果；更新单元，用于在所述目标比对结果表示所述第一数据集合和所述第二数据集合不相同的情况下，根据所述目标比对结果对所述第一数据库或所述第二数据库中的数据进行更新。

根据本发明实施例的又一方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的数据库之间的数据对账方法。

根据本发明实施例的又一方面，还提供了一种电子设备，包括存储器和处理器，上述存储器中存储有计算机程序，上述处理器被设置为通过所述计算机程序执行上述的数据库之间的数据对账方法。

在本发明实施例中，通过获取第一数据库的日志集合中的第一日志集合，其中，第一日志集合中的每个日志具有对应的日志序列号，第一日志集合中的每个日志包括对第一数据库中的数据进行修改的记录；获取第二数据库的日志集合中的第二日志集合，其中，第二数据库用于从第一数据库中同步数据，第二日志集合中的每个日志具有对应的日志序列号，第二日志集合中的每个日志包括对第二数据库中的数据进行修改的记录，第二日志集合中的日志对应的日志序列号与第一日志集合中的日志对应的日志序列号相同；根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合；对第一数据集合和第二数据集合进行比对，得到目标比对结果；在目标比对结果表示第一数据集合和第二数据集合不相同的情况下，根据目标比对结果对第一数据库或第二数据库中的数据进行更新，达到了获取目标状态下的第一数据集合和第二数据集合，对第一数据集合和第二数据集合进行比对，并对数据进行更新的目的，从而实现了不间断的数据同步的技术效果，进而解决了现有技术中，无法实现在不间断业务数据的情况下对数据进行对账的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种可选的数据库之间的数据对账方法的应用环境的示意图；

图2是根据本发明实施例的一种可选的数据库之间的数据对账方法的流程图；

图3是根据本发明实施例的一种可选的对账子***的交互界面；

图4是根据本发明实施例的一种可选的基于MVCC机制的数据对账和修复方法的流程图；

图5是根据本发明实施例的一种可选的基于数据版本号的RSM同步模型示意图；

图6是根据本发明实施例的一种可选的基于MVCC的快照生成流程图；

图7是根据本发明实施例的一种可选的两端快照对比流程图图；

图8是根据本发明实施例的一种可选的数据库之间的数据对账装置的结构示意图；

图9是根据本发明实施例的一种可选的数据库之间的数据对账方法的电子设备的结构示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了更好的理解本申请提供的实施例，现部分名词说明如下：

VTIX，Virtual Tencent Internet Exchange，腾讯虚拟公网交换平台。

MVCC，Multi-Version Concurrency Control，多协议版本并发控制。

MQ，Message Queue，消息队列。

RSM，Replicated Sate Machine，复制状态机。

COW，Copy On Write，写时复制。

大数据(Big data)是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。随着云时代的来临，大数据也吸引了越来越多的关注，大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理数据库、数据挖掘、分布式文件***、分布式数据库、云计算平台、互联网和可扩展的存储***。

根据本发明实施例的一个方面，提供了一种数据库之间的数据对账方法，可选地，作为一种可选的实施方式，上述数据库之间的数据对账方法可以但不限于应用于如图1所示的环境中。

服务器112包括：数据库114和处理引擎116，第一业务***102，第一业务***对应的第一数据库104，第二业务***106，第二业务***对应的第二数据库106，服务器112执行步骤S102-S110，获取第一数据库的日志集合中的第一日志集合，其中，第一日志集合中的每个日志具有对应的日志序列号，第一日志集合中的每个日志包括对第一数据库中的数据进行修改的记录；获取第二数据库的日志集合中的第二日志集合，其中，第二数据库用于从第一数据库中同步数据，第二日志集合中的每个日志具有对应的日志序列号，第二日志集合中的每个日志包括对第二数据库中的数据进行修改的记录，第二日志集合中的日志对应的日志序列号与第一日志集合中的日志对应的日志序列号相同；根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合；对第一数据集合和第二数据集合进行比对，得到目标比对结果；在目标比对结果表示第一数据集合和第二数据集合不相同的情况下，根据目标比对结果对第一数据库或第二数据库中的数据进行更新，达到了获取目标状态下的第一数据集合和第二数据集合，对第一数据集合和第二数据集合进行比对，并对数据进行更新的目的，从而实现了不间断的数据同步的技术效果，进而解决了现有技术中，无法实现在不间断业务数据的情况下对数据进行对账的技术问题。

可选的，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

可选地，作为一种可选的实施方式，如图2所示，上述数据库之间的数据对账方法包括：

步骤S202，获取第一数据库的日志集合中的第一日志集合，其中，第一日志集合中的每个日志具有对应的日志序列号，第一日志集合中的每个日志包括对第一数据库中的数据进行修改的记录。

步骤S204，获取第二数据库的日志集合中的第二日志集合，其中，第二数据库用于从第一数据库中同步数据，第二日志集合中的每个日志具有对应的日志序列号，第二日志集合中的每个日志包括对第二数据库中的数据进行修改的记录，第二日志集合中的日志对应的日志序列号与第一日志集合中的日志对应的日志序列号相同。

步骤S206，根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合。

步骤S208，对第一数据集合和第二数据集合进行比对，得到目标比对结果。

步骤S210，在目标比对结果表示第一数据集合和第二数据集合不相同的情况下，根据目标比对结果对第一数据库或第二数据库中的数据进行更新。

可选的，在本实施例中，上述第一数据库的数据可以包括但不限于动态更新的数据库，上述第二数据库可以包括但不限于动态更新的数据库。

可选的，本实施例中的方案可以基于消息队列实现跨地域数据同步，两端数据的对账和修复问题。例如，该方案可以应用到腾讯网络平台部的VTIX(虚拟腾讯出口流量调度)项目中。在VTIX项目中，需要通过消息队列完成跨地域的路由信息同步。通过基于本实施例中的方案的对账***，最终实现多地数据的最终一致性。图3为对账子***的交互界面。

通过图3所示的对账***，管理员或者后台定时可以发起对所有区域的数据审计和修复，并看到每次对账结果的差异信息及修复结果。

可选的，在本实施例中，在获取第一数据库的日志集合中的第一日志集合之后，还可以包括：根据第一日志集合中的日志对应的日志序列号，生成第一版本号，其中，第一版本号用于标识第一日志集合中的日志对应的日志序列号；

获取第二数据库的日志集合中的第二日志集合，包括：根据第一版本号，在第二数据库的日志集合中获取第二日志集合。

其中，根据第一日志集合中的日志对应的日志序列号，生成第一版本号，可以包括：

将第一日志集合中的日志对应的日志序列号中的最大序列号，确定为第一版本号。

其中，根据第一版本号，在第二数据库的日志集合中获取第二日志集合，可以包括：

在第一版本号为第一日志集合中的日志对应的日志序列号中的最大序列号的情况下，在第二数据库的日志集合中获取初始序列号到最大序列号的日志，得到第二日志集合。

需要说明的是，日志集合中的每个日志都对应一个编号，每个日志对应一个事件，将每个事件写入消息队列。

可选的，在本实施例中，获取第一数据库的日志集合中的第一日志集合，可以包括：

在第一数据库的日志集合中获取初始序列号到目标序列号的日志，得到第一日志集合，其中，目标序列号为第一日志集合中的日志对应的日志序列号中的最大序列号。

可选的，在本实施例中，在获取第一数据库的日志集合中的第一日志集合之后，方法还包括：在消息队列中将目标序列号对应的对账消息***到第一消息之后，其中，消息队列中的消息用于被第二数据库的业务***按顺序处理，目标序列号为第一日志集合中的日志对应的日志序列号中的最大序列号，第一消息用于表示第二数据库中目标序列号的日志；

获取第二数据库的日志集合中的第二日志集合，包括：在业务***从消息队列中获取到对账消息的情况下，获取第二数据库的日志集合中的第二日志集合，其中，对账消息被业务***获取，表示业务***已对第二数据库处理完目标序列号的日志。

可选的，在本实施例中，根据目标比对结果对第一数据库或第二数据库中的数据进行更新，可以以包括：

在目标比对结果表示需要将第一数据库或第二数据库中的目标数据项的取值(key1，value1，versionN1)修改为(key1,value2,versionN2)、且目标数据项在第一数据库或第二数据库中的最新取值为(key1,value2,versionN3)的情况下，将目标数据项的取值修改为(key1,value2,versionN3)，其中，versionN1，versionN2，versionN3表示版本号，versionN1<versionN2<versionN3。

在实际应用中，当对账***得到差异集后，还有个挑战：如何在不间断的数据同步中，安全地修复数据。数据在变化，可能之前的对账结果，是过时的。如果这时候拿过时的对账结果，覆盖了更新版本的数据，就会造成数据错误。比如在version100的快照对账中，发现需要把(key1，value1，version8)的数据修改为(key1，value2，version88)。但此时数据库中已经写入(key1，value2，version111)的数据，那此时version88的修复就是过时的。

其中，快照是某个状态下的全量数据，状态由全量数据最大的版本号标识。

在执行数据库更新操作时，只修订错误版本号的数据，即(update value1 wherekey＝key1 and version＝fix-version)。基于MVCC思想的实现，保证了不会去更新更高版本的数据。最后达到了不阻塞业务的前提下，也可以安全可靠地修复数据。

通过本申请提供的实施例，获取第一数据库的日志集合中的第一日志集合，其中，第一日志集合中的每个日志具有对应的日志序列号，第一日志集合中的每个日志包括对第一数据库中的数据进行修改的记录；获取第二数据库的日志集合中的第二日志集合，其中，第二数据库用于从第一数据库中同步数据，第二日志集合中的每个日志具有对应的日志序列号，第二日志集合中的每个日志包括对第二数据库中的数据进行修改的记录，第二日志集合中的日志对应的日志序列号与第一日志集合中的日志对应的日志序列号相同；根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合；对第一数据集合和第二数据集合进行比对，得到目标比对结果；在目标比对结果表示第一数据集合和第二数据集合不相同的情况下，根据目标比对结果对第一数据库或第二数据库中的数据进行更新，达到了获取目标状态下的第一数据集合和第二数据集合，对第一数据集合和第二数据集合进行比对，并对数据进行更新的目的，从而实现了不间断的数据同步的技术效果，进而解决了现有技术中，无法实现在不间断业务数据的情况下对数据进行对账的技术问题。

作为一种可选的实施例，本申请还提供了一种可选的基于MVCC机制的数据对账和修复方法。如图4所示，一种基于MVCC机制的数据对账和修复方法的流程图。具体方案实现如下：

1，增加数据版本号，将消息队列同步转化为RSM模型

无阻塞的对账，就是在源源不断的数据修改中，去发现存量数据中存在的问题。两边的数据集就是一直在变。只有将它们固定在同一个状态比较，结果才是可信的。那怎么去定义两端的同一状态，两个数据集的纽带就是消息队列里的事件，所以队列里的业务事件就是这两个数据集的变量。通过消息队列实现两端同步，基于RSM(Replicated StateMachine，复制状态机)：如果每个节点都执行同一序列的数据操作，它们最终的状态就是一致的。消息队列中的每个业务事件就是RSM中的Replicated Log，要比较的数据集就是同一状态下的状态机。当处理完同一个业务事件后，则双方的数据集应是一致的。

在本实施例中，业务对账的问题抽象成：RSM模型下，源、目双方处理同一个事件序列后的状态机比较。如图5所示，基于数据版本号的RSM同步模型示意图。

2，基于MVCC的snapshot生成技术

在不间断的数据修改中，怎么获取某个状态的数据呢，这就是数据库中的快照生成技术。在数据库中，为了整理日志文件或者容灾备份，需要定期把数据库log日志(每一个数据变更就是个log日志)压成snapshot文件。

其中，日志是消息队列中的事件，每个日志都有版本号，数据是处理完日志事件后得到的数据，并且以日志的版本号标识。

现有的snapshot生成方式就是阻塞所有的数据操作，在一个稳定的状态下，执行log生成snapshot。但是数据量大，阻塞时间长，对业务影响大。显然这不符合我们的场景。悲观锁不行，尝试乐观锁方案。有两种实现方案：一个是Redis的CopyOnWrite，当需要生成快照文件时，一个子进程共享父进程的内存数据。这样的方式适合读多写少的场景，不适合数据频繁更新的***。还有一个缺陷，需要膨胀出来的一倍内存空间。退一步说，即使我们资源够多，允许内存膨胀，但审计***是独立于业务***，不能感知到业务***的业务处理，就没法做写时复制。

而在本实施例中，采用的MVCC(Multi-version concurrency control多协议版本并发控制)机制：把某一状态的snapshot看成一个数据，不同状态下的snapshot就是不同版本的数据。而snapshot版本根据快照里的最新日志序号来定义。因此要生成特定版本的snapshot，根据每条日志的序列号(小于等于snapshot-index)来就可以决定哪些日志可以执行到snapshot。把快照准确定义成成某一个版本下的快照后，就可以按照版本号精准地去提取和筛选信息。如图6所示，基于MVCC的快照生成流程图。

这样的模式适合对账和业务***独立的场景。源区域端先从数据库中读出所有的数据，此时就可以得到源端的snapshot及相应的版本号。拿着这个版本号，就可以从目的区域数据库从不断变化的数据集中筛选和过滤数据。所以业务对账就等价于同一版本的snapshot比对。如图7所示，两端快照对比流程图。

3，基于MVCC机制的安全修复

当对账***得到差异集后，还有个挑战：如何在不间断的数据同步中，安全地修复数据。数据在变化，可能之前的对账结果，是过时的。如果这时候拿过时的对账结果，覆盖了更新版本的数据，就会造成数据错误。比如在version100的快照对账中，发现需要把(key1，value1，version8)的数据修改为(key1，value2，version88)。但此时数据库中已经写入(key1，value2，version111)的数据，那此时version88的修复就是过时的。

在执行数据库更新操作时，只修订错误版本号的数据，即(update value1 wherekey＝key1 and version＝fix-version)。这是个基于MVCC思想的实现,保证了不会去更新更高版本的数据。最后达到了不阻塞业务的前提下，也可以安全可靠地修复数据。

4，借助消息队列高效判断同步状态

按照上述思路，业务的存储模型中增加了序号。当发起审计后，由源区域读取本地的数据库，生成源数据集，并从数据集中筛选得到最大的业务序号max-index。同样也需要在目的区域中筛选得到数据集dest-snapshot。因此目的区域至少已经处理到max-index的业务事件，才可能在目的区域数据库中筛选得到max-index的快照。

由于目的区域是从源区域同步数据，所以它的数据状态是滞后的，那旁挂的对账***如何确定当前的业务***已经消费的事件进度呢，最简单就是，对账***不断地去查询所有的业务信息，筛选它的最大序号，如果大于等于max-index，则说明可以去生成目标snapshot了。但业务规格是亿级的，那每次的全量查询都是非常耗时，所以效率不高。或者业务***每消费一个消息，都去把版本号刷入数据库。但是这样就使得所有的业务消费都多了个更新数据库序号的操作。为了低频的对账任务，带来这样的业务性能损耗也不明智。所以需要一个为了对账任务而生的标识，这样的标识能告诉我们当前的数据库已经消费到了某个状态。

消息队列的先进先出特性为对账***提供了消费的进度状态。源区域在生成max-index的snapshot后，Kafka上已经写入了max-index的业务事件，此时再主动往Kafka写入一个checkpoint消息。当目的区域收到这个checkpoint后，意味着它已消费过max-index的业务事件，此时主动往数据库中更新checkpoint标识。此时目的区域的对账模块读取数据库，得到当前的数据集dest-snapshot。该数据集消费的业务序号大于等于max-index，因此在dest-snapshot中剔除序号大于max-index的。这样src-snapshot和dest-snapshot都是消费[0，max-index]事件序列的数据集，并可以进行比较。

在本实施例中，在通过消息队列同步数据的***中，实现不阻塞业务，可独立部署且安全可靠的数据对账和修复目标。为此，本实施例的方案中需要：1)业务数据增加版本号，将基于消息队列同步的***转化基于事件序列同步的RSM模型。通过记录业务数据的最新事件序列号，从而达到源、目两端可量化比较的状态；2)通过数据库生成快照的MVCC乐观锁方案，在不阻塞业务同步的前提下，两端生成同一状态的快照数据；3)借助队列先进先出的机制，通过在消息队列写入特定的检测点checkpoint事件，量化了两端数据的同步状态；4)基于MVCC在不阻塞业务同步的情况下，完成数据安全可靠的修复。

在本实施例中，为了做数据容灾和区域数据共享，基于消息队列的数据同步广泛应用于互联网后台项目中。提出了一个业务无阻塞的数据对账和修复方案，并且对业务***无感知，很容易成为一套独立于业务的通用对账***。在保证实现数据对账和安全修复的目标下，可应用于不同业务场景。

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

根据本发明实施例的另一个方面，还提供了一种用于实施上述数据库之间的数据对账方法的数据库之间的数据对账装置。如图8所示，该装置包括：第一获取单元81、第二获取单元83、第三获取单元85、对比单元87以及更新单元89。

第一获取单元81，用于获取第一数据库的日志集合中的第一日志集合，其中，第一日志集合中的每个日志具有对应的日志序列号，第一日志集合中的每个日志包括对第一数据库中的数据进行修改的记录；

第二获取单元83，用于获取第二数据库的日志集合中的第二日志集合，其中，第二数据库用于从第一数据库中同步数据，第二日志集合中的每个日志具有对应的日志序列号，第二日志集合中的每个日志包括对第二数据库中的数据进行修改的记录，第二日志集合中的日志对应的日志序列号与第一日志集合中的日志对应的日志序列号相同；

第三获取单元85，用于根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合；

对比单元87，用于对第一数据集合和第二数据集合进行比对，得到目标比对结果；

更新单元89，用于在目标比对结果表示第一数据集合和第二数据集合不相同的情况下，根据目标比对结果对第一数据库或第二数据库中的数据进行更新。

可选的，在本实施例中，上述更新单元89，可以包括：

修改模块，用于在目标比对结果表示需要将第一数据库或第二数据库中的目标数据项的取值(key1，value1，versionN1)修改为(key1,value2,versionN2)、且目标数据项在第一数据库或第二数据库中的最新取值为(key1,value2,versionN3)的情况下，将目标数据项的取值修改为(key1,value2,versionN3)，其中，versionN1，versionN2，versionN3表示版本号，versionN1<versionN2<versionN3。

通过本申请提供的实施例，第一获取单元81获取第一数据库的日志集合中的第一日志集合，其中，第一日志集合中的每个日志具有对应的日志序列号，第一日志集合中的每个日志包括对第一数据库中的数据进行修改的记录；第二获取单元83获取第二数据库的日志集合中的第二日志集合，其中，第二数据库用于从第一数据库中同步数据，第二日志集合中的每个日志具有对应的日志序列号，第二日志集合中的每个日志包括对第二数据库中的数据进行修改的记录，第二日志集合中的日志对应的日志序列号与第一日志集合中的日志对应的日志序列号相同；第三获取单元85根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合；对比单元87对第一数据集合和第二数据集合进行比对，得到目标比对结果；更新单元89，在目标比对结果表示第一数据集合和第二数据集合不相同的情况下，根据目标比对结果对第一数据库或第二数据库中的数据进行更新。达到了获取目标状态下的第一数据集合和第二数据集合，对第一数据集合和第二数据集合进行比对，并对数据进行更新的目的，从而实现了不间断的数据同步的技术效果，进而解决了现有技术中，无法实现在不间断业务数据的情况下对数据进行对账的技术问题。

作为一种可选的实施例，上述装置可以包括：生成单元，用于在获取第一数据库的日志集合中的第一日志集合之后，根据第一日志集合中的日志对应的日志序列号，生成第一版本号，其中，第一版本号用于标识第一日志集合中的日志对应的日志序列号；

第二获取单元83可以包括：第一获取模块，用于根据第一版本号，在第二数据库的日志集合中获取第二日志集合。

可选的，在本实施例中，上述生成单元，可以包括：

确定模块，用于将第一日志集合中的日志对应的日志序列号中的最大序列号，确定为第一版本号。

其中，上述第一获取模块，可以包括：

获取子模块，用于在第一版本号为第一日志集合中的日志对应的日志序列号中的最大序列号的情况下，在第二数据库的日志集合中获取初始序列号到最大序列号的日志，得到第二日志集合。

可选的，在本实施例中，上述第一获取单元81，可以包括：

第二获取模块，用于在第一数据库的日志集合中获取初始序列号到目标序列号的日志，得到第一日志集合，其中，目标序列号为第一日志集合中的日志对应的日志序列号中的最大序列号。

作为一种可选的实施例，上述装置可以包括：

***单元，用于在获取第一数据库的日志集合中的第一日志集合之后，在消息队列中将目标序列号对应的对账消息***到第一消息之后，其中，消息队列中的消息用于被第二数据库的业务***按顺序处理，目标序列号为第一日志集合中的日志对应的日志序列号中的最大序列号，第一消息用于表示第二数据库中目标序列号的日志；

第二获取单元83可以包括：第三获取模块，用于在业务***从消息队列中获取到对账消息的情况下，获取第二数据库的日志集合中的第二日志集合，其中，对账消息被业务***获取，表示业务***已对第二数据库处理完目标序列号的日志。

根据本发明实施例的又一个方面，还提供了一种用于实施上述数据库之间的数据对账方法的电子设备，该电子设备可以是图1所示的终端设备或服务器。本实施例以该电子设备为服务器为例来说明。如图9所示，该电子设备包括存储器902和处理器904，该存储器902中存储有计算机程序，该处理器904被设置为通过计算机程序执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述电子设备可以位于计算机网络的多个网络设备中的至少一个网络设备。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，获取第一数据库的日志集合中的第一日志集合，其中，第一日志集合中的每个日志具有对应的日志序列号，第一日志集合中的每个日志包括对第一数据库中的数据进行修改的记录；

S2，获取第二数据库的日志集合中的第二日志集合，其中，第二数据库用于从第一数据库中同步数据，第二日志集合中的每个日志具有对应的日志序列号，第二日志集合中的每个日志包括对第二数据库中的数据进行修改的记录，第二日志集合中的日志对应的日志序列号与第一日志集合中的日志对应的日志序列号相同；

S3，根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合；

S4，对第一数据集合和第二数据集合进行比对，得到目标比对结果；

S5，在目标比对结果表示第一数据集合和第二数据集合不相同的情况下，根据目标比对结果对第一数据库或第二数据库中的数据进行更新。

可选地，本领域普通技术人员可以理解，图9所示的结构仅为示意，电子装置电子设备也可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile Internet Devices，MID)、PAD等终端设备。图9其并不对上述电子装置电子设备的结构造成限定。例如，电子装置电子设备还可包括比图9中所示更多或者更少的组件(如网络接口等)，或者具有与图9所示不同的配置。

其中，存储器902可用于存储软件程序以及模块，如本发明实施例中的数据库之间的数据对账方法和装置对应的程序指令/模块，处理器904通过运行存储在存储器902内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的数据库之间的数据对账方法。存储器902可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器902可进一步包括相对于处理器904远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。其中，存储器902具体可以但不限于用于第一数据集合和第二数据集合等信息。作为一种示例，如图9所示，上述存储器902中可以但不限于包括上述数据库之间的数据对账装置中的第一获取单元81、第二获取单元83、第三获取单元85、对比单元87以及更新单元89。此外，还可以包括但不限于上述数据库之间的数据对账装置中的其他模块单元，本示例中不再赘述。

可选地，上述的传输装置906用于经由一个网络接收或者发送数据。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置906包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置906为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

此外，上述电子设备还包括：显示器908，用于显示上述待处理更新的数据；和连接总线910，用于连接上述电子设备中的各个模块部件。

在其他实施例中，上述终端设备或者服务器可以是一个分布式***中的一个节点，其中，该分布式***可以为区块链***，该区块链***可以是由该多个节点通过网络通信的形式连接形成的分布式***。其中，节点之间可以组成点对点(P2P，Peer To Peer)网络，任意形式的计算设备，比如服务器、终端等电子设备都可以通过加入该点对点网络而成为该区块链***中的一个节点。

根据本发明的实施例的又一方面，还提供了一种计算机可读的存储介质，该计算机可读的存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述计算机可读的存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1，获取第一数据库的日志集合中的第一日志集合，其中，第一日志集合中的每个日志具有对应的日志序列号，第一日志集合中的每个日志包括对第一数据库中的数据进行修改的记录；

S2，获取第二数据库的日志集合中的第二日志集合，其中，第二数据库用于从第一数据库中同步数据，第二日志集合中的每个日志具有对应的日志序列号，第二日志集合中的每个日志包括对第二数据库中的数据进行修改的记录，第二日志集合中的日志对应的日志序列号与第一日志集合中的日志对应的日志序列号相同；

S3，根据第一日志集合获取第一数据库在目标状态下的第一数据集合，根据第二日志集合获取第二数据库在目标状态下的第二数据集合；

S4，对第一数据集合和第二数据集合进行比对，得到目标比对结果；

S5，在目标比对结果表示第一数据集合和第二数据集合不相同的情况下，根据目标比对结果对第一数据库或第二数据库中的数据进行更新。

可选地，在本实施例中，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random Access Memory，RAM)、磁盘或光盘等。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

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

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (15)

1.一种数据库之间的数据对账方法，其特征在于，包括：

获取第一数据库的日志集合中的第一日志集合，其中，所述第一日志集合中的每个日志具有对应的日志序列号，所述第一日志集合中的每个日志包括对所述第一数据库中的数据进行修改的记录；

获取第二数据库的日志集合中的第二日志集合，其中，所述第二数据库用于从所述第一数据库中同步数据，所述第二日志集合中的每个日志具有对应的日志序列号，所述第二日志集合中的每个日志包括对所述第二数据库中的数据进行修改的记录，所述第二日志集合中的日志对应的日志序列号与所述第一日志集合中的日志对应的日志序列号相同；

获取所述第一数据库在执行消息队列中的业务事件后得到的与所述第一日志集合对应的第一数据集合，以及所述第二数据库在执行所述消息队列中的业务事件后得到的与所述第二日志集合对应的第二数据集合，其中，所述第一数据集合中包括不同版本的第一快照数据，所述第二数据集合中包括不同版本的第二快照数据；

对所述第一数据集合和所述第二数据集合中属于同一版本的快照数据进行比对，得到目标比对结果；

在所述目标比对结果表示所述第一数据集合和所述第二数据集合中属于同一版本的快照数据不相同的情况下，根据所述目标比对结果对所述第一数据库或所述第二数据库中错误版本号的数据更新，其中，所述同一版本的版本号为所述错误版本号。

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

在所述获取第一数据库的日志集合中的第一日志集合之后，所述方法还包括：根据所述第一日志集合中的日志对应的日志序列号，生成第一版本号，其中，所述第一版本号用于标识所述第一日志集合中的日志对应的日志序列号；

所述获取第二数据库的日志集合中的第二日志集合，包括：根据所述第一版本号，在所述第二数据库的日志集合中获取所述第二日志集合。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第一日志集合中的日志对应的日志序列号，生成第一版本号，包括：

将所述第一日志集合中的日志对应的日志序列号中的最大序列号，确定为所述第一版本号。

4.根据权利要求2所述的方法，其特征在于，所述根据所述第一版本号，在所述第二数据库的日志集合中获取所述第二日志集合，包括：

在所述第一版本号为所述第一日志集合中的日志对应的日志序列号中的最大序列号的情况下，在所述第二数据库的日志集合中获取初始序列号到所述最大序列号的日志，得到所述第二日志集合。

5.根据权利要求1所述的方法，其特征在于，所述获取第一数据库的日志集合中的第一日志集合，包括：

在所述第一数据库的日志集合中获取初始序列号到目标序列号的日志，得到所述第一日志集合，其中，所述目标序列号为所述第一日志集合中的日志对应的日志序列号中的最大序列号。

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

在获取第一数据库的日志集合中的第一日志集合之后，所述方法还包括：在消息队列中将目标序列号对应的对账消息***到第一消息之后，其中，所述消息队列中的消息用于被所述第二数据库的业务***按顺序处理，所述目标序列号为所述第一日志集合中的日志对应的日志序列号中的最大序列号，所述第一消息用于表示所述第二数据库中所述目标序列号的日志；

所述获取第二数据库的日志集合中的第二日志集合，包括：在所述业务***从所述消息队列中获取到所述对账消息的情况下，获取第二数据库的日志集合中的第二日志集合，其中，所述对账消息被所述业务***获取，表示所述业务***已对所述第二数据库处理完所述目标序列号的日志。

7.根据权利要求1所述的方法，其特征在于，所述根据所述目标比对结果对所述第一数据库或所述第二数据库中的数据进行更新，包括：

在所述目标比对结果表示需要将所述第一数据库或所述第二数据库中的目标数据项的取值(key1，value1，versionN1)修改为(key1,value2,versionN2)、且所述目标数据项在所述第一数据库或所述第二数据库中的最新取值为(key1,value2,versionN3)的情况下，将所述目标数据项的取值修改为(key1,value2,versionN3)，其中，所述versionN1，versionN2，versionN3表示版本号，versionN1<versionN2<versionN3。

8.一种数据库之间的数据对账装置，其特征在于，包括：

第一获取单元，用于获取第一数据库的日志集合中的第一日志集合，其中，所述第一日志集合中的每个日志具有对应的日志序列号，所述第一日志集合中的每个日志包括对所述第一数据库中的数据进行修改的记录；

第二获取单元，用于获取第二数据库的日志集合中的第二日志集合，其中，所述第二数据库用于从所述第一数据库中同步数据，所述第二日志集合中的每个日志具有对应的日志序列号，所述第二日志集合中的每个日志包括对所述第二数据库中的数据进行修改的记录，所述第二日志集合中的日志对应的日志序列号与所述第一日志集合中的日志对应的日志序列号相同；

第三获取单元，用于获取所述第一数据库在执行消息队列中的业务事件后得到的与所述第一日志集合对应的第一数据集合，以及所述第二数据库在执行所述消息队列中的业务事件后得到的与所述第二日志集合对应的第二数据集合，其中，所述第一数据集合中包括不同版本的第一快照数据，所述第二数据集合中包括不同版本的第二快照数据；

对比单元，用于对所述第一数据集合和所述第二数据集合中属于同一版本的快照数据进行比对，得到目标比对结果；

更新单元，用于在所述目标比对结果表示所述第一数据集合和所述第二数据集合中属于同一版本的快照数据不相同的情况下，根据所述目标比对结果对所述第一数据库或所述第二数据库中错误版本号的数据进行更新，其中，所述同一版本的版本号为所述错误版本号。

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

生成单元，用于在所述获取第一数据库的日志集合中的第一日志集合之后，根据所述第一日志集合中的日志对应的日志序列号，生成第一版本号，其中，所述第一版本号用于标识所述第一日志集合中的日志对应的日志序列号；

所述第二获取单元包括：第一获取模块，用于根据所述第一版本号，在所述第二数据库的日志集合中获取所述第二日志集合。

10.根据权利要求9所述的装置，其特征在于，所述生成单元，包括：

确定模块，用于将所述第一日志集合中的日志对应的日志序列号中的最大序列号，确定为所述第一版本号。

11.根据权利要求9所述的装置，其特征在于，所述第一获取模块，包括：

获取子模块，用于在所述第一版本号为所述第一日志集合中的日志对应的日志序列号中的最大序列号的情况下，在所述第二数据库的日志集合中获取初始序列号到所述最大序列号的日志，得到所述第二日志集合。

12.根据权利要求8所述的装置，其特征在于，所述第一获取单元，包括：

第二获取模块，用于在所述第一数据库的日志集合中获取初始序列号到目标序列号的日志，得到所述第一日志集合，其中，所述目标序列号为所述第一日志集合中的日志对应的日志序列号中的最大序列号。

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

***单元，用于在获取第一数据库的日志集合中的第一日志集合之后，在消息队列中将目标序列号对应的对账消息***到第一消息之后，其中，所述消息队列中的消息用于被所述第二数据库的业务***按顺序处理，所述目标序列号为所述第一日志集合中的日志对应的日志序列号中的最大序列号，所述第一消息用于表示所述第二数据库中所述目标序列号的日志；

所述第二获取单元包括：第三获取模块，用于在所述业务***从所述消息队列中获取到所述对账消息的情况下，获取第二数据库的日志集合中的第二日志集合，其中，所述对账消息被所述业务***获取，表示所述业务***已对所述第二数据库处理完所述目标序列号的日志。

14.一种计算机可读的存储介质，其特征在于，所述计算机可读的存储介质包括存储的程序，其中，所述程序运行时执行所述权利要求1至7任一项中所述的方法。

15.一种电子设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行所述权利要求1至7任一项中所述的方法。

Images