数据容灾的处理方法、装置、设备及计算机可读存储介质与流程

1.本技术涉及云技术领域及计算机技术领域，尤其涉及一种数据容灾的处理方法、装置、设备及计算机可读存储介质。


背景技术：

2.云技术(cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。
3.随着计算机的普及和信息技术的进步，信息安全、数据安全的重要性日趋明显。计算机系统可能因为天灾或人为因素等等意外事故，导致系统毁坏而长期无法运行。
4.云安全(cloud security)是指基于云计算商业模式应用的安全软件、硬件、用户、机构、安全云平台的总称。其中，云安全研究中的云计算安全主要是研究如何保障云自身及云上各种应用的安全，包括云计算机系统安全、用户数据的安全存储与隔离、用户接入认证、信息传输安全、网络攻击防护、合规审计等。相关技术中，业务系统的数据容灾主要是从业务系统包括的各个服务层或模块出发考虑自身的容灾实现，每个服务层采用不同的容灾方式，如此，需要考虑的容灾点非常多，导致容灾效率低，且各自容灾实现的效果也不同，任何一个点容灾实现效果不好，都会导致业务系统整体容灾切换失败，使得对外提供服务的可用性受到影响。


技术实现要素：

5.本技术实施例提供一种数据容灾的处理方法、装置、设备及计算机可读存储介质，能够快速有效地实现容灾切换，保证业务系统对外提供服务的可用性。
6.本技术实施例的技术方案是这样实现的：
7.本技术实施例提供一种数据容灾的处理方法，包括：
8.统计业务系统中第一业务实体针对目标业务的业务请求的处理结果；
9.其中，所述业务系统包括至少两个业务实体，每个所述业务实体包括逻辑层服务、数据层服务及数据库，能够独立完成针对所述业务请求的处理；所述至少两个业务实体，用于共同处理所述业务系统针对所述目标业务的多个业务请求；
10.当基于所述处理结果确定所述第一业务实体发生故障时，将所述第一业务实体待处理的业务请求切换至所述至少两个业务实体中第二业务实体；
11.通过所述第二业务实体的逻辑层服务，调用所述第二业务实体的数据层服务，从所述第二业务实体的数据库读取对应所述第一业务实体待处理的业务请求的数据，并
12.通过所述第二业务实体的逻辑层服务，基于读取的所述数据，执行与所述业务请求对应的逻辑处理。
13.本技术实施例提供一种数据容灾装置，包括：
14.统计模块，用于统计业务系统中第一业务实体针对目标业务的业务请求的处理结果；
15.其中，所述业务系统包括至少两个业务实体，每个所述业务实体包括逻辑层服务、数据层服务及数据库，能够独立完成针对所述业务请求的处理；所述至少两个业务实体，用于共同处理所述业务系统针对所述目标业务的多个业务请求；
16.切换模块，用于当基于所述处理结果确定所述第一业务实体发生故障时，将所述第一业务实体待处理的业务请求切换至所述至少两个业务实体中第二业务实体；
17.处理模块，用于通过所述第二业务实体的逻辑层服务，调用所述第二业务实体的数据层服务，从所述第二业务实体的数据库读取对应所述第一业务实体待处理的业务请求的数据，并
18.通过所述第二业务实体的逻辑层服务，基于读取的所述数据，执行与所述业务请求对应的逻辑处理。
19.上述方案中，所述统计模块，还用于统计目标时间段内所述第一业务实体所处理的针对目标业务的业务请求的总数量、及所述总数量的业务请求中处理成功的业务请求的数量；
20.依据所述业务请求的总数量及所述处理成功的业务请求的数量，确定所述第一业务实体针对目标业务的业务请求的处理成功率，将所述处理成功率作为所述处理结果；
21.将所述处理成功率与成功率阈值进行比较；
22.当所述处理成功率低于成功率阈值时，确定所述第一业务实体发生故障。
23.上述方案中，所述统计模块，还用于统计目标时间段内所述业务系统中第一业务实体所处理的针对目标业务的业务请求的总数量、及所述总数量的业务请求中处理成功的业务请求的数量；
24.依据所述业务请求的总数量及所述处理成功的业务请求的数量，确定所述第一业务实体针对目标业务的业务请求的处理成功率，将所述处理成功率作为所述处理结果；
25.将所述处理成功率与成功率阈值进行比较，并将所述业务请求的总数量与数量阈值进行比较；
26.当所述处理成功率低于成功率阈值、且所述总数量达到数量阈值时，确定所述第一业务实体发生故障。
27.上述方案中，所述切换模块，还用于获取所述业务系统中业务实体间的关联关系；
28.根据所述业务实体间的关联关系，从所述至少两个业务实体中，确定与所述第一业务实体相关联的第二业务实体。
29.上述方案中，所述切换模块，还用于统计所述第二业务实体针对目标业务的业务请求的处理结果；
30.根据所述第一业务实体针对目标业务的业务请求的处理结果、及所述第二业务实体针对目标业务的业务请求的处理结果，确定所述第一业务实体的处理成功率与所述第二业务实体的处理成功率之间的差值；
31.当所述差值达到差值阈值时，将所述第一业务实体待处理的业务请求切换至所述至少两个业务实体中第二业务实体处理。
32.上述方案中，所述切换模块，还用于当所述业务系统包括的业务实体的数量多于两个时，获取所述业务系统包括的业务实体中，除所述第一业务实体外的至少两个业务实体针对所述目标业务的业务请求的处理结果；
33.根据除所述第一业务实体外的至少两个业务实体针对所述目标业务的业务请求的处理结果，分别对各业务实体进行故障判断，得到各业务实体的故障判断结果；
34.依据所述故障判断结果，从所述除所述第一业务实体外的至少两个业务实体中，选择一个未发生故障的业务实体作为第二业务实体。
35.上述方案中，所述切换模块，还用于将所述第一业务实体与所述第二业务实体进行关联，以得到所述第一业务实体与所述第二业务实体之间的路由关系；
36.在接收到所述第一业务实体待处理的业务请求时，根据所述路由关系，将所述第一业务实体待处理的业务请求，路由到所述第二业务实体。
37.上述方案中，所述切换模块，还用于获取所述第一业务实体待处理的业务请求；
38.基于所述业务请求，生成携带有第二业务实体的标识的业务信息；
39.根据所述业务信息，将所述第一业务实体待处理的业务请求路由至第二业务实体。
40.上述方案中，所述切换模块，还用于当接收到针对第一业务实体的故障恢复信息时，获取至少一个回切间隔；
41.其中，所述回切间隔，用于指示相邻两次业务请求回切操作之间的间隔时长；
42.根据所述至少一个回切间隔，将切换至所述第二业务实体的所述第一业务实体待处理的业务请求切换回所述第一业务实体。
43.上述方案中，所述切换模块，还用于获取回切失败的次数；
44.根据所述回切失败的次数，确定至少一个回切间隔，所述回切间隔与所述回切次数呈正相关关系。
45.上述方案中，所述切换模块，还用于在将所述第一业务实体待处理的业务请求切换回所述第一业务实体的过程中，周期性统计已切换回所述第一业务实体的业务请求的处理结果；
46.当所述处理结果表征所述第一业务实体再次发生故障时，将所述第一业务实体待处理的业务请求全量切换至所述第二业务实体。
47.上述方案中，所述切换模块，还用于当存在与所述第一业务实体相关联的第二业务实体时，获取切换列表中包括的业务实体；
48.基于所述切换列表中包括的业务实体，确定所述切换列表中未包括所述第一业务实体和所述第二业务实体时，获取针对所述第一业务实体的切换记录；
49.当所述切换记录表征未执行针对所述第一业务实体的业务请求切换处理时，将所述第一业务实体及所述第二业务实体添加至切换列表；
50.基于所述切换列表，将所述第一业务实体待处理的业务请求路由至所述至少两个业务实体中第二业务实体。
51.本技术实施例提供一种计算机设备，包括：
52.存储器，用于存储可执行指令；
53.处理器，用于执行所述存储器中存储的可执行指令时，实现本技术实施例提供的数据容灾的处理方法。
54.本技术实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本技术实施例提供的数据容灾的处理方法。
55.本技术实施例具有以下有益效果：
56.应用本技术上述实施例，当基于处理结果确定第一业务实体发生故障时，将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体处理；通过所述第二业务实体的逻辑层服务，调用所述第二业务实体的数据层服务，从所述第二业务实体的数据库读取对应所述第一业务实体待处理的业务请求的数据，并通过所述第二业务实体的逻辑层服务，基于读取的所述数据，执行与所述业务请求对应的逻辑处理；由于业务系统中每个业务实体能够独立完成针对业务请求的处理，在其中一个业务实体发生故障时，能够将该业务实体待处理的业务请求切换至业务系统中的另一业务实体，实现容灾切换；且，由于容灾切换针对的是单一业务实体，即以业务实体为处理粒度来实现的，无需查找业务系统中具体的故障点，提高了容灾切换的效率，保证了业务系统对外提供服务的可用性。
附图说明
57.图1是本技术实施例提供的数据容灾的处理系统100的架构示意图；
58.图2是本技术实施例提供的业务系统的结构示意图；
59.图3是本技术实施例提供的服务器200的结构示意图；
60.图4是本技术实施例提供的数据容灾的处理方法的流程示意图；
61.图5是本技术实施例提供的业务系统的结构示意图；
62.图6是本技术实施例提供的数据容灾的处理方法的流程示意图；
63.图7是本技术实施例提供的交易系统的架构示意图；
64.图8是本技术实施例提供的切换命令下发的判断流程示意图；
65.图9是本技术实施例提供的数据容灾的处理方法的流程示意图；
66.图10是本技术实施例提供的数据容灾的处理装置的组成结构示意图。
具体实施方式
67.为了使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术作进一步地详细描述，所描述的实施例不应视为对本技术的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本技术保护的范围。
68.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
69.在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
70.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
71.对本技术实施例进行进一步详细说明之前，对本技术实施例中涉及的名词和术语进行说明，本技术实施例中涉及的名词和术语适用于如下的解释。
72.1)数据容灾，当计算机系统在遭受如火灾、水灾、地震、战争等不可抗拒的自然灾难以及计算机犯罪、计算机病毒、掉电、网络/通信失败、硬件/软件错误和人为操作错误等人为灾难时，在保证业务系统的数据尽量少丢失的情况下，保持业务系统的业务不间断地运行。
73.2)业务实体，可以实现一组特定功能的模块组合，如集合(set)。
74.3)回切，指将第一业务实体的待处理的业务请求切换至第二业务实体后，再将第一业务实体的待处理的业务请求切换回第一业务实体的过程。
75.参见图1，图1是本技术实施例提供的数据容灾的处理系统的架构示意图，为实现支撑一个示例性应用，终端(示例性示出了终端400-1和终端400-2)通过网络300-1连接服务器200，网络300-1可以是广域网或者局域网，又或者是二者的组合。其中，服务器200上部署有业务系统，业务系统包括两个业务实体，每个所述业务实体包括逻辑层服务、数据层服务及数据库，能够独立完成针对所述业务请求的处理；所述至少两个业务实体，用于共同处理所述业务系统针对所述目标业务的多个业务请求。
76.终端(如终端400-1)，用于发送针对目标业务的业务请求至服务器200。
77.服务器200，用于将接收到的业务请求路由到相应的业务实体，通过相应的业务实体对业务请求进行处理，并将处理结果返回终端。
78.服务器200，还用于统计各业务实体针对目标业务的业务请求的处理结果；当基于处理结果确定第一业务实体发生故障时，将第一业务实体待处理的业务请求切换至第二业务实体；通过所述第二业务实体的逻辑层服务，调用所述第二业务实体的数据层服务，从所述第二业务实体的数据库读取对应所述第一业务实体待处理的业务请求的数据，并通过所述第二业务实体的逻辑层服务，基于读取的所述数据，执行与所述业务请求对应的逻辑处理。
79.在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本技术实施例中不做限制。
80.参见图2，图2是本技术实施例提供的业务系统的结构示意图，在实际实施时，业务系统包括网关路由201、路由管理202和至少两个业务实体(示例性示出了第一业务实体203-1和第二业务实体203-2)。
81.网关路由210，用于在接收到针对目标业务的业务请求时，将业务请求路由到相应的业务实体；如，在接收到第一业务实体203-1待处理的业务请求时，将第一业务实体待处理的业务请求路由到第一业务实体203-1；
82.业务实体(如第一业务实体203-1)，用于在接收到待处理的业务请求时，通过逻辑层服务，调用数据层服务，从数据库读取对应业务请求的数据，并通过逻辑层服务，基于读取的数据，执行与业务请求对应的逻辑处理；
83.路由管理202，还用于统计各业务实体针对目标业务的业务请求的处理结果；当基于处理结果确定第一业务实体203-1发生故障时，发送切换指令至网关路由201，其中，切换
指令用于指示将第一业务实体待处理的业务请求切换至第二业务实体处理；
84.网关路由201，用于根据切换指令，在接收到第一业务实体203-1待处理的业务请求时，将第一业务实体待处理的业务请求路由到第二业务实体203-2。
85.参见图3，图3是本技术实施例提供的服务器200的结构示意图，图2所示的服务器200包括：至少一个处理器210、存储器250、至少一个网络接口220和用户接口230。服务器200中的各个组件通过总线系统240耦合在一起。可理解，总线系统240用于实现这些组件之间的连接通信。总线系统240除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统240。
86.处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(dsp，digital signal processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
87.用户接口230包括使得能够呈现媒体内容的一个或多个输出装置231，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口230还包括一个或多个输入装置232，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
88.存储器250可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器250可选地包括在物理位置上远离处理器210的一个或多个存储设备。
89.存储器250包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(rom，read only memory)，易失性存储器可以是随机存取存储器(ram，random access memory)。本技术实施例描述的存储器250旨在包括任意适合类型的存储器。
90.在一些实施例中，存储器250能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
91.操作系统251，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
92.网络通信模块252，用于经由一个或多个(有线或无线)网络接口220到达其他计算设备，示例性的网络接口220包括：蓝牙、无线相容性认证(wifi)、和通用串行总线(usb，universal serial bus)等；
93.呈现模块253，用于经由一个或多个与用户接口230相关联的输出装置231(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；
94.输入处理模块254，用于对一个或多个来自一个或多个输入装置232之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
95.在一些实施例中，本技术实施例提供的装置可以采用软件方式实现，图3示出了存储在存储器250中的数据容灾的处理装置255，其可以是程序和插件等形式的软件，包括以下软件模块：统计模块2551、切换模块2552及处理模块2553，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。
96.将在下文中说明各个模块的功能。
97.在另一些实施例中，本技术实施例提供的数据容灾的处理装置可以采用硬件方式实现，作为示例，本技术实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本技术实施例提供的数据容灾的处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(asic，application specific integrated circuit)、dsp、可编程逻辑器件(pld，programmable logic device)、复杂可编程逻辑器件(cpld，complex programmable logic device)、现场可编程门阵列(fpga，field-programmable gate array)或其他电子元件。
98.将结合本技术实施例提供的服务器的示例性应用和实施，说明本技术实施例提供的数据容灾的处理方法。
99.参见图4，图4是本技术实施例提供的数据容灾的处理方法的流程示意图，将结合图4示出的步骤进行说明。
100.步骤401：服务器统计业务系统中第一业务实体针对目标业务的业务请求的处理结果。
101.其中，业务系统包括至少两个业务实体，每个业务实体包括逻辑层服务、数据层服务及数据库，能够独立完成针对业务请求的处理；至少两个业务实体，用于共同处理业务系统针对目标业务的多个业务请求。
102.在实际实施时，服务器上部署有业务系统，业务系统包括至少两个业务实体，每个业务实体包括逻辑层服务、数据层服务及数据库，图5是本技术实施例提供的业务系统的结构示意图，参见图5，业务系统包括多个业务实体(如业务实体500)，业务实体包括逻辑层服务501、数据层服务502及数据库503。这里，每个业务实体均能够独立完成针对业务请求的所有处理，如，当业务请求为交易请求时，业务实体能够实现交易过程中的所有功能，如生成订单、支付确认等。
103.在一些实施例中，业务系统包括的至少两个业务实体可以是用于处理针对目标业务的不同类别的业务请求，以使两个业务实体，用于共同处理业务系统针对目标业务的多个业务请求。例如，针对目标业务的业务请求包括业务请求a和业务请求b，那么可以通过第一业务实体处理业务请求a，通过第二业务实体处理业务请求b。
104.在一些实施例中，业务系统包括的至少两个业务实体可以是用于不同用户触发的针对目标业务的业务请求，以使两个业务实体，用于共同处理业务系统针对目标业务的多个业务请求，例如，用户共有100个，那么可以通过第一业务实体处理用户1-50触发的业务请求，通过第二业务实体处理用户51-100触发的业务请求。
105.步骤402：当基于处理结果确定第一业务实体发生故障时，将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体。
106.在实际实施时，可以根据处理结果对第一业务实体进行故障判断，当确定第一业务实体发生故障时，便可以进行容灾切换，也即在接收到第一业务实体待处理的业务请求时，将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体处理。
107.例如，假设第一业务实体用于处理用户1-50触发的业务请求，第二业务实体用户处理用户51-100触发的业务请求，当基于处理结果确定第一业务实体发生故障时，若接收到用户51触发的业务请求，该业务请求本应该有第一业务实体处理，这时，将该业务请求切
换至第二业务实体进行处理。
108.在一些实施例中，服务器可以通过以下方式确定第一业务实体发生故障：当基于处理结果，确定第一业务实体的逻辑层服务、数据层服务及数据库中至少之一出现故障时，确定第一业务实体发生故障。
109.在实际实施时，处理结果可以为业务请求处理的成功率，这里，由于将逻辑层服务、服务处服务和数据库组合部署在一起，作为一个业务实体，那么逻辑层服务、服务处服务和数据库中的任意一个发生故障，都会对成功率造成影响，因此，可以根据业务请求处理的成功率，来确定第一业务实体的逻辑层服务、数据层服务及数据库中是否至少之一出现故障。这里，无论是第一业务实体的哪个层发生障碍，都将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体处理。
110.在一些实施例中，可以通过以下方式统计业务系统中第一业务实体针对目标业务的业务请求的处理结果：统计目标时间段内第一业务实体所处理的针对目标业务的业务请求的总数量、及总数量的业务请求中处理成功的业务请求的数量；依据业务请求的总数量及处理成功的业务请求的数量，确定第一业务实体针对目标业务的业务请求的处理成功率，将处理成功率作为处理结果；相应的，统计业务系统中第一业务实体针对目标业务的业务请求的处理结果之后，方法还包括：将处理成功率与成功率阈值进行比较；当处理成功率低于成功率阈值时，确定第一业务实体发生故障。
111.在实际实施时，服务器可以周期性地统计第一业务实体针对目标业务的业务请求的处理结果，这里的目标时间段指的是上次统计时间到当前统计时间之间的一段时间，例如，将统计周期设置为1分钟，上次统计时间为10:00，那么在10:01时执行统计操作，目标时间段为10:00-10:01。
112.这里的处理结果为处理成功率，需要获取第一业务实体所处理的针对目标业务的业务请求的总数量及处理成功的业务请求的数量，将处理成功的业务请求的数量与总数量的比值，作为处理成功率；例如，目标时间段为10:00-10:01，那么统计10:00-10:01第一业务实体所处理的针对目标业务的业务请求的总数量及处理成功的业务请求的数量，如总数量为100，处理成功的数量为80，那么处理成功率为80％。
113.在实际应用中，成功率阈值可以是预先设置的，在获取处理成功率之后，将处理成功率与预先设置的成功率阈值进行比较，当处理成功率达到成功率阈值，则表示第一业务实体正常；当处理成功率低于成功率阈值，则表示第一业务实体发生故障，无法正常处理业务请求。
114.在一些实施例中，可以通过以下方式统计业务系统中第一业务实体针对目标业务的业务请求的处理结果：统计目标时间段内业务系统中第一业务实体所处理的针对目标业务的业务请求的总数量、及总数量的业务请求中处理成功的业务请求的数量；依据业务请求的总数量及处理成功的业务请求的数量，确定第一业务实体针对目标业务的业务请求的处理成功率，将处理成功率作为处理结果；相应的，统计业务系统中第一业务实体针对目标业务的业务请求的处理结果之后，方法还包括：将处理成功率与成功率阈值进行比较，并将业务请求的总数量与数量阈值进行比较；当处理成功率低于成功率阈值、且总数量达到数量阈值时，确定第一业务实体发生故障。
115.这里的处理结果为处理成功率及总数量，在实际实施时，由于第一业务对成功率
可能存在随机性，当目标时间段内所处理的业务请求数量较少时，即总数量低于数量阈值时，处理成功率的可信度较低，如当第一业务实体所处理的针对目标业务的业务请求的总数量仅为5时，虽然成功率仅为10％，该成功率存在随机性，其不能够说明第一业务实体发生故障。
116.因此，在实际实施时，需要将处理成功率与成功率阈值进行比较，以及将业务请求的总数量与数量阈值进行比较，只有当处理成功率低于成功率阈值、且总数量达到数量阈值时，确定第一业务实体发生故障；否则，认为第一业务实体是正常的。如此，能够提高对第一业务实体进行故障判断的准确性。
117.在一些实施例中，服务器在将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体处理之前，还可以获取业务系统中业务实体间的关联关系；根据业务实体间的关联关系，从至少两个业务实体中，确定与第一业务实体相关联的第二业务实体。
118.在实际实施时，可以预先设置业务实体间的关联关系，以在第一业务实体发生故障时，根据关联关系，确定与其相关联的第二业务实体，将第一业务实体待处理的业务请求切换至第二业务实体。
119.例如，业务系统包括四个业务实体a、b、c、d，将业务实体a与业务实体c进行关联，将业务实体b与业务实体d进行关联，那么在业务实体a出现故障时，可以根据关联关系，获取与业务实体a相关联的业务实体c，然后价格业务实体a待处理的业务请求切换至业务实体c。
120.在一些实施例中，服务器在将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体处理之前，还可以当业务系统包括的业务实体的数量多于两个时，获取业务系统包括的业务实体中，除第一业务实体外的至少两个业务实体针对目标业务的业务请求的处理结果；根据业务系统中除第一业务实体外的至少两个业务实体针对目标业务的业务请求的处理结果，分别对各业务实体进行故障判断，得到各业务实体的故障判断结果；依据故障判断结果，从业务系统中除第一业务实体外的业务实体中，选择一个未发生故障的业务实体作为第二业务实体。
121.在实际实施时，也可以不预先设置业务实体间的关联关系，而是在确定第一业务实体发生故障时，从业务系统中除第一业务实体外的业务实体中选择一个作为第二业务实体。这里，故障了的业务实体不能作为第二业务实体，基于此，需要先对业务系统中除第一业务实体外的至少两个业务实体进行故障判断，然后从未发生故障的业务实体中选择一个作为第二业务实体。
122.在实际应用中，对其它业务实体进行故障判断的方式与对第一业务实体进行故障判断的方式可以是相同的，例如，对于每一个业务实体，可以统计该业务实体在目标时间段的所处理的针对目标业务的业务请求的总数量、及总数量的业务请求中处理成功的业务请求的数量；并根据所处理的业务请求的总数量和处理成功的业务请求的数量，计算该业务实体针对目标业务的业务请求的处理成功率，当处理成功率达到成功率阈值，则确定该业务实体未发生故障，可以作为候选的业务实体。
123.在确定了候选的业务实体之后，可以从候选的业务实体中随机选择一个业务实体作为第二业务实体；也可以根据处理结果，从候选的业务实体中选择一个表现最佳的业务
实体作为第二业务实体，例如，当处理结果为处理成功率时，可以从候选的业务实体中选择处理成功率最高的业务实体作为第二业务实体；还可以根据各业务实体所处理的业务请求的数量来选择第二业务实体，如选择所处理的业务请求的数量最少的业务实体作为第二业务实体，这里所处理的业务请求的数量越少，说明该业务实体越空闲。
124.在一些实施例中，服务器可以统计第二业务实体针对目标业务的业务请求的处理结果；根据第一业务实体针对目标业务的业务请求的处理结果、及第二业务实体针对目标业务的业务请求的处理结果，确定第一业务实体的处理成功率与第二业务实体的处理成功率之间的差值；当差值达到差值阈值时，将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体处理。
125.在实际实施时，只有在第一业务实体与第二业务实体的处理成功率之间的差值达到差值阈值时，将第一业务实体待处理的业务请求切换至第二业务实体处理才能够对处理结果进行改善；若第一业务实体与第二业务实体的处理成功率之间的差值未达到差值阈值，也即第一业务实体与第二业务实体的处理成功率相差不多时，则没有必要将第一业务实体，其对业务处理的改善不大，此时可以从业务系统总重新选择一个业务实体作为第二业务实体，或者可以不执行切换操作。
126.在一些实施例中，服务器可以通过以下方式将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体处理：将第一业务实体与第二业务实体进行关联，以得到第一业务实体与第二业务实体之间的路由关系；在接收到第一业务实体待处理的业务请求时，根据路由关系，将第一业务实体待处理的业务请求，路由到第二业务实体。
127.在实际实施时，服务器在将第一业务实体与第二业务实体进行关联之后，可以存储该关联关系，这里可以通过列表的形式对该关联关系进行存储，也可以通过其他形式对该关联关系进行存储。当后续再接收到第一业务实体待处理的业务请求时，服务器可以获取该关联关系，然后依据该关联关系，确定与第一业务实体待处理的业务请求，进而将原本应该有第一业务实体待处理的业务请求，路由到第二业务实体，由第二业务实体对该业务请求进行处理。
128.在一些实施例中，服务器可以通过以下方式将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体：存在与第一业务实体相关联的第二业务实体时，获取切换列表中包括的业务实体；基于切换列表中包括的业务实体，确定切换列表中未包括第一业务实体和第二业务实体时，获取针对第一业务实体的切换记录；当切换记录表征未执行针对第一业务实体的业务请求切换处理时，将第一业务实体及第二业务实体添加至切换列表；基于切换列表，将第一业务实体待处理的业务请求路由至至少两个业务实体中第二业务实体。
129.这里，切换列表中记录有业务实体，用于指示业务实体间的路由关系，以基于路由关系实现切换。在实际实施时，由于切换列表用于指示业务实体间的路由关系，服务器可以获取切换列表，判断切换列表中是否已有第一业务实体、以及是否已有第二业务实体，若已有第一业务实体和/或第二业务实体，那么，说明已执行过切换处理；若没有，则进一步获取针对第一业务实体的切换记录，来通过切换记录判断是否已执行切换处理，当切换记录表征未执行针对所述第一业务实体的业务请求切换处理时，则表示需要执行切换处理。这时，将第一业务实体和第二业务实体添加至切换列表，以在接收到第一业务实体待处理的业务
请求时，基于切换列表，将第一业务实体待处理的业务请求路由到第二业务实体，通过第二业务实体包括的逻辑层服务、数据层服务及数据库，对所述第一业务实体待处理的业务请求进行处理。
130.在一些实施例中，服务器可以通过以下方式将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体：获取第一业务实体待处理的业务请求；基于业务请求，生成携带有第二业务实体的标识的业务信息；根据业务信息，将第一业务实体待处理的业务请求路由至第二业务实体。
131.在实际实施时，服务器在接收到待处理的业务请求后，会根据该业务请求生成携带有相应业务实体的标识的业务信息，以根据该业务信息，将与该业务请求路由到相应的业务实体进行处理。具体地，当第一业务实体未发生故障时，对于第一业务实体待处理的业务请求，基于该业务请求，生成携带有第一业务实体的业务信息，以对该业务信息进行识别，将第一业务实体待处理的业务请求路由至第一业务实体；当确定第一业务实体发生故障时，则确定第二业务实体，对于第一业务实体待处理的业务请求，基于该业务请求，生成携带有第二业务实体的业务信息，以对该业务信息进行识别，将第一业务实体待处理的业务请求路由至第二业务实体。
132.作为示例，当第一业务实体用于处理用户1-50触发的业务请求，第二业务实体用户处理用户51-100触发的业务请求，当基于处理结果确定第一业务实体发生故障时，若接收到用户51触发的业务请求，则根据用户51触发的业务请求生成，如当业务请求为交易请求时，则基于该交易请求生成携带有第二业务实体对应的订单号，以将对应该单号的所有交易过程都有第二业务实体进行处理，如订单生成、确认支付等操作。
133.步骤403：通过第二业务实体的逻辑层服务，调用第二业务实体的数据层服务，从第二业务实体的数据库读取对应第一业务实体待处理的业务请求的数据，并通过第二业务实体的逻辑层服务，基于读取的数据，执行与业务请求对应的逻辑处理。
134.这里，通过第二业务实体中的逻辑层服务、数据层服务及数据库共同完成针对第一业务实体待处理的业务请求的处理。其中，逻辑层服务用于调用数据层服务来访问数据库，数据层服务用于与数据库进行交互。在实际实施时，当接收到对应第一业务实体待处理的业务请求，将该业务请求路由至第二业务实体，通过第二业务实体的逻辑层服务，调用数据层服务读取数据库中与业务请求相关的数据，进而基于该数据执行相应的逻辑处理，以实现对第一业务实体待处理的业务请求的全部处理。
135.服务器可以通过以下方式将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体之后，当接收到针对第一业务实体的故障恢复信息时，获取至少一个回切间隔；根据至少一个回切间隔，将切换至第二业务实体的第一业务实体待处理的业务请求切换回第一业务实体。
136.这里，回切间隔，指示相邻两次业务请求回切操作之间的间隔时长。回切间隔可以是相同的，如设置为10分钟，也可以是不同的，如回切间隔可以根据回切次数，按照一定比例递增；每次切换至第二业务实体的业务请求的数量可以是相同的，也可以是不同的，如，可以按照一定比例来切换，第一次切换10％，第二次切换20％，第三次切换30％，第四次切换40％，直至全部切换回第一业务实体。
137.本技术实施例采用了快切换、慢回切的方式，也即在第一业务实体发生故障时，立
刻将第一业务实体全部待处理的业务请求都切换至第二业务实体进行处理；当第一业务实体恢复正常时，进行多次回切，直至全部切换回第一业务实体，保证了业务系统的连续性。
138.在一些实施例中，服务器可以通过以下方式获取至少一个回切间隔：获取业务请求回切操作对应的回切失败的次数；根据回切失败的次数，确定至少一个回切间隔，回切间隔与回切次数呈正相关关系。
139.在实际实施时，回切失败的次数越多，那么回切间隔时间越长，其中，第一次进行回切时，回切失败的次数为零。
140.在一些实施例中，可以通过d＝((i t-1)/t)*(f 1)，来确定回切间隔，其中，i是配置的间隔时间，如10分钟，t是处理结果上报周期，如45秒，f是回切失败的次数，如3次，d是回切间隔，这里的回切间隔为间隔的上报周期数。
141.在一些实施例中，当回切失败的次数达到次数阈值时，则不再尝试回切，此时需要人工介入，也即在接收到人工触发的回切指令时，再执行回切操作。
142.在一些实施例中，服务器在将第一业务实体待处理的业务请求切换回第一业务实体的过程中，周期性统计已切换回第一业务实体的业务请求的处理结果；当处理结果表征第一业务实体再次发生故障时，将第一业务实体待处理的业务请求全量切换至第二业务实体。
143.在实际实施时，在回切的过程中，会对第一业务实体进行故障检测，即周期性的统计已切换会第一业务实体的业务请求的处理结果，这里的处理结果可以为处理成功率，依据接收到的处理结果进行故障判断，若检测到第一业务实体再次发生故障时，将第一业务实体待处理的业务请求全部切换至第二业务实体。
144.应用本技术上述实施例，当基于处理结果确定第一业务实体发生故障时，将第一业务实体待处理的业务请求切换至至少两个业务实体中第二业务实体处理；由于业务系统中每个业务实体能够独立完成针对业务请求的处理，在其中一个业务实体发生故障时，能够将该业务实体待处理的业务请求切换至业务系统中的另一业务实体，实现容灾切换；且，由于容灾切换针对的是单一业务实体，即以业务实体为处理粒度来实现的，无需查找业务系统中具体的故障点，提高了容灾切换的效率，保证了业务系统对外提供服务的可用性。
145.下面以业务系统为交易系统为例，说明本技术实施例提供的数据容灾的处理方法，图6是本技术实施例提供的数据容灾的处理方法的流程示意图，参见图6，本技术实施例提供的数据容灾的处理方法包括：
146.步骤601：终端发送针对第一目标商品的交易请求至服务器。
147.这里终端的用户为对应第一业务实体的用户。
148.步骤602：服务器根据针对第一目标商品的交易请求所对应的用户标识，生成携带有第一业务实体的对应第一目标商品的订单号。
149.步骤603：服务器根据订单号，将对应该订单号的交易请求路由至第一业务实体进行处理。
150.步骤604：服务器统计交易系统包括的多个业务实体所处理的交易请求数量、处理成功率、处理失败率。
151.步骤605：服务器基于交易请求数量、处理成功率、处理失败率，确定第一业务实体发生故障时，将第一业务实体与第二业务实体关联后存储至切换列表。
152.步骤606：终端发送针对第二目标商品的交易请求至服务器。
153.步骤607：服务器根据针对第二目标商品的交易请求所对应的用户标识，确定与用户标识对应的第一业务实体。
154.步骤608：服务器根据切换列表，确定与第一业务实体相关联的第二业务实体，并生成携带有第二业务实体的对应第二目标商品的订单号。
155.步骤609：服务器根据订单号，将对应该订单号的交易请求路由至第二业务实体进行处理。
156.应用本技术上述实施例，当确定第一业务实体发生故障时，将第一业务实体待处理的业务请求第二业务实体处理；由于业务系统中每个业务实体能够独立完成针对业务请求的处理，在其中一个业务实体发生故障时，能够将该业务实体待处理的业务请求切换至业务系统中的另一业务实体，实现容灾切换；且，由于容灾切换针对的是单一业务实体，即以业务实体为处理粒度来实现的，无需查找业务系统中具体的故障点，提高了容灾切换的效率，保证了业务系统对外提供服务的可用性。
157.下面，将说明本技术实施例在一个实际的应用场景中的示例性应用。
158.以业务系统为交易系统为例，图7是本技术实施例提供的交易系统的架构示意图，参见图7，交易系统包括两个业务实体，业务实体包括逻辑层服务、数据层服务以及数据库，这里将业务实体作为一个集合(set)，在set内可以完成交易过程的全部功能。
159.在实际实施时，将交易系统的所有用户根据表示信息划分为不同的群组，例如，可以将用户id的尾号均分为不同号段，根据号段个数分别独立部署相应个数的set。参见图7，可以部署两个set，分别对应不同的用户尾号段，即00-49和50-99。这里，两个set分别部署不同的互联网数据中心(idc，internet data center)，如此，能够降低idc故障对系统的影响范围，有利于本技术实施例的数据容灾处理方法的实施。
160.当接收到用户触发的交易请求时，由路由网关按照用户尾号，将交易请求路由到对应的set，由该set单号服务生成尾号与本set对应的订单号，后续此用户的该笔交易的所有操作都是由路由网关按照订单号中记录的set信息，路由到对应set来完成所有的交易流程操作。
161.网关路由会将每个set在一个周期内处理的交易请求的总数量、成功率、失败率等处理结果上报到路由管理模块；以根据处理结果，判断各set是否发生故障，这里，某个set无论是哪一层或者任意单点故障后，必将对整个set的成功率造成影响后，基于此，路由管理模块将会根据各set上报的成功率、及配置的切换阈值，按照一定的算法规则和流程，判断是否执行下发切换命令。这里，一旦下发切换命令成功，网关路由将会启动新的路由方式，如set1故障，则会将set1的流量也一并路由到set2，以实现set故障的自动切换。后续原set1对应的用户触发的交易请求，将生成与set2对应的订单号，后续该笔交易的全部交易流程也将在set2中完成，从而保证在set1内任意模块故障的情况下，均可以迅速恢复交易业务。其中，set2可以是预先设置的与set1对等的set。
162.图8是本技术实施例提供的切换命令下发的判断流程示意图，参见图8，本技术实施例提供的切换命令下发的判断流程包括：
163.步骤801：判断成功率是否大于成功率阈值，若是，则结束流程；否则，执行步骤802；
164.步骤802：判断请求数量是否小于且数量阈值，若是，则结束流程；否则，执行步骤803；
165.步骤803：判断对等set是否为空，若是，则结束流程；否则，执行步骤804；
166.步骤804：判断set是否已在切换列表中，若是，则结束流程；否则，执行步骤805；
167.步骤805：判断对等set是否已在切换列表中，若是，则结束流程；否则，执行步骤806；
168.步骤806：判断是否已经切换过，若是，则结束流程；否则，执行步骤807；
169.步骤807：判断对等set成功率是否小于成功率阈值，若是，则结束流程；否则，执行步骤808；
170.步骤808：判断(对等set成功率*100-本set成功率*100)是否大于0且大于对等set成功率的方差，若是，则执行步骤809；否则，结束流程；
171.步骤809：将本set与对等set关联并加入切换列表，将切换列表下发至网关路由执行切换。
172.当故障set恢复后，如上述set1故障恢复后，set2的流量将按照一定的规则，逐步探测set1的功能，当确定set1的功能已经完全恢复后，会重新将原set1的用户流量切回set1。
173.在实际实施时，根据d＝((i t-1)/t)*(f 1)，确定回切间隔，其中，i是配置的间隔时间(600s)，t是处理结果上报周期(45s)，f是失败次数(3次)，d是间隔多少个周期才尝试进行恢复。从公式可以看到随着恢复失败次数的增加，间隔的距离会越来越久；同时，路由管理模块发现一旦超出最大错误数，就不会再尝试自动恢复了，此时需要人工介入，其中回切量比例依次为：1％，2％，10％，20％，30％，60％，80％，最后全量回切，完成整个回切过程。
174.图9是本技术实施例提供的数据容灾的处理方法的流程示意图，参见图9，本技术实施例提供的数据容灾的处理方法包括：
175.步骤901：判断是否满足用户交易前置条件，若是，执行步骤902，否则结束处理流程。
176.这里，用户交易前置条件，用于判断用户是否满足购买条件，如年龄限制、用户资格等。
177.步骤902：路由网关获取交易请求，并根据用户尾号将交易请求路由到与用户尾号对应的set，生成订单号。
178.步骤903：上层交易服务接收到后台服务返回的含有set信息的订单号。
179.步骤904：通过与set信息对应的set，完成后续下单、支付确认等交易流程。
180.步骤905：当与set信息对应的set发生故障时，路由管理模块下发切换命令。
181.步骤906：将原set对应的用户触发的交易请求切换至对等set。
182.这里，后续的生成订单、根据订单路由完成下单、支付确认等操作将在切换后的对等set完成，实现业务功能恢复。
183.本技术实施例具有以下有益效果：
184.本技术实施例改进了业务系统中从系统内部的单点、单层或单个模块逐一来考虑实现系统容灾时，需要考虑的点过多、容灾方案不统一且差异很大造成容灾效果不理想、系
统内某一模块实现容灾困难导致系统整体容灾困难的问题，提出了交易系统从set维度整体考虑容灾的方法。该方法将交易系统按用户尾号划分为不同的set，同时将set整体的成功率、失败率等方面统计处理结果上报路由管理模块，如某个set故障的情况下，自动将系统流量从故障set切换到对等正常set，极大地简化了之前从交易系统内部各层逐一考虑各模块容灾实现的方式，同时较之之前的方案也更加可靠，有效地实现交易系统的容灾切换，更加有效的保证的交易系统业务的连续性。
185.继续对本发明实施例提供的数据容灾的处理装置进行说明。图10为本技术实施例提供的数据容灾的处理装置的组成结构示意图，参见图10，本技术实施例提供的数据容灾的处理装置255包括：
186.统计模块2551，用于统计业务系统中第一业务实体针对目标业务的业务请求的处理结果；
187.其中，所述业务系统包括至少两个业务实体，每个所述业务实体包括逻辑层服务、数据层服务及数据库，能够独立完成针对所述业务请求的处理；所述至少两个业务实体，用于共同处理所述业务系统针对所述目标业务的多个业务请求；
188.切换模块2552，用于当基于所述处理结果确定所述第一业务实体发生故障时，将所述第一业务实体待处理的业务请求切换至所述至少两个业务实体中第二业务实体，以通过所述第二业务实体包括的逻辑层服务、数据层服务及数据库，对所述第一业务实体待处理的业务请求进行处理。
189.在一些实施例中，所述业务实体包括：逻辑层服务、数据层服务及数据库；
190.所述切换模块2552，还用于当基于所述处理结果，确定所述第一业务实体的逻辑层服务、数据层服务及数据库中至少之一出现故障时，确定所述第一业务实体发生故障。
191.在一些实施例中，所述统计模块2551，还用于统计目标时间段内所述第一业务实体所处理的针对目标业务的业务请求的总数量、及所述总数量的业务请求中处理成功的业务请求的数量；
192.依据所述业务请求的总数量及所述处理成功的业务请求的数量，确定所述第一业务实体针对目标业务的业务请求的处理成功率，将所述处理成功率作为所述处理结果；
193.将所述处理成功率与成功率阈值进行比较；
194.当所述处理成功率低于成功率阈值时，确定所述第一业务实体发生故障。
195.在一些实施例中，所述统计模块2551，还用于统计目标时间段内所述业务系统中第一业务实体所处理的针对目标业务的业务请求的总数量、及所述总数量的业务请求中处理成功的业务请求的数量；
196.依据所述业务请求的总数量及所述处理成功的业务请求的数量，确定所述第一业务实体针对目标业务的业务请求的处理成功率，将所述处理成功率作为所述处理结果；
197.将所述处理成功率与成功率阈值进行比较，并将所述业务请求的总数量与数量阈值进行比较；
198.当所述处理成功率低于成功率阈值、且所述总数量达到数量阈值时，确定所述第一业务实体发生故障。
199.在一些实施例中，所述切换模块2552，还用于获取所述业务系统中业务实体间的关联关系；
200.根据所述业务实体间的关联关系，从所述至少两个业务实体中，确定与所述第一业务实体相关联的第二业务实体。
201.在一些实施例中，所述切换模块2552，还用于统计所述第二业务实体针对目标业务的业务请求的处理结果；
202.根据所述第一业务实体针对目标业务的业务请求的处理结果、及所述第二业务实体针对目标业务的业务请求的处理结果，确定所述第一业务实体的处理成功率与所述第二业务实体的处理成功率之间的差值；
203.当所述差值达到差值阈值时，将所述第一业务实体待处理的业务请求切换至所述至少两个业务实体中第二业务实体处理。
204.在一些实施例中，所述切换模块2552，还用于当所述业务系统包括的业务实体的数量多于两个时，获取所述业务系统包括的业务实体中，除所述第一业务实体外的至少两个业务实体针对所述目标业务的业务请求的处理结果；
205.根据除所述第一业务实体外的至少两个业务实体针对所述目标业务的业务请求的处理结果，分别对各业务实体进行故障判断，得到各业务实体的故障判断结果；
206.依据所述故障判断结果，从所述除所述第一业务实体外的至少两个业务实体中，选择一个未发生故障的业务实体作为第二业务实体。
207.在一些实施例中，所述切换模块2552，还用于将所述第一业务实体与所述第二业务实体进行关联，以得到所述第一业务实体与所述第二业务实体之间的路由关系；
208.在接收到所述第一业务实体待处理的业务请求时，根据所述路由关系，将所述第一业务实体待处理的业务请求，路由到所述第二业务实体。
209.在一些实施例中，所述切换模块2552，还用于获取所述第一业务实体待处理的业务请求；
210.基于所述业务请求，生成携带有第二业务实体的标识的业务信息；
211.根据所述业务信息，将所述第一业务实体待处理的业务请求路由至第二业务实体。
212.在一些实施例中，所述切换模块2552，还用于当接收到针对第一业务实体的故障恢复信息时，获取至少一个回切间隔；
213.其中，所述回切间隔，用于指示相邻两次业务请求回切操作之间的间隔时长；
214.根据所述至少一个回切间隔，将切换至所述第二业务实体的所述第一业务实体待处理的业务请求切换回所述第一业务实体。
215.在一些实施例中，所述切换模块2552，还用于获取回切失败的次数；
216.根据所述回切失败的次数，确定至少一个回切间隔，所述回切间隔与所述回切次数呈正相关关系。
217.在一些实施例中，所述切换模块2552，还用于在将所述第一业务实体待处理的业务请求切换回所述第一业务实体的过程中，周期性统计已切换回所述第一业务实体的业务请求的处理结果；
218.当所述处理结果表征所述第一业务实体再次发生故障时，将所述第一业务实体待处理的业务请求全量切换至所述第二业务实体。
219.在一些实施例中，所述切换模块2552，还用于当存在与所述第一业务实体相关联
的第二业务实体时，获取切换列表中包括的业务实体；
220.基于所述切换列表中包括的业务实体，确定所述切换列表中未包括所述第一业务实体和所述第二业务实体时，获取针对所述第一业务实体的切换记录；
221.当所述切换记录表征未执行针对所述第一业务实体的业务请求切换处理时，将所述第一业务实体及所述第二业务实体添加至切换列表；
222.基于所述切换列表，将所述第一业务实体待处理的业务请求路由至所述至少两个业务实体中第二业务实体。
223.本技术实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本技术实施例上述的数据容灾的处理方法。
224.本技术实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本技术实施例提供的方法，例如，如图4示出的方法。
225.在一些实施例中，计算机可读存储介质可以是fram、rom、prom、eprom、eeprom、闪存、磁表面存储器、光盘、或cd-rom等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
226.在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
227.作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(html，hyper text markup language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。
228.作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
229.以上所述，仅为本技术的实施例而已，并非用于限定本技术的保护范围。凡在本技术的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本技术的保护范围之内。