CN115033578A - 一种业务数据更新的方法、相关装置及存储介质 - Google Patents

Abstract

本申请实施例提供了一种基于云数据库技术实现的业务数据更新的方法、相关装置及存储介质。目标节点可以获取业务节点中第一业务数据对应的第一时刻至第二时刻的快照数据，获取业务节点第一时刻至第三时刻的操作日志，其中，第三时刻为出现在第二时刻之后的一个时刻。然后目标节点可以根据操作日志生成日志数据，并根据该日志数据以及快照数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。通过上述方式，在业务节点创建快照的过程中，当已完成扫描的部分数据发生变更时，由于操作日志准确地记录了数据的实时变化，因此目标节点可以利用操作日志对接收到的快照数据进行更新，从而提高数据同步的准确性和完整性。

Description

一种业务数据更新的方法、相关装置及存储介质

技术领域

本申请实施例涉及云数据库技术领域，尤其涉及一种业务数据更新的方法、相关装置及存储介质。

背景技术

随着互联网的快速发展，数据的体量巨大且更新频繁。对于性能有限的业务数据库(如Mysql)，可能没办法很好地执行复杂程度较高且计算量较大的任务。一般来说，可以通过数据入库的方式，将业务数据库中的数据，同步到更稳定、存储量更大且计算能力更强的数据仓库中进行保存。

在现有的数据入库的过程中，可以通过快照，遍历扫描业务数据库中所需要复制的数据，然后将扫描得到的数据复制到数据仓库。

由于数据的快照需要一定的时间，而业务数据是时刻发生变更的。因此，在创建快照的过程中，若已完成扫描的部分数据发生变更，则无法获取到变更后的数据，导致数据入库的准确性和完整性较低。

发明内容

本申请实施例提供了一种业务数据更新的方法、相关装置及存储介质，用于在对业务节点的业务数据同步到目标节点的过程中，提高数据的准确性和完整性。

有鉴于此，本申请一方面提供一种业务数据更新的方法，包括：

获取来源于业务节点的快照数据，其中，快照数据为业务节点根据第一业务数据生成的，第一业务数据为第一时刻至第二时刻的业务数据；

获取来源于业务节点的目标操作日志，其中，目标操作日志包括业务节点所记录的从第一时刻至第三时刻的操作日志，第三时刻为出现在第二时刻之后的一个时刻；

根据目标操作日志获取日志数据；

根据快照数据以及日志数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。

本申请另一方面提供一种业务数据更新的方法，包括：

获取第一时刻至第二时刻内所对应的第一业务数据；

根据第一业务数据生成快照数据；

获取从第一时刻至第三时刻的目标操作日志，第三时刻为出现在第二时刻之后的一个时刻；

向目标节点发送快照数据以及目标操作日志，以使目标节点根据目标操作日志获取日志数据，根据快照数据以及日志数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。

本申请另一方面提供一种业务数据更新装置，包括：

获取单元，用于获取来源于业务节点的快照数据，其中，快照数据为业务节点根据第一业务数据生成的，第一业务数据为第一时刻至第二时刻的业务数据；

获取单元，还用于获取来源于业务节点的目标操作日志，其中，目标操作日志为业务节点所记录的从第一时刻至第三时刻的操作日志，第三时刻为出现在第二时刻之后的一个时刻；

获取单元，还用于根据目标操作日志获取日志数据；

更新单元，用于根据快照数据以及日志数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

更新单元，具体用于从日志数据中获取从第一时刻至第二时刻的数据，得到第一更新数据；

从日志数据中获取从第二时刻至第三时刻的数据，得到第二更新数据；

利用第一更新数据和第二更新数据对快照数据进行更新，得到第二业务数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

更新单元，具体用于从日志数据中获取从第二时刻至第三时刻的数据，得到第二更新数据；

利用第二更新数据对快照数据进行更新，得到第二业务数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

获取单元，还用于若第一业务数据在第二时刻至第三时刻内发生变化，则获取业务节点在第二时刻至所述第三时刻所对应的记录日志；

获取单元，还用于根据记录日志获取第一业务数据在第二时刻至第三时刻内的第三更新数据；

更新模块，还用于利用第三更新数据对快照数据进行更新。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

获取单元，具体用于若业务节点检测到第一业务数据发生变化，则接收业务节点发送的快照数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，业务更新装置还包括接收单元、比对单元以及发送单元；

接收单元，用于接收业务节点发送的第三业务数据，其中，第三业务数据为第三时刻之后未发生变化的业务数据；

比对单元，用于对第二业务数据以及第三业务数据进行比对，得到数据比对结果；

发送单元，用于向业务节点发送数据比对结果，以使业务节点根据数据比对结果对第一时刻和第二时刻进行调整。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

更新单元，还用于若数据比对结果指示第二业务数据与第三业务数据不一致，则利用第三业务数据对第二业务数据进行更新。

本申请另一方面提供一种业务数据更新装置，包括：

获取单元，用于获取第一时刻至第二时刻内所对应的第一业务数据；

生成单元，用于根据第一业务数据生成快照数据；

获取单元，还用于获取从第一时刻至第三时刻的目标操作日志，第三时刻为出现在第二时刻之后的一个时刻；

发送单元，用于向目标节点发送快照数据以及目标操作日志，以使目标节点根据目标操作日志获取日志数据，根据快照数据以及日志数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

生成单元，具体用于若检测到第一业务数据发生变化，根据第一业务数据生成快照数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，业务数据更新装置还包括接收单元和调整单元；

发送单元，具体用向目标节点发送第三业务数据，第三业务数据为在第三时刻之后未发生变化的数据；

接收单元，用于接收目标节点发送的数据比对结果，其中，数据比对结果为目标节点对第二业务数据以及第三业务数据进行比对后得到的；

调整单元，用于根据数据比对结果对第一时刻和第二时刻进行调整。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

调整单元单元，具体用于根据数据比对结果，确定第三业务数据和第二业务数据之间的差异值；

若差异值大于或等于差异阈值，则缩短第一时刻和第二时刻的间隔。

本申请另一方面提供一种计算机设备，该计算机设备具体为目标节点，该目标节点包括：存储器、收发器、处理器以及总线系统；

其中，存储器用于存储程序；

处理器用于执行存储器中的程序，处理器用于根据程序代码中的指令执行上述各方面的方法；

总线系统用于连接存储器以及处理器，以使存储器以及处理器进行通信。

本申请另一方面提供一种计算机设备，该计算机设备具体为业务节点，该业务节点包括：存储器、收发器、处理器以及总线系统；

其中，存储器用于存储程序；

处理器用于执行存储器中的程序，处理器用于根据程序代码中的指令执行上述各方面的方法；

总线系统用于连接存储器以及处理器，以使存储器以及处理器进行通信。

本申请的另一方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。

本申请的另一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方面所提供的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中，提供了一种业务数据更新的方法，目标节点可以获取业务节点中第一业务数据对应的第一时刻至第二时刻的快照数据，获取业务节点第一时刻至第三时刻的操作日志，其中，第三时刻为出现在第二时刻之后的一个时刻。然后目标节点可以根据操作日志生成日志数据，并根据该日志数据以及快照数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。通过上述方式，在业务节点创建快照的过程中，当已完成扫描的部分数据发生变更时，由于操作日志准确地记录了数据的实时变化，因此目标节点可以利用操作日志对接收到的快照数据进行更新，从而提高数据同步的准确性和完整性。

附图说明

图1为本申请实施例中将业务节点中的业务数据同步到数据仓库的场景示意图；

图2为本申请实施例中业务数据更新方法的应用场景示意图；

图3为本申请实施例中业务数据更新的方法的一个实施例示意图；

图4为本申请实施例中根据快照数据以及日志数据，更新得到第二业务数据的一个示意图；

图5为本申请实施例中根据快照数据以及日志数据，更新得到第二业务数据的另一个示意图；

图6为本实施例中对第二业务数据以及第三业务数据进行比对的一个场景示意图；

图7为本申请实施例中业务数据更新的方法的另一个实施例示意图；

图8为本申请实施例中基于区块链技术的一个数据共享系统示意图；

图9为本申请实施例中基于数据共享系统的一个区块链示意图；

图10为本申请实施例中生成一个区块的实施例示意图；

图11为本申请实施例提供的一种业务数据更新装置的结构示意图；

图12为本申请实施例中业务数据更新装置另一实施例示意图；

图13为本申请实施例中节点设备的一个结构示意图。

具体实施方式

本申请实施例提供了一种业务数据更新的方法、相关装置及存储介质，用于在对业务节点的业务数据同步到目标节点的过程中，提高数据的准确性和完整性。

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

全球网络存储工业协会(StorageNetworking industry association，SNIA)对快照(Snapshot)的定义是：关于指定数据集合的一个完全可用拷贝，该拷贝包括相应数据在某个时间点(拷贝开始的时间点)的映像。快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。

快照的作用主要是能够进行在线数据备份与恢复。当存储设备发生应用故障或者文件损坏时可以进行快速的数据恢复，将数据恢复某个可用的时间点的状态。快照的另一个作用是为存储用户提供了另外一个数据访问通道，当原数据进行在线应用处理时，用户可以访问快照数据，还可以利用快照进行测试等工作。因此，对于存储系统而言，快照是一种不可或缺的功能，经常用于以下业务场景中：

A：数据库、系统盘或数据盘的日常备份，可以利用快照定期地对重要业务数据进行备份，来应对误操作、攻击或病毒等导致的数据丢失风险；

B：在更换操作系统、应用软件升级或业务数据迁移等重大操作前，可以创建一份或多份数据快照，一旦升级或迁移过程中出现任何问题，可以通过数据快照及时恢复到正常的系统数据状态；

C：业务数据的多副本应用，可以通过对业务数据创建快照，从而为数据挖掘、报表查询或开发测试等应用提供近实时的真实业务数据。

请参阅图1所示，利用快照将业务节点中的业务数据同步到数据仓库的场景，以将业务节点中每天0点至24点的所有数据同步至数据仓库为例，既不能有超过24点的数据，也不能有24点前的数据遗漏。而快照技术需要对待备份的数据进行遍历扫描，待备份的数据量越大，则遍历扫描的时间越长。为了同步的数据不会有超过24点的数据，可以选择在23点时，对业务节点中从0点开始的数据进行快照。假设创建快照的过程需要30分钟，则此时所获得的快照数据为0点至23点30分的数据。一方面，缺失了23点30分至24点的数据；另一方面，对于承载业务数据的业务节点而言，其所存储的业务数据的变更频率往往是比较频繁的。因此，在创建快照的过程中，若已完成扫描的部分数据发生变更(例如新增、修改或删除)，则这些已经扫描过的数据的变更，快照是无法感知的。所以在23点至23点30分之间，已经遍历扫描过的数据的变化就被遗漏了，此时快照无法获取到变更后的数据，因此数据入库的准确性和完整性较低。

请参阅图2，图2为本申请实施例提供的业务数据更新方法的应用场景。为了解决上述问题，本申请中，可以将业务节点在第一时刻至第二时刻(例如0点至23点30分)的快照数据发送至目标节点(例如数据仓库)，并且将业务节点在第一时刻至第三时刻(例如0点至24点)的操作日志也发送到目标节点。由于操作日志准确地记录了数据的实时变化(包括0点至24点)，因此目标节点可以将操作日志作为依据，将操作日志所记录的数据变化覆盖到快照数据中，从而提高数据同步过程中的准确性和完整性。

结合上述介绍，下面基于目标节点对本申请中业务数据更新的方法进行介绍。请参阅图3，图3为本申请实施例中业务数据更新的方法的一个实施例示意图，如图所示，本申请实施例中业务数据更新的方法的一个实施例包括：

101、获取来源于业务节点的快照数据，其中，快照数据为业务节点根据第一业务数据生成的，第一业务数据为第一时刻至第二时刻的业务数据；

本申请实施例，提供了一种将业务节点中的业务数据同步到目标节点的方法。其中，业务节点可以是用于承载业务数据的数据库(例如Mysql或Oracle等)，随着互联网的快速发展，例如互联网增值、网游、金融或电商等业务数据往往是体量巨大且更新频繁的。为了能够更好地对业务数据进行存储和分析，一般来说，会将存储量更高、计算能力更强且更稳定的数据仓库作为目标节点，把业务节点中的业务数据同步到目标节点。

关于上文所提及的“数据库”(Database)，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

数据库管理系统(英语：Database Management System，简称DBMS)是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类，例如关系式、XML(Extensible MarkupLanguage,即可扩展标记语言)；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话；或依据所用查询语言来作分类，例如SQL(结构化查询语言(Structured QueryLanguage)、XQuery；或依据性能冲量重点来作分类，例如最大规模、最高运行速度；亦或其他的分类方式。不论使用哪种分类方式，一些DBMS能够跨类别，例如，同时支持多种查询语言。

为了便于理解，本实施例中，以将业务节点中每天0点至24点的所有业务数据同步至数据仓库为例进行阐述，要求所同步到数据仓库的业务数据，既不能有超过24点的数据，也不能有24点前的数据遗漏。

具体的，先选定需要创建快照的第一业务数据对应的时间点(即本申请中的第一时刻和第二时刻)，按照选定的第一时刻和第二时刻，对业务节点中的业务数据进行遍历扫描。由于遍历扫描需要消耗一定时间，所以需要提前创建快照。需要说明的是，本申请实施例中，第二时刻指的是创建快照的时刻，而创建快照的过程中所消耗的时间，并不在第二时刻的范围之内。

以第一时刻为0点，第二时刻为23点为例，创建0点至23点的业务数据的快照，得到一份快照数据。由于快照的遍历扫描是比较全面的，不会遗漏数据。此时可以先将这份快照数据，发送给数据仓库。

但是，这份快照数据是不完整的。假设创建快照需要耗时半小时，那么在创建快照这半小时内，已经扫描过的业务数据若是发生变化，则不会被再次扫描到。因此，这份快照数据，对于第一业务数据在23点至23点30分的数据变化，是扫描不完整的。另一方面，由于23点30分至24点这段时间，并没有进行快照的扫描，因此这份快照数据同样也缺少了23点30分至24点的数据变化。所以，还需要将业务数据中23点至24点的数据变化，补全到快照数据当中。

具体的，本申请中的“业务节点”和“目标节点”可以由服务器组成。其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。其中，终端可以通过有线或无线通信方式与服务器进行直接或间接地连接，从而对服务器中所存储的数据进行读写等操作。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。

在实际应用中，若业务节点或者目标节点的计算力比较一般，可以为业务节点或者目标节点配置计算设备。示例性的，可以将计算设备配置到云服务器，由云服务器来进行逻辑处理计算。

102、获取来源于业务节点的目标操作日志，其中，目标操作日志为业务节点所记录的从第一时刻至第三时刻的操作日志，第三时刻为出现在第二时刻之后的一个时刻；

数据库的操作日志能够记录数据的实时变化。因此，通过操作日志可以得知数据都经历了哪些变化，不管是更新、插入还是删除都能被良好地反馈。但是，操作日志的传递有一定的丢失概率，尤其是对于Mysql数据库，其操作日志更加的传递更加不稳定，从而导致数据的不准确。

本申请实施例中，业务节点可以将第一时刻至第三时刻的操作日志发送给数据仓库。以第三时刻为24点为例，那么目标操作日志就是0点至24点的操作日志。

需要说明的是，业务节点可以在第一时刻至第三时刻这段时间内，将发生更新的操作日志实时地发送给数据仓库；也可以在到达第三时刻之后，将第一时刻至第三时刻这段时间内操作日志打包，一起发送给数据仓库。

103、根据目标操作日志获取日志数据；

数据仓库接收到来自业务节点的目标操作日志后，可以对该目标操作日志进行解析，生成日志数据，该日志数据精确地体现了业务节点在第一时刻至第三时刻(0点至24点)内各个时间点的数据变化。

104、根据快照数据以及日志数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。

由于日志数据包括了第一时刻至第三时刻(0点至24点)内各个时间点的数据变化，那么其中自然也包括了第二时刻至第三时刻(23点至24点)的数据变化。而如步骤101中所提到的，数据仓库所接收到的快照数据是不完整不够准确的。因此，数据仓库可以根据快照数据以及日志数据，更新得到第二业务数据。

以电商的应用场景为例，业务节点中，有一条订单数据，于20点时，订单状态更新为“待发货”。此时，业务节点从23点开始创建快照，直至23点30分完成快照。假设创建快照过程中，于23点10分，对该订单数据完成了扫描，此时20点更新为“待发货”的订单状态已经被记录。当该订单数据，于23点20分时，订单状态更新为“已发货”，则“已发货”的订单状态，并不会被快照所扫描到。数据仓库所接收到的快照数据中，该订单仍然时处于“待发货”的订单状态。但是对于23点20分时，该订单数据的订单状态更新为“已发货”，这一事件，操作日志是可以记录到的。数据仓库接收到该操作日志后，可以解析生成对应的日志数据。而日志数据中，记录了该订单数据的订单状态于23点20分更新为“已发货”。而快照数据中，该订单数据所记载的最新一次更新时间为20点，则说明操作日志中，订单状态为“已发货”的更新时间迟于快照数据中订单状态为“待发货”的更新时间。此时，应当已操作日志中“已发货”的订单状态为准，对快照数据中，“待发货”的订单状态进行覆盖。

本申请实施例中，提供了一种业务数据更新的方法，目标节点可以获取业务节点中第一业务数据对应的第一时刻至第二时刻的快照数据，获取业务节点第一时刻至第三时刻的操作日志，其中，第三时刻为出现在第二时刻之后的一个时刻。然后目标节点可以根据操作日志生成日志数据，并根据该日志数据以及快照数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。通过上述方式，在业务节点创建快照的过程中，当已完成扫描的部分数据发生变更时，由于操作日志准确地记录了数据的实时变化，因此目标节点可以利用操作日志对接收到的快照数据进行更新，从而提高数据同步的准确性和完整性。

可选地，在上述图3对应的实施例的基础上，本申请实施例提供的业务数据更新的方法另一个可选实施例中，根据快照数据以及日志数据，更新得到第二业务数据，具体包括：

从日志数据中获取从第一时刻至第二时刻的数据，得到第一更新数据；

从日志数据中获取从第二时刻至第三时刻的数据，得到第二更新数据；

利用第一更新数据对快照数据进行更新，得到第三更新数据；

利用第二更新数据对第三更新数据进行更新，得到第二业务数据。

本实施例中，快照没办法体现数据在各个时间段的更新情况，通过快照只能获得到数据在某一时刻的即时状态。因此，为了使快照数据更完整，可以从日志数据中获取从第一时刻至第二时刻的数据，得到第一更新数据。该第一更新数据，记录了业务数据从第一时刻至第二时刻所经历的变化。利用第一更新数据对快照数据进行更新，从而完善了数据完整的更新过程，可以提高快照数据的完整性。

另一方面，由于快照是在第二时刻开始创建的，而快照的遍历扫描需要消耗一定的时间，因此在遍历扫描的过程中(即第二时刻之后)，已经扫描过的业务数据若是发生变化，则不会被再次扫描到。因此可以从日志数据中获取从第二时刻至第三时刻的数据，得到第二更新数据，该第二更新数据记录了业务数据从第二时刻至第三时刻所经历的变化。利用第二更新数据对快照数据进行更新，从而补充了业务数据在第二时刻之后所经历的变化，可以提高快照数据的完整性。

为了便于理解，请参阅图4，图4为本申请实施例中根据快照数据以及日志数据，更新得到第二业务数据的一个场景示意图。如图4所示，订单状态于10点更新为“待付款”，于18点更新为“已付款”，于23点20分更新为“已发货”。此时，业务节点于23点创建快照，并于23点10时扫描到该订单状态，18点时为“已付款”。但23点20分时，更新为“已发货”的订单状态没办法被快照所再次扫描，所以该快照数据是不准确的。并且，数据仓库业务也无法得知，该订单状态此前在10点时更新为“待付款”，因此，这份快照数据的完整性较低。通过0点至24点的操作日志，数据仓库可以获取该订单状态在不同时间点的变化，对快照数据进行更新。一方面，对在快照数据的更新时间(18点)之前的数据变化，进行补充，如补充：订单状态于10点更新为“待付款”。另一方面，利用在快照数据的更新时间(18点)之后的数据变化，对快照数据进行覆盖，即更新为：订单状态于23点20分更新为“已发货”。最终，更新得到第二业务数据为：订单状态于10点更新为“待付款”，订单状态于18点更新为“已付款”，订单状态于23点20分更新为“已发货”。

本实施例中，利用日志数据中第一时刻至第二时刻的数据，补充了在快照数据的更新时间之前的数据变化，利用日志数据中第二时刻至第三时刻的数据，对快照数据进行覆盖，从而所得到的第二业务数据，即包括了业务数据在第一时刻至第三时刻内，各个时间点的数据变化，从而提高了快照数据的完整性和准确性。

可选地，在上述图3对应的实施例的基础上，本申请实施例提供的业务数据更新的方法另一个可选实施例中，根据快照数据以及日志数据，更新得到第二业务数据，具体包括：

从日志数据中获取从第一时刻至第二时刻的数据，得到第一更新数据；

从日志数据中获取从第二时刻至第三时刻的数据，得到第二更新数据；

利用第一更新数据和利用第二更新数据对快照数据进行更新，得到第二业务数据。

本实施例中，在进行快照的扫描的过程中，由于快照是在第二时刻开始创建的，而快照的遍历扫描需要消耗一定的时间，因此在遍历扫描的过程中(即第二时刻之后)，已经扫描过的业务数据若是发生变化，则不会被再次扫描到。因此可以从日志数据中获取从第二时刻至第三时刻的数据，得到第二更新数据，该第二更新数据记录了业务数据从第二时刻至第三时刻所经历的变化。利用第二更新数据对快照数据进行更新，从而补充了业务数据在第二时刻之后所经历的变化，可以提高快照数据的完整性。

为了便于理解，请参阅图5，图5为本申请实施例中根据快照数据以及日志数据，更新得到第二业务数据的另一个场景示意图。如图5所示，订单状态于10点更新为“待付款”，于18点更新为“已付款”，于23点20分更新为“已发货”。此时，业务节点于23点创建快照，并于23点10时扫描到该订单状态，18点时为“已付款”。但23点20分时，更新为“已发货”的订单状态没办法被快照所再次扫描，所以该快照数据是不准确的。通过获取日志数据中第二时刻至第三时刻(即23点至24点)的数据，得到第二更新数据(即订单状态于23点20分更新为“已发货”)。由于第二更新数据的更新时间(23点20分)在快照数据的更新时间(18点)之后，因此，以第二更新数据为准，对快照数据进行覆盖，得到第二业务数据(即订单状态于23点20分更新为“已发货”)。

本实施例中，利用日志数据中第二时刻至第三时刻的数据，对快照数据进行覆盖，从而得到的第二业务数据，即包括了业务数据截止第三时刻的最新状态，从而提高了快照数据的准确性，并且，本实施例只对业务数据的最新状态进行更新覆盖，而不需要对更新时间在快照数据之前的数据变化进行处理，节约了目标节点的存储空间。

可选地，在上述图3对应的实施例的基础上，本申请实施例提供的业务数据更新的方法另一个可选实施例中，业务数据更新的方法还可以包括如下步骤：

若第一业务数据在第二时刻至第三时刻内发生变化，则获取业务节点在第二时刻至第三时刻所对应的记录日志；

根据记录日志获取第一业务数据在第二时刻至第三时刻内的第三更新数据；

利用第三更新数据对快照数据进行更新。

由于操作日志的传递有一定的丢失概率，尤其是对于Mysql数据库，其操作日志更加的传递更加不稳定，更容易发生丢失。为了能够对快照数据做好更好的补全，本实施例中，在当业务节点中的第一业务数据在第二时刻至第三时刻内发生变化时，可以通过用户主动记录下对应的变化情况，形成记录日志并发到给目标节点。目标节点根据记录日志解析出第三更新数据，并对快照数据进行更新。

本实施例中，还通过用户主动记录数据的变化情况，发送给目标节点，从而对快照数据进行更新，进一步地提高了数据的准确性和完整性。

可选地，在上述图3对应的实施例的基础上，本申请实施例提供的业务数据更新的方法另一个可选实施例中，获取来源于业务节点的快照数据，具体包括：

若业务节点检测到第一业务数据发生变化，则接收业务节点发送的快照数据。

本实施例中，可以只扫描业务节点在第一时刻至第二时刻有发生更新的第一业务数据，而那些在第一时刻至第二时刻没有发生变更的业务数据，则可以忽略，不获取相应的快照数据。

需要说明的是，本申请实施例并不限定创建快照的次数。在实际应用中，可以按照预设的时间间隔，对需要同步的数据，反复地执行本申请实施例所提供的业务数据更新的方法。例如，上文介绍了，对需要同步的业务数据，先通过一次快照获取一份快照数据，并结合操作日志进行更新。此外，还可以预先设定好执行快照的时间间隔，每当到达执行快照的时间点(第二时刻)时，自动执行快照扫描。然后再根据第一时刻至第三时刻的操作日志和快照数据，更新得到第二数据。但是，当快照的扫描间隔较短时，由于数据量较大，难以对一个时间段内(第一时刻至第二时刻)的所有数据全部进行扫描，而且频繁地对某些更新频率较低的业务数据进行扫描发送，目标节点会得到较多的冗余业务数据，造成资源浪费。因此，本实施例中，可以只对第一时刻至第二时刻内发生变化的业务数据，进行扫描，而那些没有发生变更的数据，则可以忽略。

例如，当需要对0点至24点内发生变更的业务数据进行同步时，可以从1点开始，每隔一小时则对进行一次快照，并将快照数据发送给目标节点。然后再根据操作日志，对每份快照数据进行更新。这样的话，目标节点便可以每隔1小时便获得到一份快照数据，提高了目标节点中的数据的实时性。

本实施例中，业务节点可以只扫描在第一时刻至第二时刻有发生更新的第一业务数据，从而减少快照扫描的数据量，缩短扫描时间，减少了计算资源的占用。

可选地，在上述图3对应的实施例的基础上，本申请实施例提供的业务数据更新的方法另一个可选实施例中，根据快照数据以及日志数据，更新得到第二业务数据之后，还可以包括如下步骤：

接收业务节点发送的第三业务数据，其中，第三业务数据第三时刻后未发生变化的业务数据；

对第二业务数据以及第三业务数据进行比对，得到数据比对结果；

向业务节点发送数据比对结果，以使业务节点根据数据比对结果对第一时刻和第二时刻进行调整。

为了便于理解，请参阅图6，图6为本实施例中对第二业务数据以及第三业务数据进行比对的一个场景示意图。如图6所示，本实施例中，在根据快照数据以及日志数据，更新得到第二业务数据之后，还可以将该第二业务数据，与业务节点中的数据，进行比对，从而检验数据同步的结果。

但是，一般来说，业务节点中的业务数据，是频繁发生变化的。由于第二业务数据为业务数据在第一时刻至第三时刻(0点至24点)的数据状态，因此，业务节点中的业务数据在第三时刻(24点)之后发生变化的数据状态，是没有参考意义的。所以当需要进行数据比对时，可以将业务数据在第三时刻(24点)之后未发生变化的业务数据，即第三业务数据发送给目标节点，目标节点可以将第二业务数据以及第三业务数据进行比对，得到数据比对结果。该数据比对结果可以发送给业务节点，业务节点接收到该数据比对结果后，就能够知道，数据更新的准确性。另一方面，第二业务数据和第三业务数据之间的差异，能够反映业务节点中业务数据更新的频繁程度。

应理解，由于步骤101中，业务节点创建快照的时间段(第一时刻至第二时刻)越长，则遍历扫描得耗时越长，期间业务数据发生变更的次数就越多，从而直接影响了快照数据的准确性。因此，在业务节点便可以根据该数据比对结果，对第一时刻至第二时刻进行调整。即，一方面可以调整定时执行创建快照的时间点(第二时刻)，例如将创建快照的时间点从23点提前到22点；另一方面可以调整每次执行创建快照的时间间隔，例如从每一小时创建一次快照，调整为每半小时创建一次快照。

本实施例中，在根据快照数据以及日志数据，更新得到第二业务数据之后，将第二业务数据与业务节点中在第三时刻之后未发生变化的数据进行比对，并根据数据比对结果调整第一时刻和第二时刻，从而优化了后续的业务数据更新的准确性和完整性。

可选地，在上述图3对应的实施例的基础上，本申请实施例提供的业务数据更新的方法另一个可选实施例中，对第二业务数据以及第三业务数据进行比对，得到数据比对结果之后，还可以包括如下步骤：

若数据比对结果指示第二业务数据与第三业务数据不一致，则利用第三业务数据对第二业务数据进行更新。

本实施例中，对第二业务数据以及第三业务数据进行比对，得到数据比对结果之后，若根据数据比对结果发现第二业务数据中仍然存在与第三业务数据不一致的数据时，则目标节点可以以第三业务数据为准，对第二业务数据进行更新，更进一步地提升了业务数据更新的准确性和完整性。

下面基于业务节点对本申请中业务数据更新的方法进行介绍，请参阅图7，图7为本申请实施例中业务数据更新的方法另一个实施例示意图，如图7所示，本申请实施例中业务数据更新的方法一个实施例包括：

201、获取第一时刻至第二时刻内所对应的第一业务数据；

202、根据第一业务数据生成快照数据；

203、获取从第一时刻至第三时刻的目标操作日志，第三时刻为出现在第二时刻之后的一个时刻；

204、向目标节点发送快照数据以及目标操作日志，以使目标节点根据目标操作日志获取日志数据，根据快照数据以及日志数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。

本实施例中，提供了一种业务数据更新的方法，目标节点可以获取业务节点中第一业务数据对应的第一时刻至第二时刻的快照数据，获取业务节点第一时刻至第三时刻的操作日志，其中，第三时刻为出现在第二时刻之后的一个时刻。然后目标节点可以根据操作日志生成日志数据，并根据该日志数据以及快照数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。通过上述方式，在业务节点创建快照的过程中，当已完成扫描的部分数据发生变更时，由于操作日志准确地记录了数据的实时变化，因此目标节点可以利用操作日志对接收到的快照数据进行更新，从而提高数据同步的准确性和完整性。具体方法流程以及相关有益效果，与前述实施例所介绍的方法类似，此处不做赘述。

可选地，在上述图7对应的实施例的基础上，本申请实施例提供的业务数据更新的方法另一个可选实施例中，根据第一业务数据生成快照数据，可以包括如下步骤：

若检测到第一业务数据发生变化，根据第一业务数据生成快照数据。

本实施例中，业务节点可以只扫描在第一时刻至第二时刻有发生更新的第一业务数据，从而减少快照扫描的数据量，缩短扫描时间，减少了计算资源的占用。具体方法流程，与前述实施例所介绍的方法类似，此处不做赘述。

可选地，在上述图7对应的实施例的基础上，本申请实施例提供的业务数据更新的方法另一个可选实施例中，向目标节点发送快照数据以及目标操作日志，以使目标节点根据目标操作日志获取日志数据，根据快照数据以及日志数据，更新得到第二业务数据之后，还可以包括如下步骤：

向目标节点发送第三业务数据，第三业务数据为在第三时刻之后未发生变化的数据；

接收目标节点发送的数据比对结果，其中，数据比对结果为目标节点对第二业务数据以及第三业务数据进行比对后得到的；

根据数据比对结果对第一时刻和第二时刻进行调整。

本实施例中，在根据快照数据以及日志数据，更新得到第二业务数据之后，将第二业务数据与业务节点中在第三时刻之后未发生变化的数据进行比对，并根据数据比对结果调整第一时刻和第二时刻，从而优化了后续的业务数据更新的准确性和完整性。具体方法流程，与前述实施例所介绍的方法类似，此处不做赘述。

可选地，在上述图7对应的实施例的基础上，根据数据比对结果对数据快照时段进行更新，可以包括如下步骤：

根据数据比对结果，确定第三业务数据和第二业务数据之间的差异值；

若差异值大于或等于差异阈值，则缩短第一时刻和第二时刻的间隔。

本实施例中，可以先配置一个第三业务数据和第二业务数据之间的差异值的阈值，即差异阈值。以该差异阈值来判断数据比对结果是否满足要求。

具体的，通过数据比对结果，便可以知道第三业务数据和第二业务数据的差异值。进一步的，将该差异值与预设的差异阈值进行比较。若该差异值小于差异阈值，则可以认为，快照数据的准确性和完整性，达到了要求，此时可以不需要对第一时刻和第二时刻进行调整；若该差异值大于差异阈值，则可以认为，快照数据的准确性和完整性不足，可以通过调整快照的扫描时间来提高。此时，可以缩短执行快照的时间间隔(即第一时刻和第二时刻的间隔)，从而减少快照的遍历扫描所消耗的时间，减少遍历扫描过程中业务数据发生的变化。

本实施例中，通过第三业务数据和第二业务数据之间的差异值来判断是否需要调整执行快照扫描得时间，从而提高了快照数据的准确性。

本申请提供了一种业务数据更新的方法，目标节点可以获取业务节点中第一业务数据对应的第一时刻至第二时刻的快照数据，获取业务节点第一时刻至第三时刻的操作日志，其中，第三时刻为出现在第二时刻之后的一个时刻。然后目标节点可以根据操作日志生成日志数据，并根据该日志数据以及快照数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。通过上述方式，在业务节点创建快照的过程中，当已完成扫描的部分数据发生变更时，由于操作日志准确地记录了数据的实时变化，因此目标节点可以利用操作日志对接收到的快照数据进行更新，从而提高数据同步的准确性和完整性。进一步的，本申请实施例中，业务节点或目标节点，都可以是区块链节点设备，从而将业务数据以区块链信息的方式保存及同步到区块链节点中。由于区块链技术具有较强的保密性和防篡改性，往往可以将重要程度较高的业务数据(例如金融信息、身份信息或企业内部信息)同步到区块链节点设备，从而提升数据的安全性。

具体地，为了便于理解，请参阅图8，图8为本申请实施例中基于区块链技术的一个数据共享系统示意图，如图所示，数据共享系统300是指用于进行节点与节点之间数据共享的系统，该数据共享系统中可以包括多个节点301，多个节点301可以是指数据共享系统中各个客户端。每个节点301在进行正常工作可以接收到输入信息，并基于接收到的输入信息维护该数据共享系统内的共享数据。为了保证数据共享系统内的信息互通，数据共享系统中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。例如，当数据共享系统中的任意节点接收到输入信息时，数据共享系统中的其他节点便根据共识算法获取该输入信息，将该输入信息作为共享数据中的数据进行存储，使得数据共享系统中全部节点上存储的数据均一致。

对于数据共享系统中的每个节点，均具有与其对应的节点标识，而且数据共享系统中的每个节点均可以存储有数据共享系统中其他节点的节点标识，以便后续根据其他节点的节点标识，将生成的区块广播至数据共享系统中的其他节点。每个节点中可维护一个如下表所示的节点标识列表，将节点名称和节点标识对应存储至该节点标识列表中。其中，节点标识可为IP(Internet Protocol，网络之间互联的协议)地址以及其他任一种能够用于标识该节点的信息，表1中仅以IP地址为例进行说明。

节点名称	节点标识
		节点1	117.114.151.174
节点2	117.116.189.145
		…	…
节点N	119.123.789.258

数据共享系统中的每个节点均存储一条相同的区块链。区块链由多个区块组成，参见图9，区块链由多个区块组成，创始块中包括区块头和区块主体，区块头中存储有输入信息特征值、版本号、时间戳和难度值，区块主体中存储有输入信息；创始块的下一区块以创始块为父区块，下一区块中同样包括区块头和区块主体，区块头中存储有当前区块的输入信息特征值、父区块的区块头特征值、版本号、时间戳和难度值，并以此类推，使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，保证了区块中输入信息的安全性。

在生成区块链中的各个区块时，参见图10，区块链所在的节点在接收到输入信息时，对输入信息进行校验，完成校验后，将输入信息存储至内存池中，并更新其用于记录输入信息的哈希树；之后，将更新时间戳更新为接收到输入信息的时间，并尝试不同的随机数，多次进行特征值计算，使得计算得到的特征值可以满足下述公式：

SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))＜TARGET

其中，SHA256为计算特征值所用的特征值算法；version(版本号)为区块链中相关区块协议的版本信息；prev_hash为当前区块的父区块的区块头特征值；merkle_root为输入信息的特征值；ntime为更新时间戳的更新时间；nbits为当前难度，在一段时间内为定值，并在超出固定时间段后再次进行确定；x为随机数；TARGET为特征值阈值，该特征值阈值可以根据nbits确定得到。

这样，当计算得到满足上述公式的随机数时，便可将信息对应存储，生成区块头和区块主体，得到当前区块。随后，区块链所在节点根据数据共享系统中其他节点的节点标识，将新生成的区块分别发送给其所在的数据共享系统中的其他节点，由其他节点对新生成的区块进行校验，并在完成校验后将新生成的区块添加至其存储的区块链中。

本申请实施例中，提供了一种将业务数据存储于区块链节点设备的方法，通过上述方式，由于区块中包含了验证下一个区块有效性的信息，因此，能够有效地降低业务数据被恶意窃取的可能性，此外，新的区块一旦加入至区块链中就不会被移除，从而减少业务数据出现丢失的情况。

为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关装置。请参阅图11，图11为本申请实施例提供的一种业务数据更新装置的结构示意图，业务数据更新装置300包括：

获取单元301，用于获取来源于业务节点的快照数据，其中，快照数据为业务节点根据第一业务数据生成的，第一业务数据为第一时刻至第二时刻的业务数据；

获取单元301，还用于获取来源于业务节点的目标操作日志，其中，目标操作日志为业务节点所记录的从第一时刻至第三时刻的操作日志，第三时刻为出现在第二时刻之后的一个时刻；

获取单元301，还用于根据目标操作日志获取日志数据；

更新单元302，用于根据快照数据以及日志数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的业务数据更新装置300的一个实施例中，

更新单元302，具体用于从日志数据中获取从第一时刻至第二时刻的数据，得到第一更新数据；

从日志数据中获取从第二时刻至第三时刻的数据，得到第二更新数据；

利用第一更新数据和第二更新数据对快照数据进行更新，得到第二业务数据。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的业务数据更新装置300的一个实施例中，

更新单元302，具体用于从日志数据中获取从第二时刻至第三时刻的数据，得到第二更新数据；

利用第二更新数据对快照数据进行更新，得到第二业务数据。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的业务数据更新装置300的一个实施例中，

获取单元301，还用于若第一业务数据在第二时刻至第三时刻内发生变化，则获取业务节点在第二时刻至所述第三时刻所对应的记录日志；

获取单元301，还用于根据记录日志获取第一业务数据在第二时刻至第三时刻内的第三更新数据；

更新模块302，还用于利用第三更新数据对快照数据进行更新。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的业务数据更新装置300的一个实施例中，

获取单元，具体用于若业务节点检测到第一业务数据发生变化，则接收业务节点发送的快照数据。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的业务数据更新装置300的一个实施例中，业务更新装置300还包括接收单元、比对单元以及发送单元；

接收单元303，用于接收业务节点发送的第三业务数据，其中，第三业务数据为第三时刻之后未发生变化的业务数据；

比对单元304，用于对第二业务数据以及第三业务数据进行比对，得到数据比对结果；

发送单元305，用于向业务节点发送数据比对结果，以使业务节点根据数据比对结果对第一时刻和第二时刻进行调整。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的业务数据更新装置300的一个实施例中，

更新单元302，还用于若数据比对结果指示第二业务数据与第三业务数据不一致，则利用第三业务数据对第二业务数据进行更新。

本实施例中，业务数据更新装置300可以执行前述图3或图7中任一项所示实施例中目标节点所执行的操作，具体此处不再赘述。

请参阅图12，图12为本申请实施例中业务数据更新装置另一实施例示意图，如图12所示，业务数据更新装置400包括：

获取单元401，用于获取第一时刻至第二时刻内所对应的第一业务数据；

生成单元402，用于根据第一业务数据生成快照数据；

获取单元401，还用于获取从第一时刻至第三时刻的目标操作日志，第三时刻为出现在第二时刻之后的一个时刻；

发送单元403，用于向目标节点发送快照数据以及目标操作日志，以使目标节点根据目标操作日志获取日志数据，根据快照数据以及日志数据，更新得到第二业务数据，其中，第二业务数据为第一时刻至第三时刻的业务数据。

可选地，在上述图12所对应的实施例的基础上，本申请实施例提供的业务数据更新装置400的一个实施例中，

生成单元402，具体用于若检测到第一业务数据发生变化，根据第一业务数据生成快照数据。

可选地，在上述图12所对应的实施例的基础上，本申请实施例提供的业务数据更新装置400的一个实施例中，业务数据更新装置还包括接收单元和调整单元；

发送单元403，具体用向目标节点发送第三业务数据，第三业务数据为在第三时刻之后未发生变化的数据；

接收单元404，用于接收目标节点发送的数据比对结果，其中，数据比对结果为目标节点对第二业务数据以及第三业务数据进行比对后得到的；

调整单元405，用于根据数据比对结果对第一时刻和第二时刻进行调整。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

调整单元405，具体用于根据数据比对结果，确定第三业务数据和第二业务数据之间的差异值；若差异值大于或等于差异阈值，则缩短第一时刻和第二时刻的间隔。

本实施例中，业务数据更新装置400可以执行前述图3或图7中任一项所示实施例中业务节点所执行的操作，具体此处不再赘述。

本申请实施例还提供了一种节点设备，用于执行图3或图7对应的实施例中目标节点执行的步骤，或者，用于执行图3或图7对应的实施例中业务节点执行的步骤。请参阅图13，图13为本申请实施例中节点设备的一个结构示意图，应理解，改及节点设备可以是上述实施例中的目标节点，也可以是上述实施例中的业务节点。如图所示，该节点设备500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)522(例如，一个或一个以上处理器)和存储器532，一个或一个以上存储应用程序542或数据544的存储介质530(例如一个或一个以上海量存储设备)。其中，存储器532和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对节点设备中的一系列指令操作。更进一步地，中央处理器522可以设置为与存储介质530通信，在节点设备500上执行存储介质530中的一系列指令操作。

节点设备500还可以包括一个或一个以上电源526，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口558，和/或，一个或一个以上操作系统541，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

上述实施例中由目标节点所执行的步骤，或者，由业务节点所执行的步骤可以基于该图13所示的节点设备的结构。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如前述各个实施例描述的方法。

本申请实施例中还提供一种包括程序的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例描述的方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，互动视频的管理装置，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (15)

1.一种业务数据更新的方法，其特征在于，包括：

获取来源于业务节点的快照数据，其中，所述快照数据为所述业务节点根据第一业务数据生成的，所述第一业务数据为第一时刻至第二时刻的业务数据；

获取来源于所述业务节点的目标操作日志，其中，所述目标操作日志包括所述业务节点所记录的从所述第一时刻至第三时刻的操作日志，所述第三时刻为出现在所述第二时刻之后的一个时刻；

根据所述目标操作日志获取日志数据；

根据所述快照数据以及所述日志数据，更新得到第二业务数据，其中，所述第二业务数据为所述第一时刻至所述第三时刻的业务数据。

2.根据权利要求1所述的方法，其特征在于，所述根据所述快照数据以及所述日志数据，更新得到第二业务数据包括：

从所述日志数据中获取从所述第一时刻至所述第二时刻的数据，得到第一更新数据；

从所述日志数据中获取从所述第二时刻至所述第三时刻的数据，得到第二更新数据；

利用所述第一更新数据和利用所述第二更新数据对所述快照数据进行更新，得到第二业务数据。

3.根据权利要求1所述的方法，其特征在于，所述根据所述快照数据以及所述日志数据，更新得到第二业务数据包括：

从所述日志数据中获取从所述第二时刻至所述第三时刻的数据，得到第二更新数据；

利用所述第二更新数据对快照数据进行更新，得到第二业务数据。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述第一业务数据在所述第二时刻至所述第三时刻内发生变化，则获取所述业务节点在所述第二时刻至所述第三时刻所对应的记录日志；

根据所述记录日志获取所述第一业务数据在所述第二时刻至所述第三时刻内的第三更新数据；

利用所述第三更新数据对所述快照数据进行更新。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述获取来源于业务节点的快照数据，包括：

若所述业务节点检测到所述第一业务数据发生变化，则接收所述业务节点发送的所述快照数据。

6.根据权利要求5所述的方法，其特征在于，所述根据所述快照数据以及所述日志数据，更新得到第二业务数据之后，所述方法还包括：

接收所述业务节点发送的第三业务数据，其中，所述第三业务数据为所述第三时刻之后未发生变化的业务数据；

对所述第二业务数据以及所述第三业务数据进行比对，得到数据比对结果；

向所述业务节点发送所述数据比对结果，以使所述业务节点根据所述数据比对结果对所述第一时刻和所述第二时刻进行调整。

7.根据权利要求6所述的方法，其特征在于，所述对所述第二业务数据以及所述第三业务数据进行比对，得到数据比对结果之后，所述方法还包括：

若所述数据比对结果指示所述第二业务数据与所述第三业务数据不一致，则利用所述第三业务数据对所述第二业务数据进行更新。

8.一种业务数据更新的方法，其特征在于，包括：

获取第一时刻至第二时刻内所对应的第一业务数据；

根据所述第一业务数据生成快照数据；

获取从所述第一时刻至第三时刻的目标操作日志，所述第三时刻为出现在所述第二时刻之后的一个时刻；

向目标节点发送所述快照数据以及所述目标操作日志，以使所述目标节点根据所述目标操作日志获取日志数据，根据所述快照数据以及所述日志数据，更新得到第二业务数据，其中，所述第二业务数据为所述第一时刻至所述第三时刻的业务数据。

9.根据权利要求8所述的方法，其特征在于，所述根据所述第一业务数据生成快照数据，包括：

若检测到所述第一业务数据发生变化，根据所述第一业务数据生成快照数据。

10.根据权利要求8或9所述的方法，其特征在于，所述向目标节点发送所述快照数据以及所述目标操作日志，以使所述目标节点根据所述目标操作日志获取日志数据，根据所述快照数据以及所述日志数据，更新得到第二业务数据之后，所述方法还包括：

向所述目标节点发送第三业务数据，所述第三业务数据为在所述第三时刻之后未发生变化的数据；

接收所述目标节点发送的数据比对结果，其中，所述数据比对结果为所述目标节点对所述第二业务数据以及第三业务数据进行比对后得到的；

根据所述数据比对结果对所述第一时刻和所述第二时刻进行调整。

11.根据权利要求10所述的方法，其特征在于，所述根据所述数据比对结果对数据快照时段进行更新，包括：

根据所述数据比对结果，确定所述第三业务数据和所述第二业务数据之间的差异值；

若所述差异值大于或等于差异阈值，则缩短所述第一时刻和所述第二时刻的间隔。

12.一种业务数据更新装置，其特征在于，包括：

获取单元，用于获取来源于业务节点的快照数据，其中，所述快照数据为所述业务节点根据第一业务数据生成的，所述第一业务数据为第一时刻至第二时刻的业务数据；

所述获取单元，还用于获取来源于所述业务节点的目标操作日志，其中，所述目标操作日志为所述业务节点所记录的从所述第一时刻至第三时刻的操作日志，所述第三时刻为出现在所述第二时刻之后的一个时刻；

所述获取单元，还用于根据所述目标操作日志获取日志数据；

更新单元，用于根据所述快照数据以及所述日志数据，更新得到第二业务数据，其中，所述第二业务数据为所述第一时刻至所述第三时刻的业务数据。

13.一种业务数据更新装置，其特征在于，包括：

获取单元，用于获取第一时刻至第二时刻内所对应的第一业务数据；

生成单元，用于根据所述第一业务数据生成快照数据；

所述获取单元，还用于获取从所述第一时刻至第三时刻的目标操作日志，所述第三时刻为出现在所述第二时刻之后的一个时刻；

发送单元，用于向目标节点发送所述快照数据以及所述目标操作日志，以使所述目标节点根据所述目标操作日志获取日志数据，根据所述快照数据以及所述日志数据，更新得到第二业务数据，其中，所述第二业务数据为所述第一时刻至所述第三时刻的业务数据。

14.一种计算机设备，其特征在于，所述计算机设备包括处理器以及存储器：

所述存储器用于存储程序代码；

所述处理器用于根据所述程序代码中的指令执行如上述权利要求1至7中任一项所述的方法，或，执行如上述权利要求8至11中任一项所述的方法。

15.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行如上述权利要求1至7中任一项所述的方法，或，执行如上述权利要求8至11中任一项所述的方法。

Images