CN110716825B - 数据容灾处理方法、装置及系统 - Google Patents

Abstract

本申请实施例公开了数据容灾处理方法、装置及系统，其中，所述系统包括：离线数据生成子系统，用于确定目标业务场景关联的目标数据库，从服务端获得所述目标数据库中的相关数据，并根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件，并发布到缓存子系统中；所述缓存子系统，用于对所述离线数据文件进行缓存，并提供下载接口；终端设备，用于从所述缓存子系统中下载获得所述所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。通过本申请实施例，能够实现针对业务场景的完整容灾，避免加重客户端的业务逻辑。

Description

数据容灾处理方法、装置及系统

技术领域

本申请涉及数据容灾处理技术领域，特别是涉及数据容灾处理方法、装置及系统。

背景技术

POS(point of sale，销售终端)设备是消费者在线下实体店的支付入口。对于一些应用场景而言，支付时用到的商品数据、营销信息等需要实时从服务端获取，例如，其中包括具体的商品价格，用户所享受的优惠信息，等等。但是，一旦因为网络故障或者服务器故障就会造成POS机无法进行支付，严重影响了线下门店的运营，甚至引起顾客投诉等。

现有技术中，有些客户端设备具备一定的容灾功能，也即，即使网络故障或者服务器故障，也能够继续提供服务。但是根据业务场景的不同，使用的策略不尽相同。

例如，其中一种策略是采用按照接口维度进行容灾，即本地缓存上一次的请求结果，当出现网络问题时，继续使用上次的请求数据。但是这种容灾策略，无法针对某个应用场景进行完整的容灾，多用于非核心链路，适用于以UI(用户界面)展示为目的的数据展示场景。

另一种方案中，通过在客户端本地构建一个与服务端完全一致的数据库进行容灾和加速数据读取。之后，客户端可以每秒向服务端请求一次更新，以保持与服务端数据库的实时同步。这样，当网络或者服务端遇到故障时，可以使用本地数据库。但是，这种方案下，如果服务端数据库规模比较大，则在客户端构建完全一致的数据库几乎是不可能的。另外，服务端的数据库中保存的是原始数据，由于客户端构建了与服务端完全一致的数据库，因此，意味着当客户端使用本地数据库中的数据时，具体对数据进行筛选、加工等处理工作都需要由客户端来完成，这无疑会加重客户端的业务逻辑，引入了更多不稳定因素。因此这种策略更适合于面向Web应用的全栈式开发。例如，一些内容相关的门户网站等，可以使用这种策略。

而在门店中的POS机支付场景中，为了完成具体的支付，则需要与该业务场景相关的完整数据，因此，上述第一种方案并不适合。另外，具体业务场景所需的商品信息等数据库的规模通常会非常大，并且其中会包括多种不同维度上的数据表，例如，item表，SKU表，条码表，等等。在POS机本地构建如此大规模的数据库，几乎是不可能完成的任务，另外，也会加重POS的业务逻辑处理难度，这对于POS支付场景的稳定性而言是不可接受的。

因此，对于门店中的POS支付等业务场景，如何更有效的进行数据容灾，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了数据容灾处理方法、装置及系统，能够实现针对业务场景的完整容灾的同时，避免加重客户端的业务逻辑，实现客户端在使用离线数据过程中的轻量化。

本申请提供了如下方案：

一种数据容灾处理系统，包括：

离线数据生成子系统，用于确定目标业务场景关联的目标数据库，从服务端获得所述目标数据库中的相关数据，并根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件，并发布到缓存子系统中；

所述缓存子系统，用于对所述离线数据文件进行缓存，并提供下载接口；

终端设备，用于从所述缓存子系统中下载获得所述所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

一种数据容灾处理方法，包括：

确定终端设备中的目标业务场景关联的目标数据库；

从服务端获得所述目标数据库中的相关数据；

根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件；

将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

一种数据容灾处理方法，包括：

获得离线数据文件，所述离线数据文件是按照目标业务场景对应的业务处理逻辑，对所述目标业务场景关联的数据库中的相关数据进行筛选以及计算处理后生成的；

将所述离线数据文件保存在终端设备本地；

在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

一种数据容灾处理装置，包括：

目标数据库确定单元，用于确定终端设备中的目标业务场景关联的目标数据库；

相关数据获得单元，用于从服务端获得所述目标数据库中的相关数据；

离线数据文件生成单元，用于根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件；

离线数据文件发布单元，用于将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

一种数据容灾处理装置，包括：

离线数据文件获得单元，用于获得离线数据文件，所述离线数据文件是按照目标业务场景对应的业务处理逻辑，对所述目标业务场景关联的数据库中的相关数据进行筛选以及计算处理后生成的；

离线数据文件保存单元，用于将所述离线数据文件保存在终端设备本地；

离线数据文件使用单元，用于在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

确定终端设备中的目标业务场景关联的目标数据库；

从服务端获得所述目标数据库中的相关数据；

根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件；

将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以针对终端设备中具体业务场景所需的目标数据库，执行离线化处理。其中，在生成离线数据文件的过程中，还可以按照业务场景的具体业务处理逻辑，对数据库中的原始数据进行筛选、计算处理，这样，一方面可以使得离线数据文件在保证主要核心链路业务得以实现的情况下，规模不会太大，便于在终端设备本地进行保存；另一方面离线数据文件中保存的具体数据也不再是服务端数据库中的原始数据，而是按照具体的业务处理逻辑进行处理过的数据，因此，可以避免加重客户端的业务逻辑，实现客户端在使用离线数据过程中的轻量化。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的系统的示意图；

图2是本申请实施例提供的配置界面示意图；

图3是本申请实施例提供的第一方法的流程图；

图4是本申请实施例提供的第二方法的流程图；

图5是本申请实施例提供的第一装置的示意图；

图6是本申请实施例提供的第二装置的示意图；

图7是本申请实施例提供的计算机系统的示意图。

具体实施方式

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

在本申请实施例中，可以提供用于生成离线数据的平台，该平台主要针对客户端具体业务场景所需的数据库进行完整或者相对完整的离线化处理，并在生成离线数据的过程中，便可以按照具体业务场景中的业务处理逻辑对服务端数据库中的原始数据进行筛选以及计算处理等操作。这样，使得实际在终端设备本地保存的离线数据库中，具体的数据已经是经过了筛选以及计算处理的数据，在出现网络故障或者服务器故障时，使用这种离线数据库对业务的核心链路进行处理，并且，客户端不再需要对原始数据执行筛选、计算等处理，直接使用离线数据库中的数据即可。因此，在更有效是实现针对业务场景的完整容灾的同时，还避免加重POS的业务逻辑处理难度，提高稳定性。

下面对具体的实现方案进行详细介绍。

实施例一

首先，该实施例一提供了一种数据容灾处理系统，参见图1，该系统具体可以包括：

离线数据生成子系统101，用于确定目标业务场景关联的目标数据库，从服务端获得所述目标数据库中的相关数据，并根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件，并发布到缓存子系统中；

所述缓存子系统102，用于对所述离线数据文件进行缓存，并提供下载接口；

终端设备103，用于从所述缓存子系统中下载获得所述所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

其中，所述离线数据生成子系统以及缓存子系统都可以位于服务端，具体实现时，终端设备中的客户端具体涉及的业务场景，以及具体业务场景下需要哪些具体的数据库，服务端是预先获知的。另外，具体的终端设备可以是门店内的POS机等，当然，由于门店通常是分散在多个地理位置，同一门店中还可能有多台POS机等终端设备，由于在网络正常的情况下，这些设备信息需要从服务端获得业务场景相关的数据，因此，这些设备的信息显然对于服务端而言也都是可以预先获知的。这样，具体实现时，所述离线数据生成子系统还可以提供相关的配置界面，例如，具体可以参见图2，在该界面中，技术人员可以对具体所需进行离线化处理的业务场景，以及需要离线数据的终端设备进行配置。也就是说，具体对哪些业务场景进行离线化处理，以及具体哪些终端设备需要获得这种离线数据，都是可以预先进行配置的，后续在进行离线数据的生成，以及向终端设备执行的信息推送等操作，都可以以上述配置信息为依据来进行。

在确定了具体需要进行离线化处理的目标业务场景，及其对应的目标数据库之后，离线数据生成子系统便可以获得这种目标数据库的相关数据，然后，经过筛选、计算等处理，生成具体的离线数据文件，并发布到缓存子系统中，供终端设备进行下载。

具体实现时，所述离线数据生成子系统获得目标数据库的相关数据的具体方式可以有多种。例如，首先，针对目标数据库进行全量数据的离线化处理，也就是说，针对目标数据库中的全部数据，都进行离线化处理，使得终端设备可以保存相对完整的数据库文件。其中，这种全量数据的离线化处理，可以是按照预置的周期来执行的，也即，可以设定第一定时任务(例如，每5天执行一次等)，在第一定时任务的触发下，执行全量数据的离线化处理。其中，具体执行全量数据的离线化处理时，首先可以对所述服务端的目标数据库中的数据进行遍历，然后，根据所述目标业务场景对应的业务处理逻辑，对所述数据进行筛选以及计算处理后，生成端上可用的离线数据库文件。也就是说，可以将终端设备中具体业务场景对应的业务处理逻辑在离线数据生成子系统中来实现，这样，离线数据生成子系统可以利用这种业务逻辑对全量的离线数据进行筛选、计算处理，之后，生成离线数据库文件。可见，这种对全量数据进行的离线化处理，生成的是具体的数据库文件，这种数据库文件可以是端上常用的数据库文件格式，例如，sqlite数据库，等等。这种数据库文件生成并发布到缓存子系统之后，终端设备便可以进行下载，保存在本地。其中，由于上述离线数据库文件的生成是周期性进行的，因此，终端设备每次下载到新的离线数据库文件之后，都可以对之前的离线数据库文件进行替换操作，使得本地保存的是最新生成的离线数据库文件。

以上所述的对目标数据库执行的全量数据离线化处理的过程中，每次都需要遍历整个数据库，并进行数据的筛选、计算等处理，工作量会比较大，如果所述第一定时任务的周期比较短，则离线数据生成子系统的计算压力会比较大，并且，全量数据对应的离线数据库文件也会比较大，频繁的在服务端与终端设备之间发送这种离线数据库文件，造成的网络开销也比较大。再者，对于一些门店内的结算支付等应用场景中，结算及支付的频度通常并不会非常高，目标数据库中数据的更新频度也能并不是非常高，每次发生更新的数据也可能只是其中的一小部分，因此，频繁的进行全量数据的离线化处理，也显得没有必要。

基于以上所述，在本申请的优选实施例中，可以将前述第一定时任务的周期设置的相对比较长，例如，前文所述的5天，等等，当然，具体的周期长度还可以根据具体目标数据库中的数据更新特点来进行确定。而关于两次定时任务之间，数据库中可能发生的数据更新情况，则可以通过增量数据的方式来实现对终端设备中离线数据库的更新。

因此，所述离线数据生成子系统还可以用于，接收所述目标数据库的数据变更消息，并根据所述目标业务场景对应的业务处理逻辑，对所述发生变更的数据进行筛选以及计算处理后，生成增量数据文件；所述终端设备还用于，利用所述增量数据文件对所述离线数据库文件进行更新。

具体的，目标数据库中在发生数据变更时，可以向离线数据生成子系统推送相关的数据变更消息，这样，离线数据生成子系统便可以知晓目标数据库中的数据发生的变更，因此，可以生成具体的增量数据文件。所谓的增量数据文件，其中记录的是与上次全量数据对应的离线数据库文件相比，有哪些数据发生了变化，发生了怎样的变化，等等，这样，终端设备依据这种增量数据文件中的信息，对上次下载的离线数据库文件进行更新，便可以使得本地数据库中的数据，与服务端数据库中的数据保持一致。

其中，具体实现时，离线数据生成子系统在生成增量数据文件时，可以有多种策略。例如，一种方式下，可以是每收到一条数据变更消息，便判断是否需要更新到终端设备的离线数据库中，如果需要，则还可以进行计算处理，之后生成一个增量数据文件，发布到缓存子系统，供终端设备进行下载。

显然，上述方式下，可以使得终端设备本地数据的实时性比较高，但是，产生的增量数据文件数量会比较多，终端设备可能需要频繁的执行增量数据文件的下载，以及对本地离线数据库的更新操作。然而，在实际的业务场景中，终端设备中对数据的实时性要求可能并没有那么高，并不需要紧密的跟随服务端的数据变化。此时，上述高实时性的数据更新方式就成为一种浪费。

因此，在可选的实施方式中，所述离线数据生成子系统还可以设定第二定时任务，这样，在接收到目标数据库的数据变更消息后，首先可以将所述数据变更消息暂存在消息表中。之后，在第二定时任务触发后，再根据所述目标业务场景对应的业务处理逻辑，对所述消息表中的数据变更消息进行筛选以及计算处理后，生成所述增量数据文件。

也就是说，在该方式下，可以实现对数据变更消息的批量处理，例如，每15分钟触发一次增量数据文件的生成，这样，可以将15分钟内接收到的各条数据变更消息一起进行数据的筛选以及计算等处理操作，并生成增量数据文件，之后还可以进行打包、压缩等处理，再发布到缓存子系统中供终端设备进行下载。可见，这会使得增量数据文件的数量减少，也避免终端设备频繁的执行下载以及更新操作。

另外，由于终端设备在下载到具体的增量数据文件之后，需要利用该增量数据文件对本地的离线数据库文件进行更新，因此，如果增量数据文件中保存的只是变更后的具体数据，则客户端在接收到增量数据文件之后，还需要首先进行解析，与本地数据库文件中的数据进行比对等处理，才能生成具体的可执行语句，然后再执行具体的更新操作，显然，这也会使得客户端的处理逻辑变得复杂。为此，在可选的实施方式中，离线数据生成子系统在生成具体的增量数据文件时，便可以生成具体的可执行语句(例如，sql语句等)，而不是简单的记录具体的变更情况信息。这样，终端设备在下载了增量数据文件之后，便可以通过执行文件中的所述语句，将对应的增量数据更新到所述离线数据库中，从而进一步保证了终端设备在使用过程中的轻量化。

这里需要说明的是，如前文所述，无论是全量的离线数据库文件，还是增量数据文件，都是周期性生成的，而不同的终端设备，对离线数据文件的更新进度可能会不一致，因此，为了避免发生错误，所述离线数据生成子系统还可以为每次生成的离线数据文件提供版本信息，并保存在版本数据表中。其中，版本信息可以区分为全量的离线数据库文件的版本，以及增量数据文件的版本，也即，全量数据与增量数据分别进行版本的记录。

具体在为终端设备提供下载时，也可以有多种实现方式，例如，一种方式下，所述离线数据生成子系统还可以将最新生成的离线数据文件的版本信息推送至所述终端设备；这样，终端设备便可以获知已经有新的离线数据文件生成，因此，可以在接收到推送消息后，从所述缓存子系统中下载所述最新生成的离线数据文件。

或者，也可以采用由终端设备主动拉取的方式来实现。例如，具体的，所述终端设备具体可以在第三定时任务触发下，通过调用所述缓存子系统的应用程序编程接口API，获得最新生成的离线数据文件的版本信息，并通过比对本地保存的离线数据文件的版本与所述最新生成的离线数据文件的版本，确定是否需要下载最新生成的离线数据文件。如果需要，则从所述缓存子系统中下载所述最新生成的离线数据文件，之后，如果是全量的离线数据库文件，则对原有的离线数据库文件进行替换，如果是增量数据文件，则可以利用该增量数据文件对原有的离线数据库文件进行更新。

需要说明的是，在本申请实施例中，缓存子系统可以部署在服务端，具体实现时，由于终端设备的数量可能会非常多，因此，为了快速响应各个终端设备的下载请求，缓存子系统可以通过CDN(Content Delivery Network，内容分发网络)来实现。由于CDN可以尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，因此，可以使内容传输的更快、更稳定。

以上对本申请实施例提供的方案进行了详细介绍，在实际应用中，可以结合具体应用场景所需的数据库进行具体的处理。例如，在背景技术中所述的POS支付场景中，所述终端设备具体就可以是门店中使用的销售终端设备；所述目标业务场景包括所述销售终端中的结算支付场景；此时，所述目标数据库包括商品信息数据库以及营销策略信息数据库。

其中，所谓的商品信息数据库，其中保存有商品的具体信息，具体实现时，通常可能包括多个数据表，分别用于从不同的维度对商品信息进行记录。例如，包括item表、sku表、barcode表，等等。其中，item也即商品条目，一个商品在系统中可以对应一个item，item表中用于记录商品的基本信息，包括名称、品牌等等。sku也即最小库存量单位，sku表用于记录同一item在不同sku下的具体信息；barcode也即商品外包装上的条形码等，barcode表则用于记录与具体条码等图形码相关的信息。而所谓的营销策略信息数据库则是指具体的商品参加哪些活动，活动的具体优惠策略信息，等等。通常，用户在门店中购买的某件商品，在通过POS机结算时，其价格信息是通过所述商品信息数据库中记录的原始价格等信息，结合所述营销策略信息数据库中的营销策略信息，共同确定的。例如，某商品的原始价格是100元，通过查询所述营销策略信息数据库发现，该商品参见满100减5元的活动，且不带附加条件，则实际返回的价格是95元，等等。

可见，商品信息数据库的规模可能会比较大，如果在客户端本地实现与服务端完全一致的商品信息数据库几乎是不可能的。另外，在网络状态良好，且服务端正常的情况下，POS机的结算请求会发送到服务端，服务端根据具体的业务处理逻辑对数据库中的原始数据进行处理之后，再返回给POS机设备，POS机设备直接获得商品对应的实际所需支付的价格信息。

而在本申请实施例中，为了使得针对具体业务场景实现完整的容灾，所述离线数据生成子系统可以按照所述结算支付场景的业务处理逻辑，从所述商品信息数据库中筛选出与商品图形码以及资源信息相关的信息，从所述营销策略信息数据库中筛选出未关联用户标识的通用型营销策略信息。而为了实现客户端在使用离线数据过程中的轻量化，并对筛选出的信息进行计算处理。具体的计算处理可以根据实际情况需要而定，例如，在同一商品对象对应的资源信息为多条时，按照所述业务处理逻辑，从中筛选出一条资源信息。具体如，某商品的价格信息包括“原价”以及“一口价”，而最终在进行结算时，只需要其中一个价格较低者即可，因此，所述的计算处理就可以是，比较两个不同的价格，选择出其中的较低者，用于生成所述离线数据文件，等等。

需要说明的是，对于前述营销策略信息数据库，由于具体的营销策略可能会分为多种，例如，有些营销策略可能是针对所有用户通用的，而有些策略则是为特殊用户提供的，例如，为门店的会员用户提供的优惠，或者，一些用户由于完成了某些指定任务而获得的专用的优惠，等等。而在本申请实施例中，具体的离线数据文件是提供给POS机等设备中，这种设备对于具体的消费者用户而言，属于公用的设备，因此，不适合将与具体用户相关的营销信息进行离线化处理。为此，在具体实现时，在对营销策略信息数据库中的数据进行筛选时，除了考虑具体业务处理逻辑，还可以判断具体数据是否关联有特定的用户标识，也即，是否为某个或者某些用户所专用，如果不带有用户标识，则属于通用性的营销策略，因此，可以选择出来进行离线化数据处理。否则，如果带有用户标识，则不必进行离线化处理。当然，在这种将营销策略信息数据库进行部分离线化处理的方式下，可能会导致终端设备中保存的数据库信息不够完整，但是，由于已经保存了通用型的营销策略信息，因此，至少可以保证核心链路的业务得以正常进行。

以上仅针对POS支付场景进行了简单的介绍，在实际应用中，本申请实施例还可以针对其他的业务场景进行类似的处理，例如，POS终端中的小票打印场景，在该业务场景中，可以为具体门店提供在小票上打印商家自定义文案信息的功能，通常，具体的文案信息是保存在服务端的数据库中，为了使得在网络故障、服务器故障时也能使用上述功能，也可以对上述文案信息数据库进行离线化处理，等等。

总之，通过本申请实施例，可以针对终端设备中具体业务场景所需的目标数据库，执行离线化处理。其中，在生成离线数据文件的过程中，还可以按照业务场景的具体业务处理逻辑，对数据库中的原始数据进行筛选、计算处理，这样，一方面可以使得离线数据文件在保证主要核心链路业务得以实现的情况下，规模不会太大，便于在终端设备本地进行保存；另一方面离线数据文件中保存的具体数据也不再是服务端数据库中的原始数据，而是按照具体的业务处理逻辑进行处理过的数据，因此，可以避免加重客户端的业务逻辑，实现客户端在使用离线数据过程中的轻量化。

实施例二

该实施例二是与实施例一对应的，从离线数据生成子系统的角度，提供了一种数据容灾处理方法，参见图3，该方法具体可以包括：

S301：确定终端设备中的目标业务场景关联的目标数据库；

S302：从服务端获得所述目标数据库中的相关数据；

S303：根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件；

S304：将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

具体实现时，首先可以执行全量数据的离线化处理。此时，可以在第一定时任务触发后，对所述服务端的目标数据库中的数据进行遍历，获得所述相关数据；之后，可以生成端上可用的离线数据库文件。

另外，还可以接收所述目标数据库的数据变更消息，根据所述数据变更消息确定所述相关数据；此时，可以在对所述发生变更的数据进行筛选以及计算处理后，生成增量数据文件。

其中，具体在生成增量数据文件的过程中，可以先将所述数据变更消息暂存在消息表中；然后，在第二定时任务触发后，将所述消息表中暂存的各条数据变更消息对应的数据条目，确定为所述相关数据。

为了便于客户端执行具体的数据库更新操作，在对所述发生变更的数据进行筛选以及计算处理时，可以根据所述发生变更的数据生成可执行语句，以便所述终端设备通过执行所述语句，将对应的增量数据更新到所述离线数据库中。

另外，还可以为每次生成的离线数据文件提供版本信息，并保存在版本数据表中。

具体实现时，还可以将最新生成的离线数据文件的版本信息推送至所述终端设备，以通知所述终端设备对所述最新生成的离线数据文件进行下载。

其中，在一种具体的应用场景中，所述终端设备包括门店中使用的销售终端设备；所述目标业务场景包括所述销售终端中的结算支付场景；此时，所述目标数据库包括商品信息数据库以及营销策略信息数据库。

此时，具体在对所述相关数据进行筛选以及计算处理时，可以按照所述结算支付场景的业务处理逻辑，从所述商品信息数据库中筛选出与商品图形码以及资源信息相关的信息；从所述营销策略信息数据库中筛选出未关联用户标识的通用型营销策略信息；并对筛选出的信息进行计算处理。

实施例三

该实施例三是从终端设备的角度，提供了一种数据容灾处理方法，参见图4，该方法具体可以包括：

S401：获得离线数据文件，所述离线数据文件是按照目标业务场景对应的业务处理逻辑，对所述目标业务场景关联的数据库中的相关数据进行筛选以及计算处理后生成的；

S402：将所述离线数据文件保存在终端设备本地；

S403：在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

具体的，所述离线数据文件包括：通过遍历所述目标数据库，并进行筛选及计算处理后生成的端上可用的离线数据库文件；此时，可以新获得的离线数据库文件进行离线数据库文件的替换。

或者，所述离线数据文件还包括：根据所述目标数据库提供的数据变更消息以及所述业务处理逻辑，对所述发生变更的数据进行筛选以及计算处理后，生成的增量数据文件；此时，利用所述增量数据文件对所述离线数据库文件进行更新。

其中，所述增量数据文件中可以包括可执行语句，此时，可以通过执行所述语句，将对应的增量数据更新到所述离线数据库中。

关于上述实施例二、三中的未详述部分，可以参见前述实施例一中的记载，这里不再赘述。

与实施例二相对应，本申请实施例还提供了一种数据容灾处理装置，参见图5，该装置可以包括：

目标数据库确定单元501，用于确定终端设备中的目标业务场景关联的目标数据库；

相关数据获得单元502，用于从服务端获得所述目标数据库中的相关数据；

离线数据文件生成单元503，用于根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件；

离线数据文件发布单元504，用于将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

具体实现时，所述相关数据获得单元具体可以用于：

在第一定时任务触发后，对所述服务端的目标数据库中的数据进行遍历，获得所述相关数据；

所述离线数据文件生成单元具体可以包括：

全量离线数据库文件生成子单元，用于生成端上可用的离线数据库文件。

另外，所述所述相关数据获得单元还可以用于：

接收所述目标数据库的数据变更消息，根据所述数据变更消息确定所述相关数据；

所述离线数据文件生成单元具体可以包括：

增量数据文件生成子单元，用于对所述发生变更的数据进行筛选以及计算处理后，生成增量数据文件。

具体实现时，所述相关数据获得单元具体可以用于：

暂存子单元，用于将所述数据变更消息暂存在消息表中；

数据确定子单元，用于在第二定时任务触发后，将所述消息表中暂存的各条数据变更消息对应的数据条目，确定为所述相关数据。

具体的，所述增量数据文件生成子单元具体可以用于：

根据所述发生变更的数据生成可执行语句，以便所述终端设备通过执行所述语句，将对应的增量数据更新到所述离线数据库中。

另外，该装置还可以包括：

版本记录单元，用于为每次生成的离线数据文件提供版本信息，并保存在版本数据表中。

推送单元，用于将最新生成的离线数据文件的版本信息推送至所述终端设备，以通知所述终端设备对所述最新生成的离线数据文件进行下载。

具体实现时，所述终端设备包括门店中使用的销售终端设备；

所述目标业务场景包括所述销售终端中的结算支付场景；

所述目标数据库包括商品信息数据库以及营销策略信息数据库。

此时，所述离线数据文件生成单元具体可以用于：

按照所述结算支付场景的业务处理逻辑，从所述商品信息数据库中筛选出与商品图形码以及资源信息相关的信息；从所述营销策略信息数据库中筛选出未关联用户标识的通用型营销策略信息；对筛选出的信息进行计算处理。

与实施例三相对应，本申请实施例还提供了一种数据容灾处理装置，参见图6，该装置可以包括：

离线数据文件获得单元601，用于获得离线数据文件，所述离线数据文件是按照目标业务场景对应的业务处理逻辑，对所述目标业务场景关联的数据库中的相关数据进行筛选以及计算处理后生成的；

离线数据文件保存单元602，用于将所述离线数据文件保存在终端设备本地；

离线数据文件使用单元603，用于在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

具体的哦，所述离线数据文件包括：通过遍历所述目标数据库，并进行筛选及计算处理后生成的端上可用的离线数据库文件；

所述离线数据文件保存单元具体可以用于：

新获得的离线数据库文件进行离线数据库文件的替换。

或者，所述离线数据文件还包括：根据所述目标数据库提供的数据变更消息以及所述业务处理逻辑，对所述发生变更的数据进行筛选以及计算处理后，生成的增量数据文件；

所述离线数据文件保存单元具体可以用于：

利用所述增量数据文件对所述离线数据库文件进行更新。

其中，所述增量数据文件中包括可执行语句；

所述离线数据文件保存单元具体可以用于：通过执行所述语句，将对应的增量数据更新到所述离线数据库中。

另外，对应于实施例二，本申请实施例还提供了一种计算机系统，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

确定终端设备中的目标业务场景关联的目标数据库；

从服务端获得所述目标数据库中的相关数据；

根据所述目标业务场景对应的业务处理逻辑，对所述相关数据进行筛选以及计算处理后，生成离线数据文件；

将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述目标业务场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

其中，图7示例性的展示出了计算机系统的架构，具体可以包括处理器710，视频显示适配器711，磁盘驱动器712，输入/输出接口713，网络接口714，以及存储器720。上述处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720之间可以通过通信总线730进行通信连接。

其中，处理器710可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器720可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器720可以存储用于控制计算机系统700运行的操作系统721，用于控制计算机系统700的低级别操作的基本输入输出系统(BIOS)。另外，还可以存储网页浏览器723，数据存储管理系统724，以及数据容灾处理系统725等等。上述数据容灾处理系统725就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器720中，并由处理器710来调用执行。

输入/输出接口713用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口714用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线730包括一通路，在设备的各个组件(例如处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720)之间传输信息。

另外，该计算机系统700还可以从虚拟资源对象领取条件信息数据库741中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，存储器720，总线730等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的数据容灾处理方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (27)

1.一种数据容灾处理系统，其特征在于，包括：

离线数据生成子系统，用于确定销售终端中的结算支付场景关联的目标数据库，所述目标数据库包括商品信息数据库，从服务端获得所述目标数据库中的相关数据，并根据所述结算支付场景对应的业务处理逻辑，从所述商品信息数据库中筛选出与商品图形码以及资源信息相关的信息，并对筛选出的信息进行计算处理后，生成离线数据文件，并发布到缓存子系统中；

所述缓存子系统，用于对所述离线数据文件进行缓存，并提供下载接口；

门店中使用的销售终端设备，用于从所述缓存子系统中下载获得所述所述离线数据文件，并保存在本地，在所述结算支付场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

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

所述离线数据生成子系统具体用于，在第一定时任务触发后，对所述服务端的目标数据库中的数据进行遍历，并根据所述结算支付场景对应的业务处理逻辑，对所述数据进行筛选以及计算处理后，生成端上可用的离线数据库文件；

所述终端设备具体用于，利用新下载到的离线数据库文件进行离线数据库文件的替换。

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

所述离线数据生成子系统还用于，接收所述目标数据库的数据变更消息，并根据所述结算支付场景对应的业务处理逻辑，对发生变更的数据进行筛选以及计算处理后，生成增量数据文件；

所述终端设备还用于，利用所述增量数据文件对所述离线数据库文件进行更新。

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

所述离线数据生成子系统具体用于，将所述数据变更消息暂存在消息表中，并在第二定时任务触发后，根据所述结算支付场景对应的业务处理逻辑，对所述消息表中的数据变更消息进行筛选以及计算处理后，生成所述增量数据文件。

5.根据权利要求3所述的系统，其特征在于，

所述增量数据文件中包括可执行语句；

所述终端设备具体用于，通过执行所述语句，将对应的增量数据更新到所述离线数据库中。

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

所述离线数据生成子系统还用于，为每次生成的离线数据文件提供版本信息，并保存在版本数据表中。

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

所述离线数据生成子系统还用于，将最新生成的离线数据文件的版本信息推送至所述终端设备；

所述终端设备具体用于，在接收到推送消息后，从所述缓存子系统中下载所述 最新生成的离线数据文件。

8.根据权利要求6所述的系统，其特征在于，

所述终端设备具体用于，在第三定时任务触发下，通过调用所述缓存子系统的应用程序编程接口API，获得最新生成的离线数据文件的版本信息，并通过比对本地保存的离线数据文件的版本与所述最新生成的离线数据文件的版本，确定是否需要下载最新生成的离线数据文件。

9.根据权利要求1至8任一项所述的系统，其特征在于，

所述目标数据库还包括营销策略信息数据库。

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

所述离线数据生成子系统具体用于，按照所述结算支付场景的业务处理逻辑，从所述营销策略信息数据库中筛选出未关联用户标识的通用型营销策略信息。

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

所述离线数据生成子系统具体用于，在同一商品对象对应的资源信息为多条时，按照所述业务处理逻辑，从中筛选出一条资源信息。

12.一种数据容灾处理方法，其特征在于，包括：

确定门店中使用的销售终端设备中的销售终端中的结算支付场景关联的目标数据库，所述目标数据库包括商品信息数据库；

从服务端获得所述目标数据库中的相关数据；

根据所述结算支付场景对应的业务处理逻辑，从所述商品信息数据库中筛选出与商品图形码以及资源信息相关的信息，并对筛选出的信息进行计算处理后，生成离线数据文件；

将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述结算支付场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

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

所述从服务端获得所述目标数据库中的相关数据，包括：

在第一定时任务触发后，对所述服务端的目标数据库中的数据进行遍历，获得所述相关数据；

所述生成离线数据文件，包括：

生成端上可用的离线数据库文件。

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

所述从服务端获得所述目标数据库中的相关数据，还包括：

接收所述目标数据库的数据变更消息，根据所述数据变更消息确定所述相关数据；

所述生成离线数据文件，包括：

对发生变更的数据进行筛选以及计算处理后，生成增量数据文件。

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

所述根据所述数据变更消息确定所述相关数据，包括：

将所述数据变更消息暂存在消息表中；

在第二定时任务触发后，将所述消息表中暂存的各条数据变更消息对应的数据条目，确定为所述相关数据。

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

所述对发生变更的数据进行筛选以及计算处理，包括：

根据所述发生变更的数据生成可执行语句，以便所述终端设备通过执行所述语句，将对应的增量数据更新到所述离线数据库中。

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

为每次生成的离线数据文件提供版本信息，并保存在版本数据表中。

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

将最新生成的离线数据文件的版本信息推送至所述终端设备，以通知所述终端设备对所述最新生成的离线数据文件进行下载。

19.根据权利要求12至18任一项所述的方法，其特征在于，

所述目标数据库还包括营销策略信息数据库。

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

还包括：

按照所述结算支付场景的业务处理逻辑，从所述营销策略信息数据库中筛选出未关联用户标识的通用型营销策略信息。

21.一种数据容灾处理方法，其特征在于，包括：

获得离线数据文件，所述离线数据文件是按照销售终端中的结算支付场景对应的业务处理逻辑，从所述结算支付场景关联的商品信息数据库中筛选出与商品图形码以及资源信息相关的信息，并对筛选出的信息进行计算处理后生成的；

将所述离线数据文件保存在门店中使用的销售终端设备本地；

在所述结算支付场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

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

所述离线数据文件包括：通过遍历所述商品信息数据库，并进行筛选及计算处理后生成的端上可用的离线数据库文件；

所述将所述离线数据文件保存在终端设备本地，包括：

新获得的离线数据库文件进行离线数据库文件的替换。

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

所述离线数据文件还包括：根据所述商品信息数据库提供的数据变更消息以及所述业务处理逻辑，对发生变更的数据进行筛选以及计算处理后，生成的增量数据文件；

所述将所述离线数据文件保存在终端设备本地，包括：

利用所述增量数据文件对所述离线数据库文件进行更新。

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

所述增量数据文件中包括可执行语句；

所述利用所述增量数据文件对所述离线数据库文件进行更新，包括：

通过执行所述语句，将对应的增量数据更新到所述离线数据库中。

25.一种数据容灾处理装置，其特征在于，包括：

目标数据库确定单元，用于确定门店中使用的销售终端设备中的销售终端中的结算支付场景关联的目标数据库，所述目标数据库包括商品信息数据库；

相关数据获得单元，用于从服务端获得所述目标数据库中的相关数据；

离线数据文件生成单元，用于根据所述结算支付场景对应的业务处理逻辑，从所述商品信息数据库中筛选出与商品图形码以及资源信息相关的信息，并对筛选出的信息进行计算处理后，生成离线数据文件；

离线数据文件发布单元，用于将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述结算支付场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

26.一种数据容灾处理装置，其特征在于，包括：

离线数据文件获得单元，用于获得离线数据文件，所述离线数据文件是按照销售终端中的结算支付场景对应的业务处理逻辑，从所述结算支付场景关联的商品信息数据库中筛选出与商品图形码以及资源信息相关的信息，并对对筛选出的信息进行计算处理后生成的；

离线数据文件保存单元，用于将所述离线数据文件保存在门店中使用的销售终端设备本地；

离线数据文件使用单元，用于在所述结算支付场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

27.一种计算机系统，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

确定门店中使用的销售终端设备中的销售终端中的结算支付场景关联的目标数据库，所述目标数据库包括商品信息数据库；

从服务端获得所述目标数据库中的相关数据；

根据所述结算支付场景对应的业务处理逻辑，从所述商品信息数据库中筛选出与商品图形码以及资源信息相关的信息，并对筛选出的信息进行计算处理后，生成离线数据文件；

将所述离线数据文件发布到缓存子系统中，以便所述终端设备从所述缓存子系统中下载获得所述离线数据文件，并保存在本地，在所述结算支付场景下，如果出现网络故障或服务端故障，则利用所述离线数据文件执行提供的服务。

Images