CN109308643A - 一种打底数据生成方法、数据容灾方法及相关设备 - Google Patents

Abstract

本申请提供了打底数据生成方法、系统及相关设备，还提供了数据容灾方法及装置，在本申请的方案中，当客户端需要数据容灾时，客户端通过业务的前后端组件路由到存储设备中，从存储设备中获取与业务对应的当前可用版本的打底数据；在业务的资源位上渲染打底数据。由于打底数据生成系统能够自动化地为业务提供满足多样性要求的多版本的打底数据，打底数据是根据业务实际进展而实时更新的，因此，客户端获取的打底数据是具有时效性的，也具有业务具体特性，与现有技术的打底数据固定不变、业务具体特性不区分的情况相比，本申请能够做到真正的用户对故障的零感知。

Description

一种打底数据生成方法、数据容灾方法及相关设备

技术领域

本申请涉及互联网技术领域，特别涉及一种用于数据容灾的打底数据生成方法、系统、相关设备，以及一种数据容灾的方法和装置。

背景技术

在电子商务平台中，数据量开始成爆炸性增长，数据价值也越来越高，因此，数据容灾就显得尤为重要。数据容灾是电子商务平台为了在系统出现故障时能够及时有效的恢复数据的手段，用于保障业务的稳定性，使用户对故障零感知。

目前，电子商务平台的数据容灾方法是：针对每个业务，由业务方提前准备好打底数据，当系统发生故障时，向用户推送该打底数据。目前这种数据容灾方法无法满足业务发展多样化和高时效性的业务需求。

发明内容

有鉴于此，本申请提供了一种用于数据容灾的打底数据生成系统，该系统能够对用户使用的客户端进行实时流量采样，自动地将用户实际看到的业务数据作为具体业务对应的打底数据，记录并存储在存储设备中，一旦某个客户端故障需要数据容灾，就从存储设备中获取与具体业务相关的打底数据来实现数据容灾。由于打底数据是基于业务的实际进展而同步的生成，并且打底数据是基于业务实际参数而确定的，因此，打底数据既能够满足业务的时效性需求，又能够满足业务多样性需求。

在本申请第一方面提供了一种用于数据容灾的打底数据生成系统，包括：

数据处理设备，用于响应于客户端发送的业务数据请求反馈业务数据，并从所述业务数据请求中提取业务打底参数；

数据采集设备，用于从所述数据处理设备中采集与所述业务打底参数对应的所述业务数据，将所述业务数据作为打底数据存储在所述存储设备中；

存储设备，用于存储所述打底数据。

在本申请第二方面提供了一种用于数据容灾的打底数据生成方法，该方法应用于数据处理设备，该方法包括：

响应于客户端发送的业务数据请求反馈业务数据；

从所述业务数据请求中提取业务打底参数；

接收数据采集设备发送的采集请求，反馈与所述业务打底参数对应的所述业务数据。

在本申请第三方面提供了一种用于数据容灾的打底数据生成方法，该方法应用于数据采集设备，该方法包括：

向数据处理设备发送采集请求，接收所述数据处理设备反馈的与业务打底参数对应的业务数据；

根据所述业务打底参数和所述业务数据的对应关系，将所述业务数据作为打底数据存储在存储设备中。

在本申请第四方面提供了一种数据处理设备，该数据处理设备包括：

第一响应模块，用于响应于客户端发送的业务数据请求反馈业务数据；

提取模块，用于从所述业务数据请求中提取业务打底参数；

第二响应模块，用于接收所述数据采集设备发送的采集请求，反馈与所述业务打底参数对应的所述业务数据。

在本申请第五方面提供了一种数据采集设备，该数据采集设备包括：

采集模块，用于向数据处理设备发送采集请求，接收所述数据处理设备反馈的与业务打底参数对应的业务数据；

存储模块，用于根据所述业务打底参数与所述业务数据之间的对应关系，将所述业务数据作为打底数据存储在存储设备中。

在本申请第六方面提供了一种数据容灾方法，该方法应用于客户端，该方法包括：

监控客户端的业务是否满足预设的容灾场景；

若是，则路由到存储设备中，从所述存储设备中获取与所述业务对应的当前可用版本的打底数据；其中，所述存储设备用于存储数据采集设备从数据处理系统中采集的打底数据，所述打底数据是所述数据处理系统在响应客户端业务数据请求的同时根据业务数据而确定的；

在所述业务的资源位上渲染所述打底数据。

在本申请第七方面提供了一种数据容灾装置，该装置应用于客户端，该装置包括：

监控模块，用于监控客户端的业务是否满足预设的容灾场景；若是，执行打底数据获取模块；

获取模块，用于路由到存储设备中，从所述存储设备中获取与所述业务对应的当前可用版本的打底数据；其中，所述存储设备用于存储数据采集设备从数据处理系统中采集的打底数据，所述打底数据是所述数据处理系统在响应客户端业务数据请求的同时根据业务数据而确定的；

渲染模块，用于在所述业务的资源位上渲染所述打底数据。

与现有技术相比，本申请包括以下优点：

在本申请中，数据处理设备与客户端实时通信，在为客户端提供业务数据支持的同时，通过对业务数据请求的再处理，提取出业务打底参数，将该业务打底参数与该业务数据作为打底数据的数据源。然后数据采集设备从数据处理系统中获取与业务打底参数对应的业务数据，将该业务数据就作为打底数据存储在存储设备中。可见：通过数据处理设备和数据采集设备的共同作用，能够实时地生成具有业务时效性和业务多样性的打底数据。

在本申请中，当客户端需要数据容灾时，客户端将业务数据请求路由到存储设备中，从存储设备中获取与业务对应的当前可用版本的打底数据；在业务的资源位上渲染打底数据。由于打底数据生成系统是自动化地为业务提供多版本的打底数据，打底数据是根据业务实际进展而实时更新的，因此，客户端获取的打底数据是具有时效性的，也具有业务具体特性，与现有技术的打底数据固定不变、业务具体特性不区分的情况相比，本申请能够做到真正的用户对故障的零感知。

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

附图说明

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

图1是本申请在实际应用中的场景框架图；

图2是本申请实施例提供的一种打底数据生成系统的结构图；

图3是本申请实施例提供的数据处理设备侧的打底数据生成方法的流程图；

图4是本申请实施例提供的数据采集设备侧的打底数据生成方法的流程图；

图5是本申请实施例提供的数据容灾方法的流程图；

图6是本申请实施例提供的关于打底数据生成方法及数据容灾方法的实现过程的示意图；

图7是本申请实施例提供的数据处理设备的结构图；

图8是本申请实施例提供的数据采集设备的结构图；

图9是本申请实施例提供的数据容灾装置的结构图。

具体实施方式

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

发明人在研究过程中发现，现有技术中针对一个业务预先生成一份打底数据，这份打底数据随着业务的实时进展将越来越没用实际意义，由于这份打底数据是预先准备好的，随着业务进展，数据的更新，这份打底数据基本无法满足对时效性要求较高的业务，很可能给用户推出的过期数据，那么用户将会明显感知到业务故障，这种数据容灾方式的效果并不理想。

此外，发明人还发现，当某业务有更细粒度的划分时，打底数据将无法满足数据容灾对打底数据的业务多样性的需求。例如：在电子商务平台中，某个业务需要针对不同的区域展示不同的业务数据，但现有技术针对这个业务仅有一份打底数据，一旦该业务故障，也只能展示这一份打底数据，这样，不同区域的用户就只能看到同样的数据，这就违背了业务规则，限制了用户操作。因此，现有技术无法满足业务细粒度划分对数据的多样性需求。

基于此，本申请提供的用于数据容灾的打底数据生成系统、方法及其相关设备，另外本申请还提供了数据容灾方法和装置。在本申请的方案中，打底数据是指数据容灾时所需要使用的数据。下文将对本申请提供的各个方案进行介绍。

首先结合图1，对本申请在实际应用中的场景进行解释说明。参考图1所示，为本申请的方案在实际应用中的场景框架图，其中，第一客户端100与第二客户端300具有相同业务功能，但第一客户端100是指在运行业务，需要获取业务数据的客户端，而第二客户端300是指在运行业务时由于故障，需要数据容灾的客户端。

在实际应用中，在软件层面上，第一客户端100和第二客户端300可以是独立的应用程序，或者，还可以是一些综合性应用程序中的功能模块等，例如，可以是“手机淘宝”、“淘宝”等移动终端App中的功能模块，等等。在硬件层面上，第一客户端100和第二客户端300均可以配置在用户个人终端中，用户个人终端是指能够安装应用，并且能够与数据处理设备通信的设备，如智能手机、平板电脑，等等。而打底数据生成系统200包括数据处理设备，数据采集设备和存储设备，这些设备分别为独立的设备，而关于这些设备的具体结构请参见下文的图5和图6所示实施例的实现。

在实际应用中，第一客户端100与打底数据生成系统200中的数据处理系统进行通信以实现业务，数据处理系统在为客户端提供正常的业务数据支持的同时，收集业务打底参数和对应的业务数据，这些数据成为打底数据的数据源，进而数据采集系统采集得到打底数据并存储存储设备中，以供数据容灾。可见，打底数据生成系统200在为第一客户端100提供业务数据支持的过程中，在不对客户端正常业务产生任何影响的情况下，就能够自动地实时地将业务数据记录并存储为打底数据，这些打底数据是真实的业务数据，并且是随着实际业务进展而实时更新的，其具有时效性和多样性。以此为基础，当第二客户端300需要数据容灾时，则直接从存储设备中获取对应业务的打底数据，这种方式能够保证数据容灾的实时性，并能够保证满足业务多样性需求。

下面对本申请提供的打底数据生成系统进行介绍。

参见图2，图2为本申请实施例提供的一种打底数据生成系统的结构图；如图2所示，打底数据生成系统，包括：

数据处理设备700，用于响应于客户端发送的业务数据请求反馈业务数据，并从所述业务数据请求中提取业务打底参数，缓存所述业务打底参数和所述业务数据，生成通知消息以通知所述数据采集设备采集数据；优选地，该数据处理设备700的处理过程可参见图3所示实施例来实现。

数据采集设备800，用于根据所述通知消息，从所述数据处理设备中采集与所述业务打底参数对应的业务数据，将所述业务数据作为打底数据存储在所述存储设备中；优选地，该数据采集设备800的处理过程可参见图4所示实施例来实现。

存储设备900，用于存储所述打底数据。

从硬件实现上来讲，数据处理设备700和数据采集设备800均可以采用集群服务器设备来实现，存储设备900可以采用分布式缓存、分布式数据库、云存储等等任意一种或多种组合的硬件部署设备来实现。

利用本申请实施例提供的打底数据生成系统，在业务进展地过程中，在不影响业务正常进行的同时，同步地生成与业务特征对应的打底数据，在存储设备中实时地更新存储业务对应的打底数据，这些打底数据具有很高的时效性和业务特性，能够满足数据容灾对数据时效性和业务多样性的需求。

下面对本申请提供的打底数据生成方法进行介绍。

参见图3，图3为本申请实施例提供的数据处理设备侧的打底数据生成方法的流程图，该方法包括：步骤301-步骤303。

步骤301：数据处理设备响应于客户端发送的业务数据请求反馈业务数据。

在具体实现时，客户端根据实际业务需求向数据处理设备发送业务数据请求，该业务数据请求中携带有业务标识、业务相关参数等内容；数据处理设备接收到该业务数据请求之后，根据业务数据请求中携带的内容为客户端反馈对应的业务数据，客户端接收到该业务数据后渲染页面。这一过程是客户端运行业务的正常数据处理过程，本申请实施例正是在数据处理设备执行这一过程中，为客户端提供业务数据支持的过程中，在不影响这一过程实现的情况下，再通过以下步骤302-303挖掘出能够作为打底数据的业务数据。

在具体实现时，不同应用承载业务类型和数量都不相同，但本申请中并不关注业务的具体类型和数量，下面仅天猫应用为例进行说明。

举例说明：在天猫应用中承载有许多业务，例如“苏宁易购”、“天猫超市”、“天猫国际”“聚划算”、“每日优选”等等业务。

下面先以“每日优选”为例来进行说明，参见表1。

表1

用户A1，在时间为12:00:00时刻，通过天猫客户端发起业务数据请求1，以获取“每日优选”业务对应的数据1；其中，数据1就是数据处理设备针对业务数据请求1而反馈的与“每日优选”业务对应的业务数据。

用户B1，在时间为12:10:00时刻，通过天猫客户端发起业务数据请求2，以获取“每日优选”业务对应的数据2；其中，数据2就是数据处理设备针对业务数据请求2而反馈的与“每日优选”业务对应的业务数据。

再以“天猫超市”为例，参见表2

针对天猫应用中的业务“天猫超市”，“天猫超市”的业务数据具有区域性和时间性，关于区域性和时间性在该场景下，可以理解为，不同区域所销售的商品不同，在同一区域的不同时间段内销售的商品也不同，或者在不同时间段内销售的商品价格不同，即，该业务在特定区域或者特定时间段内对应的业务数据不同。

表2

用户A2，所选区域是北京东城区，在时间为13:00:00时刻，通过天猫客户端发起业务数据请求4，以获得“天猫超市”业务下北京东城区所对应的数据4；其中，数据4就是数据处理设备针对业务数据请求1而反馈的与“天猫超市”业务对应的业务数据。

用户B2，所选区域也是北京东城区，在时间为13:10:00时刻，通过天猫客户端发起业务数据请求5，以获得“天猫超市”业务下北京东城区所对应的数据5；其中，数据5就是数据处理设备针对业务数据请求5而反馈的与“天猫超市”业务对应的业务数据。

用户C2，所选区域是上海黄浦区,在时间为13:10:00时刻，通过天猫客户端发起业务数据请求6，以获得“天猫超市”业务下北京东城区所对应的数据6；其中，数据6就是数据处理设备针对业务数据请求6而反馈的与“天猫超市”业务对应的业务数据。

步骤302：数据处理设备从所述业务数据请求中提取业务打底参数。

在具体实现时，在电子商务平台中由于不同业务的业务划分粒度不同，为了针对性地为业务提供满足业务多样性需求的打底数据的数据源，数据处理设备要根据业务的具体情况提取所需的业务打底参数。

优选地，数据处理设备根据预设的业务打底参数白名单，对所述业务数据请求中的业务相关参数进行过滤得到业务打底参数。其中，预设的业务打底参数白名单包括：一个或者多个业务各自对应的业务打底参数。由于业务数据请求中会包含一些对打底无用的参数，因此通过过滤操作可以得到纯净参数，只供打底所需即可。

优选地，数据处理设备在提取出业务打底参数之后，还缓存所述业务打底参数和所述业务数据，并生成通知消息以通知数据采集设备。

在具体实现时，数据处理设备利用通过消息以通知数据采集设备进行打底数据的采集，但在下发通知消息时，数据处理设备需要考虑消息下发的数据量和频率不会对线上集群正常业务造成影响，需要综合考虑网卡、磁盘对于集群性能的影响。

优选地，数据处理设备可以按照预设的统一参数结构形式缓存所述业务打底参数，并缓存与所述业务打底参数对应的所述业务数据。

为了便于统一管理，减少缓存，按照预设的统一参数结构形式组织业务打底参数，同时也方便数据采集设备采集打底数据。

在具体实现时，电子商务平台针对同一业务，在不同的端进行展示时，其业务数据本质相同，但其格式并不相同，例如电子商务平台支持三种端口，分别是HTTP，HSF，MTOP，基于这三种端口的业务数据请求格式不相同，分别是url(http)、ParamMap(HSF,MTOP)。而不同的端口传送的相同的业务数据请求时，其传输的业务数据本质相同，但其格式却不相同，为了方便打底数据的采集，在本申请中对不同端口的业务数据请求的均作统一处理，提取出业务打底参数，并按照统一格式管理。当然，除了在电子商务平台之外，在其他平台或者系统中，也会存在以上技术场景，在本申请中只是为了方便描述以电子商务平台为例来进行介绍。

基于以上应用场景，在具体实现时，所述数据处理设备可具有为所述数据采集设备开放的打底接口，所述数据处理设备，具体用于通过所述打底接口根据所述数据采集设备的采集请求，针对不同的客户端类型，反馈不同格式的业务数据。这样，就能够对同一业务的业务数据进行统一管理，通过接口操作来实现针对不同端维护不同格式的打底数据。

在实际应用中，数据处理设备在同一时间点会接收到多个客户端针对同一业务发送的相同的业务数据请求，在这种情况下，数据处理设备仅从一个业务数据请求中提出业务打底参数，作后续处理即可，无需对这多个业务数据请求均做处理，因为，在同一时间点、同一业务数据请求所请求的业务数据相同，其作为打底数据的数据源，也只是同一份数据，因此避免冗余，则仅保留一个即可。

在实际应用中，数据处理设备在同一时间点会接收到多个客户端针对不同业务发送的不同的业务数据请求，在这种情况下，数据处理设备则必须对每个业务数据请求作上述处理，以保证打底数据的数据源的实时性和可靠性。

数据处理设备经过步骤302已经准备好打底数据的数据源，接下来需要为数据采集设备提供数据支持。

步骤303：接收数据采集设备发送的采集请求，反馈与所述业务打底参数对应的所述业务数据。

仍旧以上述表1和表2为例，举例说明。

以表1为例，数据处理设备接收数据采集设备的采集请求，将与业务打底参数对应的业务数据反馈给数据采集设备，则数据采集设备就得到打底数据，如表1中所示，两个版本的打底数据，其中，一个版本的打底数据是用户A1在12:00:00获取的业务数据1；另一个版本的打底数据是用户A2在12:10:00获取的业务数据2。

以表2为例，数据处理设备接收数据采集设备的采集请求，将与业务打底参数对应的业务请求反馈给数据采集设备，则数据采集设备就得到打底数据，如表2中所示，三个版本的打底数据，其中，一个版本的打底数据是用户A2获取的数据4；另一个版本的打底数据是用户B2获取的数据5，另一版本的打底数据是用户C2获取的数据6。

数据处理设备在接收到数据采集设备发送的采集请求后，就向数据采集设备反馈对应的业务数据，该业务数据就作为打底数据，以方便数据采集设备对打底数据的存储和管理。

利用本申请实施例提供的数据处理设备侧的打底数据生成方法，数据处理设备在为客户端提供业务支持的过程中，在不影响业务正常进行的同时，构建出打底数据的数据源，打底数据的数据源是随着业务实际进展的不断更新，具有时效性，并且数据源是真实的业务数据，具有业务多样性特性，数据处理设备在构建好数据源之后，通知数据采集设备采集生成打底数据，这些打底数据具有很高的时效性和业务特性，能够满足数据容灾对数据时效性和业务多样性的需求。

参见图4，图4为本申请实施例提供的数据采集设备侧的打底数据生成方法的流程图，该方法包括：

步骤401：数据采集设备向数据处理设备发送采集请求，接收所述数据处理设备反馈的与业务打底参数对应的业务数据；

步骤402：根据所述业务打底参数和所述业务数据的对应关系，将所述业务数据作为打底数据存储在存储设备中。

在具体实现时，由于客户端数量级非常大，因此，客户端与数据处理设备之间相互通信实现业务的过程中，数据处理设备接收到的业务数据请求的数据量非常大而且频率非常高，因此数据处理设备构建的打底数据的数据源的数量和更新频率也会非常高。在此基础上，数据采集设备会采集到大量的打底数据，为了更好地管理打底数据方便数据容灾，在本申请实施例中，对打底数据进行版本化管理，具体的，根据业务打底参数和时间戳生成版本信息，然后基于版本信息来管理每个打底数据。

优选的，步骤S402可包括：

根据所述业务打底参数和时间戳生成版本信息；

按照所述版本信息与所述业务数据之间的对应关系，将所述业务数据存储在所述存储设置中。

在电子商务平台中已经部署有数据库和缓存设备等存储设备，基于此，本申请实施例在实际应用中，将所述版本信息与所述业务数据的唯一对应关系存储在数据库中；以及，将所述业务数据存储在缓存设备中。

另外，在具体实现时，由于某个业务的实际需求，需要对数据容灾的打底数据进行管理，比如说，删除，修改，指定等等。以指定为例进行说明，在业务出现故障时，业务方由于业务需求指定采用某个时间点的打底数据进行数据容灾。

具体的，通过控制台提供打底数据管理界面，业务方根据实际需求可指定可用版本的打底数据。在本申请实施例上述方法的基础上，还可包括：接收控制台发送的打底数据管理指示，对存储的打底数据进行相应处理，其中，所述控制台提供的打底数据管理界面。另外，在本申请实施例上述方法的基础上，还可包括：接收控制台发送的打底数据回滚指示，所述打底数据回滚指示中携带有指定的版本信息；利用所述指定的版本信息的打底数据覆盖当前可用版本的打底数据。

利用本申请实施例提供的数据采集设备侧的打底数据生成方法，数据采集设备根据数据处理设备下发的通知信息，能够及时跟随业务进展而采集到实时性较高和业务多样性的打底数据，将这些打底数据存储在存储设备中，以供客户端数据容灾时使用。

利用上述本申请实施例提供的方案能够生成具有业务时效性和业务多样性的打底数据，基于这些打底数据，本申请还提供了数据容灾方法。

参见图5，图5是本申请实实施例提供的数据容灾方法的流程图，如图5所示，所述方法包括：

步骤501：客户端监控业务是否满足预设的容灾场景；若是，则进入步骤502；

其中，预设的容灾场景有：系统发生限流、集群故障、接口超时、网络抖动等等场景，在这些场景下，客户端无法正常展示业务，需要数据容灾。

步骤502：客户端将数据容灾请求路由到存储设备中，从所述存储设备中获取与所述业务对应的当前可用版本的打底数据；其中，所述存储设备用于存储数据采集设备从数据处理系统中采集的打底数据，所述打底数据是所述数据处理系统在响应客户端业务数据请求的同时根据业务数据而确定的；

步骤503：客户端在所述业务的资源位上渲染所述打底数据。

在具体实现时，客户端从存储设备中获取与所述业务对应的当前版本最新的打底数据，即时效性最高的打底数据，这就能够保证用户对平台故障的零感知，达到较好的数据容灾效果。

在具体实现时，由于业务方的实际需求，控制数据容灾所采用的打底数据，则业务方可指定某个阶段可用的打底数据，基于此，客户端从存储设备中获取与当前时间段匹配的打底数据，这种方式能够方便业务方有效控制数据容灾。

为了便于理解本申请实施例的方案，下面分别以上文表1和表2的场景，对图5所示方法的实现进行说明。

以表1场景为基础，假设，用户C1的天猫客户端在工作时，由于网络原因无法从天猫服务端获取对应的业务数据，在12:10:01发生业务故障，此时就需要获取打底数据进行打底容灾，避免影响用户体验。

从表1可知，当前存储的最新的打底数据是12:10:00的数据，该数据具有较高的业务时效性，则客户端从存储设备中获取到时间12:10:00的打底数据，对于用户C1而言，几乎感觉不到业务一秒中的变化情况，另外，业务在一秒中一般也不会发生变化，因此利用该方法就能够很好地实现数据容灾。

以表2场景为基础，假设，用户A3，所选区域也是北京东城区，其在时间为13:10:01时刻，启用天猫超市业务，但由于网络原因，无法从天猫服务端获取对应的数据，此时就需要获取打底数据进行打底容灾，避免业务瘫痪影响用户体验。由于，存储设备当前存储的关于“天猫超市”-北京东城区的最新的打底数据是用户B2在13:10:00请求的数据5，将该数据5反馈给用户A3，该数据既能满足业务数据的区域性要求，又能满足时效性要求，能够得到很好数据容灾效果。

假设，用户B3,所选区域不是北京东城区，而是上海黄浦区时，在时间为13:00:01时刻，需要数据容灾时，则由于当前存储的关于“天猫超市”-上海浦东区的最新的打底数据是用户C2在13:10:00请求的数据6，将该数据6反馈给用户B3，该数据既能满足业务数据的区域性要求，又能满足时效性要求，能够得到很好数据容灾效果。

由于现有技术中的客户端是通过预先设置的、与业务对应的打底数据来实现数据容灾的，而预先设置的固定的打底数据，并不随着业务的实际进展，而具备时效性，也不具备业务多样性的特点，这就导致用户会明显感知平台故障，效果不太好。相比现有技术，在本申请实施例中，客户端利用本申请实施例的方法进行数据容灾能够达到用户零感知的效果。

为了便于理解本申请提供的打底数据生成方法和数据容灾方法，下面通过一个实施例对以上方法进行解释说明。

参见图6，图6是本申请实施例提供的打底数据生成方法及数据容灾方法的流程图，如图6所示，包括：

步骤601：客户端向数据处理设备发送业务数据请求；

步骤602：数据处理设备响应于客户端发送的业务数据请求反馈业务数据；

步骤603：数据处理设备从所述业务数据请求中提取业务打底参数，缓存所述业务打底参数和所述业务数据；

步骤604：数据处理设备根据所述业务打底参数生成通知消息，以通知数据采集设备；

上述步骤601-604的实现可参见上文图3实施例的实现。

步骤605：数据采集设备根据所述通知消息，从所述数据处理设备中采集与所述业务打底参数对应的业务数据；

步骤606：数据采集设备将所述业务数据作为打底数据存储在所述存储设备中；

步骤607：存储设备存储所述打底数据。

上述步骤605-607的实现可参见上文图4实施例的实现。

步骤608：客户端监控业务处于预设的容灾场景时，利用所述业务的前后端组件路由到存储设备中，从所述存储设备中获取与所述业务对应的当前可用版本的打底数据；

步骤609：客户端在所述业务的资源位上渲染所述打底数据。

上述步骤608-609的实现可参见上文图5实施例的实现。

这里需要说明的是，步骤601的执行主体-客户端，与步骤608-609的执行主体-客户端在实际应用中，可以是同一客户端，也可以是不同客户端。

另外，步骤601-607的实现过程，与步骤608-609的实现过程并没有严格时间顺序限定，仅仅是为了方便说明才按照上述流程描述。而且步骤601-607是随着客户端的实际业务需求而不断循环执行的，步骤608-609也是随着客户端的实际业务情况而实施的。但这两个过程并不干扰，并没有顺序要求。

以上对本申请提供的打底数据生成方法进行了介绍，下面对其相关设备进行介绍。

参见图7，图7是本申请实施例提供的一种数据处理设备的结构图，如图7所示，该数据处理设备700包括：

第一响应模块701，用于响应于客户端发送的业务数据请求反馈业务数据；

提取模块702，用于从所述业务数据请求中提取业务打底参数；

第二响应模块703，用于接收所述数据采集设备发送的采集请求，反馈与所述业务打底参数对应的所述业务数据。

本申请实施例提供的数据处理设备的各个模块的处理过程可参见图3所示实施例的实现。

参见图8，图8是本申请实施例提供的一种数据采集设备的结构图，如图8所示，该数据处理设备800包括：

采集模块801，用于向数据处理设备发送采集请求，接收所述数据处理设备反馈的与业务打底参数对应的业务数据；

存储模块802，用于根据所述业务打底参数与所述业务数据之间的对应关系，将所述业务数据作为打底数据存储在存储设备中。

本申请实施例提供的数据采集设备的各个模块的处理过程可参见图4所示实施例的实现。

参见图9，图9是本申请实施例提供的一种数据容灾装置的结构图，如图9所示，该装置包括：

监控模块901，用于监控客户端的业务是否满足预设的容灾场景；若是，执行打底数据获取模块；

获取模块902，用于路由到存储设备中，从所述存储设备中获取与所述业务对应的当前可用版本的打底数据；其中，所述存储设备用于存储数据采集设备从数据处理系统中采集的打底数据，所述打底数据是所述数据处理系统在响应客户端业务数据请求的同时根据业务数据而确定的；

渲染模块903，用于在所述业务的资源位上渲染所述打底数据。

本申请实施例提供的数据容灾装置的各个模块的处理过程可参见图5所示实施例的实现。

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

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

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

Claims (16)

1.一种用于数据容灾的打底数据生成系统，其特征在于，包括：

数据处理设备，用于响应于客户端发送的业务数据请求反馈业务数据，并从所述业务数据请求中提取业务打底参数；

数据采集设备，用于从所述数据处理设备中采集与所述业务打底参数对应的所述业务数据，将所述业务数据作为打底数据存储在所述存储设备中；

存储设备，用于存储所述打底数据。

2.根据权利要求1所述的系统，其特征在于，所述数据采集设备还用于：缓存所述业务打底参数和所述业务数据，并生成通知消息以通知数据采集设备。

3.一种用于数据容灾的打底数据生成方法，其特征在于，所述方法应用于数据处理设备，所述方法包括：

响应于客户端发送的业务数据请求反馈业务数据；

从所述业务数据请求中提取业务打底参数；

接收数据采集设备发送的采集请求，反馈与所述业务打底参数对应的所述业务数据。

4.根据权利要求3所述的方法，其特征在于，在所述从所述业务数据请求中提取业务打底参数之后，所述方法还包括：

缓存所述业务打底参数和所述业务数据，并生成通知消息以通知数据采集设备。

5.根据权利要求3所述的方法，其特征在于，所述数据处理设备具有为所述数据采集设备开放的打底接口，所述打底接口能够针对不同的客户端类型，反馈不同格式的业务数据；

则所述接收数据采集设备发送的采集请求，反馈与所述业务打底参数对应的业务数据，包括：

通过所述打底接口接收携带有客户端类型的采集请求，并通过打底接口反馈与所述业务打底参数对应的符合客户端类型所需格式的业务数据。

6.根据权利要求3所述的方法，其特征在于，所述从所述业务数据请求中提取业务打底参数，包括：

据预设的业务打底参数白名单，对所述业务数据请求中的业务相关参数进行过滤得到业务打底参数。

7.根据权利要求4所述的方法，其特征在于，所述缓存所述业务打底参数和所述业务数据，包括：

按照预设的统一参数结构形式缓存所述业务打底参数，并缓存与所述业务打底参数对应的所述业务数据。

8.一种用于数据容灾的打底数据生成方法，其特征在于，所述方法应用于数据采集设备，所述方法包括：

向数据处理设备发送采集请求，接收所述数据处理设备反馈的与业务打底参数对应的业务数据；

根据所述业务打底参数和所述业务数据的对应关系，将所述业务数据作为打底数据存储在存储设备中。

9.根据权利要求8所述的方法，其特征在于，所述根据所述业务打底参数和所述业务数据的对应关系，将所述业务数据作为打底数据存储在所述存储设备中，包括：

根据所述业务打底参数和时间戳生成版本信息；

按照所述版本信息与所述业务数据之间的对应关系，将所述业务数据存储在所述存储设备中。

10.根据权利要求9所述的方法，其特征在于，所述存储设备包括：数据库和缓存设备；

则所述按照所述版本信息与所述业务数据之间的对应关系，将所述业务数据存储在所述存储设备中，包括：

将所述版本信息与所述业务数据的唯一对应关系存储在数据库中；

将所述业务数据存储在缓存设备中。

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

接收控制台发送的打底数据管理指示，对存储的打底数据进行相应处理，其中，所述控制台提供的打底数据管理界面。

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

接收控制台发送的打底数据回滚指示，所述打底数据回滚指示中携带有指定的版本信息；

利用所述指定的版本信息的打底数据覆盖当前可用版本的打底数据。

13.一种数据处理设备，其特征在于，所述数据处理设备包括：

第一响应模块，用于响应于客户端发送的业务数据请求反馈业务数据；

提取模块，用于从所述业务数据请求中提取业务打底参数；

第二响应模块，用于接收所述数据采集设备发送的采集请求，反馈与所述业务打底参数对应的所述业务数据。

14.一种数据采集设备，其特征在于，所述数据采集设备包括：

采集模块，用于向数据处理设备发送采集请求，接收所述数据处理设备反馈的与业务打底参数对应的业务数据；

存储模块，用于根据所述业务打底参数与所述业务数据之间的对应关系，将所述业务数据作为打底数据存储在存储设备中。

15.一种数据容灾方法，其特征在于，所述方法应用于客户端，所述方法包括：

监控客户端的业务是否满足预设的容灾场景；

若是，则路由到存储设备中，从所述存储设备中获取与所述业务对应的当前可用版本的打底数据；其中，所述存储设备用于存储数据采集设备从数据处理系统中采集的打底数据，所述打底数据是所述数据处理系统在响应客户端业务数据请求的同时根据业务数据而确定的；

在所述业务的资源位上渲染所述打底数据。

16.一种数据容灾装置，其特征在于，所述装置应用于客户端，所述装置包括：

监控模块，用于监控客户端的业务是否满足预设的容灾场景；若是，执行打底数据获取模块；

获取模块，用于路由到存储设备中，从所述存储设备中获取与所述业务对应的当前可用版本的打底数据；其中，所述存储设备用于存储数据采集设备从数据处理系统中采集的打底数据，所述打底数据是所述数据处理系统在响应客户端业务数据请求的同时根据业务数据而确定的；

渲染模块，用于在所述业务的资源位上渲染所述打底数据。