CN115700489A - 应急切换方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明提供一种应急切换方法、装置、电子设备及存储介质，该方法包括：在生产系统中至少一个生产中心异常的情况下，将异常的生产中心对应的目标业务的业务请求报文切换至应急系统；所述应急系统基于所述业务请求报文处理所述目标业务；其中，所述应急系统是基于所述生产系统版本直接构建而成。本发明通过采用生产系统版本直接构建的应急系统接收异常生产中心对应的业务请求报文，执行对应的目标业务，实现在应急系统的全量业务支撑，避免开发和维护两套版本的巨大工作量。

Description

应急切换方法、装置、电子设备及存储介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种应急切换方法、装置、电子设备及存储介质。

背景技术

生产系统是服务于用户的实时系统，为了保证用户体验，应尽量减少业务停服时间。在日常运营中，系统升级、设备故障、网络中断等各种情况都会导致生产系统停服。传统的保障方案包含了高可用、数据库容灾切换、应急切换等。其中，应急切换可应对应用层面和数据库层面的停服场景。

现有应急系统的业务分为查询类业务和受理类业务两类。

应急查询类业务只涉及读操作，以容灾数据库如高级数据保护(Active DataGuard，ADG)库、业务连续卷(Business Continuance Volume，BCV)等作为数据源，处理逻辑和生产系统相同。

应急受理类业务的处理逻辑和生产系统不同，生产处理逻辑是实时处理完一个业务的所有子流程；应急处理逻辑是将一个业务拆分为核心子流程和非核心子流程，核心子流程实时处理，非核心子流程暂不处理，只保存业务信息至应急库，在生产系统恢复后，将业务信息重新拼装为报文，调用回写服务，将业务重做一遍，重做过程中过滤掉已经处理过的核心子流程，避免重复处理，通过核心子流程的实时处理和业务重做，实现整个业务的完整处理。受理类业务涉及读操作和写操作，读操作以容灾数据库作为数据源，写操作以应急库作为数据源。

以充值业务为例，整个业务流程可分为校验、上账、复机、记录业务流水四个子流程，校验和复机影响用户使用体验，是核心子流程，上账和记录业务流水不影响用户使用体验，是非核心子流程。该业务在生产系统、应急系统、生产系统回写服务的处理如表1所示：

表1

系统/子流程	校验	上账	复机	记录业务流水
					生产系统	处理	处理	处理	处理
应急系统	实时处理	只保留信息	实时处理	只保留信息
					回写服务	不处理	处理	不处理	处理

由此可见，现有应急系统基于业务流程实现，与业务强相关，每种业务必须根据自己特定业务流程开发配套的应急处理逻辑，开发和维护工作量巨大，只适宜支撑少量业务的应急处理，全量业务应急支撑难度大。

发明内容

本发明提供一种应急切换方法、装置、电子设备及存储介质，用以解决现有技术中全量业务应急支撑难度大的缺陷，实现了在应急系统的全量业务支撑，减少开发和维护两套版本的巨大工作量。

第一方面，本发明提供一种应急切换方法，包括：

在生产系统中至少一个生产中心异常的情况下，将异常的生产中心对应的目标业务的业务请求报文切换至应急系统；

所述应急系统基于所述业务请求报文处理所述目标业务；

其中，所述应急系统是基于所述生产系统版本直接构建而成。

可选地，根据本发明提供的应急切换方法，所述应急系统基于所述业务请求报文处理所述目标业务，包括：

所述应急系统基于所述业务请求报文处理所述目标业务，获取应急业务数据；

其中，所述应急系统中的所述应急业务数据的数据对象版本和所述生产系统中的数据对象版本相同。

可选地，根据本发明提供的应急切换方法，所述应急系统基于所述业务请求报文处理所述目标业务，获取应急业务数据，包括：

应急系统在基于所述业务请求报文处理所述目标业务的过程中产生的每个SQL都传入数据库访问控制器，以使数据库访问控制器对所述SQL进行数据处理获得处理结果；

应急系统获取所述处理结果，并基于所述处理结果完成所述目标业务的处理，在应急数据库中生成所述应急业务数据；

其中，所述应急数据库用于在切换至生产系统后将所述应急业务数据同步至生产数据库；

其中，所述生产数据库中包括所述生产系统中的生产业务数据。

可选地，根据本发明提供的应急切换方法，所述方法还包括：

从所述业务请求报文中提取所述目标业务对应的用户基础信息和业务类型信息；

基于所述用户基础信息，从配置库中查询用户的用户归属区域，获取所述目标业务的业务流量；

基于所述目标业务的业务流量，从所述配置库中查询所述目标业务的业务流量切换信息，所述业务流量切换信息用于体现所述业务流量处于生产状态或应急状态或不可用状态；

基于所述业务流量切换信息，从应急库的ADG数据过滤表中查询所述用户基础信息，确认所述用户无待处理的应急业务数据。

可选地，根据本发明提供的应急切换方法，在确认所述用户无待处理的应急业务数据之后，所述方法还包括:

若所述业务流量为生产状态，则确定将所述业务请求报文分发至所述目标业务对应的生产系统；若所述业务流量为应急状态，则在基于所述业务类型确定所述目标业务不在应急业务禁止名单的情况下，确定将目标业务的业务请求报文切换至应急系统；

若所述业务流量为不可用状态，则确定结束处理所述业务请求报文。

可选地，根据本发明提供的应急切换方法，所述方法还包括：

基于预设周期，更新所述业务流量的业务流量切换信息。

可选地，根据本发明提供的应急切换方法，所述更新所述业务流量的业务流量切换信息，包括：

基于业务请求报文，访问配置库，获取生产系统的探测内容和应急系统的探测内容；

基于所述生产系统的探测内容和生产系统的系统指标，应急系统的探测内容和应急系统的系统指标，更新所述业务流量的业务流量切换信息。

第二方面，本发明提供一种应急切换装置，包括：

切换模块，用于在生产系统中至少一个生产中心异常的情况下，将异常的生产中心对应的目标业务的业务请求报文切换至应急系统；

处理模块，用于所述应急系统基于所述业务请求报文处理所述目标业务；

其中，所述应急系统是基于所述生产系统版本直接构建而成。

第三方面，本发明还提供一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现如第一方面所述应急切换方法的步骤。

第四方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述应急切换方法的步骤。

本发明提供的一种应急切换方法、装置、电子设备及存储介质，通过采用生产系统版本直接构建的应急系统接收异常生产中心对应的业务请求报文，执行对应的目标业务，实现在应急系统的全量业务支撑，避免开发和维护两套版本的巨大工作量。

附图说明

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

图1是本发明提供的应急切换方法的流程示意图；

图2是本发明提供的业务处理系统的结构示意图；

图3是本发明提供的生产中心运行状态切换信息流程示意图；

图4是本发明提供的应急切换装置的结构示意图；

图5是本发明提供的电子设备的实体结构示意图。

具体实施方式

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

图1是本发明提供的应急切换方法的流程示意图，如图1所示，该方法包括如下步骤：

步骤100，在生产系统中至少一个生产中心异常的情况下，将异常的生产中心对应的目标业务的业务请求报文切换至应急系统；

步骤110，所述应急系统基于所述业务请求报文处理所述目标业务；

其中，所述应急系统是基于所述生产系统版本直接构建而成。

生产系统是服务于用户的实时系统，为了保证用户满意度，可以尽量减少停服时间，实现业务连续性保障。在日常运营中，系统升级、设备故障、网络中断等各种计划内调整和非计划内的突发故障，都可能导致生产系统局部或全部停服，可以启用高可用、中心切换、数据库容灾切换、应急切换等方案以保障用户服务不中断。

高可用主要应对生产系统个别应用或主机的停服场景，中心切换主要应对单个中心级别所有应用的停服场景，数据库容灾切换主要应对生产数据库停服场景，应急切换可应对各种级别的生产应用或生产数据库停服场景。从严重程度来说，高可用面对的是轻量级场景，其他方案面对的是重量级场景。从恢复时间来说，数据库容灾需要30-60分钟，其他方案需要时间小于1分钟。因此，应急切换具有适用范围广、恢复时间短、可应对重量级场景等优势，是核心保障方案。

因此，本发明可以在生产系统中至少一个生产中心异常的情况下，将异常的生产中心对应的目标业务的业务请求报文切换至应急系统，应急系统基于所述业务请求报文处理所述目标业务；保障用户服务不中断。

图2是本发明提供的业务处理系统的结构示意图，如图2所示，应急系统包括一个应急中心为例，业务处理系统可以包括多个生产中心和一个应急中心，多个生产中心共同组成生产系统。其中，还包括配置库，配置库保存的主要数据及作用如下：

(1)用户归属区域信息：用于判断一个用户的业务请求需要分发到哪个中心；用于判断应急业务处理和应急数据同步需要访问生产系统哪个数据库。

其中，用户在数据表中可以使用多种方式表示，比方说用户号码、用户编码(ID)等，只要具有全局唯一性即可，本方案统一以用户号码表示。

(2)业务流量切换信息：用于判断一个业务请求需要分发到生产系统、应急系统还是直接返回；用于判断应急业务数据是否启动自动同步。

(3)探测指标异常阈值及切换规则：用于系统和业务异常状态的判断，并据此自动更新业务流量切换信息。

(4)版本信息及相应的探测内容：根据不同系统的不同版本信息，获取对应版本的探测内容，完成探测。

其中，应急系统需要使用到配置库的多项配置数据，从便捷性角度出发，对于不经常更新的数据，如用户归属区域信息、版本信息及相应的探测内容等，可周期性从配置库同步到应急系统，甚至放到内存中，以提高访问效率。

可选地，业务处理系统还包括服务路由控制器；

可选地，服务路由控制器从业务请求中提取用户号码、业务类型等参数，根据配置库中用户归属区域信息、业务流量切换信息等确定后续的路由处理。

其中，对于多中心的系统而言，涉及到业务请求往哪个中心路由分发，路由分发可以在服务路由控制器中实现，也可以在接入层实现，本质无区别。本方案假设在接入层实现。

可选地，业务处理系统还包括探测装置；

可选地，探测装置可以根据配置库的版本信息及相应的探测内容，使用探测内容(请求报文、自动化测试脚本或其他)定期探测生产服务和应急服务，根据探测结果，结合配置库的探测指标异常阈值及切换规则，自动更新业务流量切换信息。

可选地，探测装置可以根据配置库的版本信息及相应的探测内容，自动进行版本兼容性的验证。

可选地，业务处理系统还包括数据访问控制器；

对于应用服务而言，数据访问控制器就相当于数据库。

可选地，数据访问控制器可以解析传入的SQL，判断是读操作还是写操作，根据传入的用户号码，以及配置库的用户归属区域信息，确定并访问相关数据库。多数据中心的情况下，存在多个生产系统ADG库，读操作必然会分路由访问；写操作视应急库数量而定，如果只有一个应急库，直接访问即可，事务控制使用普通事务，否则需要分路由访问，事务控制使用分布式事务。

可选地，数据访问控制器可以根据解析的SQL操作类型和条件，进行转换，生成可直接同步生产库的应急业务数据，保存到应急库。

可选地，业务处理系统还包括同步分发器；

可选地，同步分发器可以根据配置库用户归属区域信息、业务流量切换信息，自动将应急业务数据同步生产库。

现有的应急处理逻辑和生产处理逻辑是同一业务在不同场景下的处理方式，最终产生相同的生产业务数据，二者具有相关性，两套应用版本需要保持同步升级，以保证兼容性，兼容性保障依赖于版本和开发的管理，如果系统本身不提供保障机制，维护工作量大。

因此，为了克服上述缺陷，本发明中的应急系统可以是基于生产系统版本直接构建而成，实现全量业务支撑，减少开发和维护两套版本的巨大工作量。

可选地，生产系统版本有多个，每个版本分为可分为应用服务版本和数据对象版本，应急系统的应用服务版本可以和生产系统不同，应急系统中应急库的数据对象选择与生产系统相同，由于应用服务版本和数据对象版本可能不同，需要考虑兼容性的问题，因此可以进一步进行兼容性检测。

可选地，生产系统版本包含了应用服务版本和数据对象版本，生产系统和应急系统的应用服务版本可能不同，数据对象版本是相同的；在生产系统内部，应用服务版本和数据对象版本需要保持版本统一，在应急系统内部，应用服务版本和数据对象版本可以不统一。应急系统部署了两套服务以及与服务对应的数据对象，一套用于应急业务处理，一套用于探测，其他版本情况如下表2所示：

表2

可选地，应急系统直接部署生产系统的应用服务版本，可以选择生产系统在用版本、低版本、高版本。从稳定性和可用性考虑，可以优选选择低版本，因为低版本在生产系统经历过长时间运行过，验证充分；存在多个低版本时，考虑到与在用版本的兼容性概率，选择发布时间和在用版本发布时间最为接近的低版本；如无合适的低版本，可选择生产系统在用版本。

可选地，不同的应用版本处理逻辑和步骤可能存在差异，但是只要最终查询或生成的业务数据是一致的，就可以认为应用版本兼容。

可选地，验证是探测生产服务和探测服务，比对二者探测结果来判断兼容性。由于应急服务和探测服务的应用版本一致，因此只要生产服务和探测服务兼容，生产服务和应急服务也兼容。

可选地，版本兼容性的针对对象是业务类型，允许出现若干业务兼容，若干业务不兼容，不兼容业务加入应急业务禁止名单即可。

可选地，兼容性检测机制的处理方法如下：

步骤1a：可以删除探测库所有业务数据，从生产库中将探测用户的业务数据复制到探测库，作为基准数据。

步骤2a：可以探测用户在生产系统进行探测，获取探测后的业务数据Dc(生产库)；探测用户在应急系统进行探测(探测服务)，获取探测后的业务数据Dt(探测库)。

若出现下列任何一种不兼容的情况，则可以认为不兼容：

情况1b：探测失败。常见情况包含接口调用失败、参数不匹配、无法入库等。

情况2b：Dc和Dt不完全一致。常见情况包含记录数量不同、Dc和Dt对应记录的字段取值不同等。

可选地，探测可以采用自动化测试工具、报文模拟工具、脚本等业界成熟技术，不赘述。

可选地，应急业务处理可能出现应用服务各部分版本不同的情况，比如系统的服务开放给第三方平台，第三方平台使用Vc版本接口调用服务，如果系统切换到应急，内部处理逻辑是使用Ve版本处理的。此情况不影响兼容性校验的正确性。

可选地，Dc和Dt的一致性可以利用代码实现，更便捷的方法是利用Oracle的dblink对生产库和探测库的结果进行正向和反向的minus操作。

可选地，兼容性的探测是一次性的，生产系统或应急系统每次升级后完成。业务流量切换状态的探测是周期性的。

步骤3a：如果版本不兼容，可以将对应的业务类型加入应急业务禁止名单。

应急系统的数据对象版本和生产系统一致，可以保证应急业务数据保存到应急库时信息不会丢失，以及探测结果的直接数据比对。

出于高并发、故障隔离、划小管理等目的，生产系统根据区域等属性划分为多个生产中心。同理，应急系统也可以划分为多个应急中心，考虑到应急系统使用频率较低，可以只建设一个应急中心，利于节省成本。

本发明在生产多中心架构的基础上，利用生产系统版本构建一个应急系统，通过业务探测和服务路由控制，实现生产业务停服后的自动应急切换和生产业务恢复后的自动回切生产，在应急切换期间办理业务时通过业务数据的解析和转换生成可直接同步生产数据库的应急业务数据，在生产回切之后完成此数据的自动同步，保证全局数据的完整性和一致性。

本发明提供的一种应急切换方法，通过采用生产系统版本直接构建的应急系统接收异常生产中心对应的业务请求报文，执行对应的目标业务，实现在应急系统的全量业务支撑，避免开发和维护两套版本的巨大工作量。

可选地，所述应急系统基于所述业务请求报文处理所述目标业务，包括：

所述应急系统基于所述业务请求报文处理所述目标业务，获取应急业务数据；

其中，所述应急系统中的所述应急业务数据的数据对象版本和所述生产系统中的数据对象版本相同。

现有应急系统业务重做方式，本质上可分为服务调用和应急业务数据同步两部分，服务调用是应急业务数据同步的手段，都是在回切生产之后完成。

现有应急系统采用业务信息缓存后重做的机制，如果要回切生产系统，必须先处理完应急系统缓存的所有业务信息，否则生产数据不完整，生产系统无法正常使用。生产系统故障时间越长，应急切换后缓存信息越多，重做所需时间越长，生产系统恢复越慢，严重影响用户感知。

因此，为了克服上述缺陷，本发明可以不拆分业务子流程，直接调用业务所有流程的服务，通过数据库访问控制器提取服务访问数据库的SQL并进行解析处理，结合ADG库存量业务数据的加工转换，在应急数据库生成可直接批量同步至生产数据库的最终业务数据，提高同步效率。

因此，所述应急系统在基于所述业务请求报文处理所述目标业务，时，可以获取应急业务数据；其中，所述应急系统中的所述应急业务数据的数据对象版本和所述生产系统中的数据对象版本相同，则可以实现将应急中心的应急业务数据直接同步给生产数据库。

可选地，所述应急系统基于所述业务请求报文处理所述目标业务，获取应急业务数据，包括：

应急系统在基于所述业务请求报文处理所述目标业务的过程中产生的每个SQL都传入数据库访问控制器，以使数据库访问控制器对所述SQL进行数据处理获得处理结果；

应急系统获取所述处理结果，并基于所述处理结果完成所述目标业务的处理，在应急数据库中生成所述应急业务数据；

其中，所述应急数据库用于在切换至生产系统后将所述应急业务数据同步至生产数据库；

其中，所述生产数据库中包括所述生产系统中的生产业务数据。

可选地，本发明在回切生产系统的时候，支持应急数据同步和生成业务放开的同步进行，消除现有方案中切换应急和回切生产之间的空白期，实现生产系统和应急系统两者无缝互切。

可选地，每个生产中心可以有一套数据库，为主备模式，主库为生产库，提供读写功能，备库为ADG库，提供只读功能，通过Oracle ADG技术可以从主库实时同步数据到ADG库。

可选地，每个应急中心可以有一套应急数据库，用于应急切换期间业务数据的读写操作，读操作同时复用生产中心ADG库。

可选地，查询类业务和办理类业务都是由若干子流程组成，对于具体一个子流程，可能会涉及数据库访问，也可能不涉及数据库访问，本发明的实现可以不考虑具体有多少子流程以及每个子流程的业务处理逻辑，只需要考虑涉及到数据库访问子流程的SQL和数据的处理。

其中，业务处理流程包括如下步骤：

步骤1c：服务路由控制器解析业务请求，符合规则时分发到应急中心。

步骤2c：应急中心的应急服务向数据库访问控制器发起一个事务，数据库访问控制器向应急库发起一个事务。

步骤3c：应急服务在业务处理过程中产生的每个SQL都传入数据库访问控制器，由数据库访问控制器针进行SQL和数据的处理，并将处理结果返回应急服务，应急服务根据返回的处理结果继续处理后续子流程。

步骤4c：应急服务处理完所有子流程，或者在处理过程中异常中止时，通知数据库访问控制器本事务结束(commit或者rollback)，数据库访问控制器根据通知对应急库的事务进行commit或者rollback。

其中，SQL语句分为查询(select)、插入(insert)、修改(update)、删除(delete)等操作类型，每种操作类型的处理方法可以不同，总体处理逻辑可以包括：查询SQL，从ADG库和应急库中查询出数据，并过滤掉无效数据，查询结果返回应急服务；插入/修改/删除SQL，进行SQL的解析与转换，从ADG库和应急库中查询和过滤相关数据，生成可直接同步生产库的最终业务数据，保存到应急库，同时，记录用户号码、业务数据表、ADG相关rowid、SQL操作类型、处理时间等信息记录到“ADG数据过滤表”，一方面用于ADG无效数据过滤，另外一方面用于回切生产后的数据同步处理。

可选地，因为存在多个ADG库，在ADG库访问之前，可以先根据用户号码归属区域信息确认具体的ADG库。

其中，rowid为Oracle数据库的数据表的内置字段，具有数据库级别的全局唯一性。

可选地，各种SQL操作类型的具体处理方法如下：

(1)查询(select)；

步骤1d：从原始SQL解析得到用户号码、业务数据表等信息，根据这些信息到ADG数据过滤表查询需要过滤的rowid。

步骤2d：如果能够查询到过滤的rowid，在原始SQL的where子句增加rowid过滤条件，到ADG库查询数据；如果查询不到，在ADG库执行原始SQL。

步骤3d：使用原始SQL，到应急库查询数据。

步骤4d：合并ADG库和应急库的查询数据，即为最终数据集，返回应急服务。

(2)插入(insert)；

步骤1e：原始SQL直接在应急库中执行。

步骤2e：将用户号码、业务数据表、rowid等信息记录到ADG数据过滤表，其中，rowid填写空值(null)，表示在生产系统没有此数据记录。

(3)修改(update)；

步骤1f：从原始SQL解析得到用户号码、业务数据表等信息，根据这些信息到ADG数据过滤表查询到需要过滤的rowid。

步骤2f：将原始SQL转换为select语句，字段列表增加rowid字段，where子句为原始SQL的where子句；如果能够查询到过滤的rowid，加上rowid过滤条件；在ADG库执行转换后的select语句查询数据。

步骤3f：查询结果insert到应急库。

步骤4f：在应急库执行原始SQL。

步骤5f：将用户号码、业务数据表、rowid等信息记录到ADG数据过滤表，其中，rowid为步骤2f所查询所获得。

(4)删除(delete)；

步骤1g：从原始SQL解析得到用户号码、业务数据表等信息，根据这些信息到ADG数据过滤表查询到需要过滤的rowid。

步骤2g：将原始SQL转换为select语句，字段列表增加rowid字段，where子句为原始SQL的where子句；如果能够查询到过滤的rowid，加上rowid过滤条件；在ADG库执行转换后的select语句查询数据。

步骤3g：将用户号码、业务数据表、rowid等信息记录到ADG数据过滤表，其中，rowid为步骤2g所查询所获得。

(5)复合语句；

所有操作类型语句，都可能包含select子句，如：

insert into table_name(field_list)select field_list from table_name；

此时从最内层的select子句开始，由内往外，遵循上述A-D的处理原则顺次处理。

可选地，应急中心可以定时读取配置库的业务流量切换信息，发现该业务流量恢复生产状态后，将应急库的业务数据同步到生产库。具体处理过程可以如下步骤：

步骤1h：暂停业务流量切换状态的探测。

步骤2h：读取应急库的ADG数据过滤表，取出第一个用户号码。

步骤3h：根据该用户号码，从应急库的ADG数据过滤表查询到该用户办理应急业务所涉及的业务数据表以及生产库业务数据表的rowid。

步骤4h：根据该用户号码查询用户归属区域信息，确认具体同步的生产库，根据业务表名、rowid，在对应的生产库中删除对应的业务数据。

步骤5h：根据用户号码、业务表名，查询应急库中对应的业务数据，并将查询到的业务数据直接插入生产库。

步骤6h：备份并删除应急库的ADG数据过滤表中该用户的所有记录，此时，允许该用户在生产系统办理业务。

步骤7h：重复步骤2h-6h，直到处理完所有用户，此时，全部用户在生产系统都可以办理业务，同步过程结束。

步骤8h：恢复业务流量切换状态的探测。

以用户1和用户2分别对应优惠券A和优惠券B为例，对单个SQL的处理方法进行示例性描述。

其中，业务场景与规则为：用户有优惠券，优惠券可以自己使用，可以赠送给其他用户，优惠券有有效期，过期优惠券会被删掉。优惠券信息保存在业务表“YHQ”中。假设用户1和用户2目前各有1张优惠券，初始数据如下：

生产库和ADG库：2条数据；

用户	产品	状态	rowid
				用户1	优惠券A	未使用	1111
用户2	优惠券B	未使用	2222

应急库：0条数据，表结构和生产库相同(应急库的数据记录的rowid不用控制，因此不列出)；

用户	产品	状态
			无记录

应急库的ADG数据过滤表“GL”：0条数据，表结构如下：

用户	业务表	生产rowid
			无记录

可以模拟一系列操作，假设这些操作分别在生产系统和应急系统处理(应急系统处理的前提是生产系统停服，ADG库保留原始的静态数据)，对比两种处理在最终业务数据的结果，可以看出结果一致；

操作1：用户1查询可用的优惠券；

原始SQL：select*from YHQ where用户＝'用户1'and状态＝'未使用'；

生产系统中：查询生产库，结果如下表：

用户	产品	状态	rowid
				用户1	优惠券A	未使用	1111

应急系统中：查询表GL，无数据，原始SQL直接在ADG库执行，结果如下表：

用户	产品	状态	rowid
				用户1	优惠券A	未使用	1111

因此生产系统和应急系统的处理结果一致；

应急库目前全量数据为：

表YHQ(无记录)：

用户	产品	状态
			无记录

表GL(无记录)：

用户	业务表	生产rowid
			无记录

操作2：用户1将优惠券A赠送给用户2；

原始SQL：update YHQ set用户＝'用户2'where用户＝'用户1'and产品＝'优惠券A'；

生产系统中：

用户	产品	状态	rowid
				用户2	优惠券A	未使用	1111

应急系统中：查询表GL，SQL：select*from GL where用户＝'用户1'and业务表＝'YHQ'，查询不到记录；

用户	业务表	生产rowid
			无记录

根据原始SQL转换查询SQL：select*,rowid from YHQ where用户＝'用户1'and产品＝'优惠券A'，在ADG库执行，结果如下表：

用户	产品	状态	rowid
				用户1	优惠券A	未使用	1111

该结果插入应急库，结果如下表：

用户	产品	状态
			用户1	优惠券A	未使用

应急库执行原始SQL，结果如下表：

用户	产品	状态
			用户2	优惠券A	未使用

记录表GL，结果如下表：

用户	业务表	生产rowid
			用户1	YHQ	1111

因此，生产系统和应急系统的处理结果一致；

应急库目前全量数据与操作1中所获得的应急库相比有变化，具体为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	未使用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111

操作3：用户1再次查询可用的优惠券；

原始SQL：select*from YHQ where用户＝'用户1'and状态＝'未使用'；

生产系统中：查询生产库，结果如下表：

用户	产品	状态	rowid
				无记录

应急系统中：查询表GL，SQL：select*from GL where用户＝'用户1'and业务表＝'YHQ'，查询结果如下表(需要过滤的生成rowid为1111)：

用户	业务表	生产rowid
			用户1	YHQ	1111

根据原始SQL转换查询SQL，并加上过滤条件：select*from YHQ where 用户＝'用户1'and 状态＝'未使用'and rowid not in (1111)，在ADG库执行，查询不到记录，如下表：

用户	产品	状态
			无记录

应急库执行原始SQL，查询不到记录，如下表：

用户	产品	状态
			无记录

合并ADG库和应急库的执行结果，即最终结果，如下表：

用户	产品	状态
			无记录

因此生产系统和应急系统的处理结果一致；

应急库全量数据与操作2中获得的应急库相比无变化，具体为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	未使用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111

操作4：用户2查询可用的优惠券；

原始SQL：select*from YHQ where用户＝'用户2'and状态＝'未使用'；

生产系统中：

用户	产品	状态	rowid
				用户2	优惠券A	未使用	1111
用户2	优惠券B	未使用	2222

应急系统中：查询表GL，SQL：select*from GL where用户＝'用户2'and业务表＝'YHQ'，查询不到记录，如下表：

用户	业务表	生产rowid
			无记录

原始SQL直接在ADG库执行，结果如下表：

用户	产品	状态
			用户2	优惠券B	未使用

原始SQL直接在应急库执行，结果如下表：

用户	产品	状态
			用户2	优惠券A	未使用

合并ADG库和应急库的执行结果，即最终结果，如下表：

用户	产品	状态
			用户2	优惠券A	未使用
用户2	优惠券B	未使用

因此生产系统和应急系统的处理结果一致；

应急库目前全量数据与操作3相比无变化，具体为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	未使用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111

操作5：系统给用户2赠送1张优惠券(优惠券名：优惠券C)

原始SQL：insert into YHQ values('用户2','优惠券C','未使用')

生产系统中：

用户	产品	状态	rowid
				用户2	优惠券C	未使用	3333

应急系统中：原始SQL直接在应急库执行，结果如下表：

用户	产品	状态
			用户2	优惠券C	未使用

记录表GL，结果如下表(因为生产系统原始记录中没有优惠券C的记录，所以生产rowid为空)：

用户	业务表	生产rowid
			用户2	YHQ	null

因此生产系统和应急系统的处理结果一致；

应急库目前全量数据与操作4相比有变化，具体为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	未使用
用户2	优惠券C	未使用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111
用户2	YHQ	null

操作6：用户2使用优惠券A；

原始SQL：update YHQ set状态＝'已用'where用户＝'用户2'and产品＝'优惠券A'；

生产系统中：

用户	产品	状态	rowid
				用户2	优惠券A	已用	1111

应急系统中：查询表GL，SQL：select*from GL where用户＝'用户2'and业务表＝'YHQ'，查询不到记录，如下表：

用户	业务表	生产rowid
			无记录

根据原始SQL转换查询SQL：select*,rowid from YHQ where用户＝'用户2'and产品＝'优惠券A'，在ADG库执行，查询不到记录，如下表：

用户	产品	状态
			无记录

该结果插入应急库，结果如下表(ADG库查询不到记录，插入操作是空操作)：

用户	产品	状态
			无记录

应急库执行原始SQL，结果如下表：

用户	产品	状态
			用户2	优惠券A	已用

记录过滤表，结果如下表(ADG库查询不到记录，插入操作是空操作)：

用户	业务表	生产rowid
			无记录

生产系统和应急系统的处理结果一致；

应急库目前全量数据与操作5相比有变化，具体为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	已用
用户2	优惠券C	未使用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111
用户2	YHQ	null

操作7：用户2的优惠券B过期；

原始SQL：delete from YHQ where用户＝'用户2'and产品＝'优惠券B'；

生产系统中：删除成功，使用SQL：select*from YHQ where用户＝'用户2'and产品＝'优惠券B'，查询不到记录，如下表：

用户	产品	状态	rowid
				无记录

应急系统中：查询表GL，SQL：select*from GL where用户＝'用户2'and业务表＝'YHQ'，结果如下(生产rowid为null的无需过滤)：

用户	业务表	生产rowid
			用户2	YHQ	null

根据原始SQL转换查询SQL：select*,rowid from YHQ where用户＝'用户2'and产品＝'优惠券B'，在ADG库执行，结果如下表：

用户	产品	状态
			用户2	优惠券B	未使用

记录表GL，结果如下表：

用户	业务表	生产rowid
			用户2	YHQ	2222

生产系统和应急系统的处理结果一致；

应急库目前全量数据与操作6相比有变化，具体为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	已用
用户2	优惠券C	未使用

表GL：

操作8：用户2查询可用优惠券，查到1张(优惠券C)；

原始SQL：select*from YHQ where用户＝'用户2'and状态＝'未使用'；

生产系统中：

用户	产品	状态	rowid
				用户2	优惠券C	未使用	3333

应急系统中：查询表GL，SQL：select*from GL where用户＝'用户2'and业务表＝'YHQ'，在ADG库执行，结果如下表(生产rowid为null的无需过滤)：

用户	业务表	生产rowid
			用户2	YHQ	null
用户2	YHQ	2222

原始SQL加上过滤条件：select*from YHQ where用户＝'用户2'and状态＝'未使用'and rowid not in(2222)，在ADG库执行，查询不到记录，如下表：

用户	产品	状态
			无记录

原始SQL直接在应急库执行，结果如下表：

用户	产品	状态
			用户2	优惠券C	未使用

合并ADG库和应急库的执行结果，即最终结果，如下表：

用户	产品	状态
			用户2	优惠券C	未使用

生产系统和应急系统的处理结果一致；

应急库目前全量数据与操作7相比无变化，具体为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	已用
用户2	优惠券C	未使用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111
用户2	YHQ	null
			用户2	YHQ	2222

操作9：用户2使用优惠券C；

原始SQL：update YHQ set状态＝'已用'where用户＝'用户2'and产品＝'优惠券C'；

生产系统中：

用户	产品	状态	rowid
				用户2	优惠券C	已用	3333

应急系统中：查询表GL，SQL：select*from GL where用户＝'用户2'and业务表＝'YHQ'，结果如下表(生产rowid为null的无需过滤)：

用户	业务表	生产rowid
			用户2	YHQ	null
用户2	YHQ	2222

根据原始SQL转换查询SQL，并加上过滤条件：select*,rowid from YHQ where用户＝'用户2'and产品＝'优惠券C'and rowid not in(2222)，在ADG库执行，查询不到记录，如下表：

用户	产品	状态
			无记录

该结果插入应急库，结果如下表(ADG库查询不到记录，插入操作是空操作)：

用户	产品	状态
			无记录

应急库执行原始SQL，结果如下表：

用户	产品	状态
			用户2	优惠券C	已用

记录过滤表，结果如下表(ADG库查询不到记录，插入操作是空操作)：

用户	业务表	生产rowid
			无记录

生产系统和应急系统的处理结果一致；

应急库目前全量数据与操作8相比无变化，具体为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	已用
用户2	优惠券C	已用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111
用户2	YHQ	null
			用户2	YHQ	2222

操作10：用户2查询可用优惠券，查询不到记录；

原始SQL：select*from YHQ where用户＝'用户2'and状态＝'未使用'；

生产系统中：

用户	产品	状态	rowid
				无记录			3333

应急系统中：查询表GL，SQL：select*from GL where用户＝'用户2'and业务表＝'YHQ'，在ADG库执行，结果如下表(生产rowid为null的无需过滤)：

用户	业务表	生产rowid
			用户2	YHQ	null
用户2	YHQ	2222

原始SQL加上过滤条件：select*from YHQ where用户＝'用户2'and状态＝'未使用'and rowid not in(2222)，在ADG库执行，查询不到记录，如下表：

用户	产品	状态
			无记录

原始SQL直接在应急库执行，查询不到记录，如下表：

用户	产品	状态
			无记录

合并ADG库和应急库的执行结果，即最终结果，如下表：

用户	产品	状态
			无记录

生产系统和应急系统的处理结果一致；

应急库目前全量数据与操作9相比无变化，具体如下表：表YHQ：

用户	产品	状态
			用户2	优惠券A	已用
用户2	优惠券C	已用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111
用户2	YHQ	null
			用户2	YHQ	2222

在操作结束后，可以模拟数据同步的情况；

1)假设所有处理都在生产系统完成；

生产系统的最终业务数据为下表：

用户	产品	状态	rowid
				用户2	优惠券A	已用	1111
用户2	优惠券C	已用	3333

2)假设所有处理都在应急系统完成；

生产系统和ADG的原始数据为下表：

用户	产品	状态	rowid
				用户1	优惠券A	未使用	1111
用户2	优惠券B	未使用	2222

应急系统的数据为：

表YHQ：

用户	产品	状态
			用户2	优惠券A	已用
用户2	优惠券C	已用

表GL：

用户	业务表	生产rowid
			用户1	YHQ	1111
用户2	YHQ	null
			用户2	YHQ	2222

同步处理如下所示：

A、读取表GL，获得第1个用户“用户1”；

B、根据“用户1”，到表GL查询其ADG数据过滤记录；

SQL：select用户,业务表,生产rowid from GL where用户＝'用户1'，结果如下表：

用户	业务表	生产rowid
			用户1	YHQ	1111

C、到生产库的数据表YHQ中删除对应rowid的记录；

SQL：delete from YHQ where rowid in(1111)，在生产库执行，生产库全量数据如下表(用户1所有记录被删除)：

用户	产品	状态	rowid
				用户2	优惠券B	未使用	2222

D、应急库中用户1的数据直接插入生产库，在生产库执行后，生产库全量数据如下：

SQL：insert into YHQ@生产库dblink名select*from YHQ where用户＝'用户1'(假设使用dblink方式同步，也可以使用应用程序等方式同步)；

用户	产品	状态	rowid
				用户2	优惠券B	未使用	2222

其中，用户1在应急库无数据，同步生产库为空操作

E、应急库的表YHQ、GL删除用户1的相关数据，至此用户1的应急业务数据处理完毕，此时生产系统允许用户1办理业务；

F、继续处理用户2的应急业务数据，首先根据“用户2”，到表GL查询其ADG数据过滤记录

SQL：select用户,业务表,生产rowid from GL where用户＝'用户2'，结果如下表：

用户	业务表	生产rowid
			用户2	YHQ	null
用户2	YHQ	2222

G、到生产库的数据表YHQ中删除对应rowid的记录；

SQL：delete from YHQ where rowid in(2222)，在生产库执行，生产库全量数据如下表(用户2所有记录被删除)：

用户	产品	状态	rowid
				无记录

H、应急库中用户1的数据直接插入生产库，在生产库执行后，生产库全量数据如下表(注意rowid会生成新值)：

SQL：insert into YHQ@生产库dblink名select*from YHQ where用户＝'用户2'；

用户	产品	状态	rowid
				用户2	优惠券A	已用	新值
用户2	优惠券C	已用	新值

I、应急库的表YHQ、GL删除用户2的相关数据，至此用户2的应急业务数据处理完毕，此时生产系统允许用户2办理业务；

J、应急库所有应急业务数据处理完毕，此时所有用户均可在生产系统办理业务，同步结束；

可选地，本发明通过ADG库存量业务数据和应急库新增业务数据的汇总、过滤，形成完整的业务数据，解决查询类业务查询结果不完整的问题。

可选地，所述方法还包括：

从所述业务请求报文中提取所述目标业务对应的用户基础信息和业务类型信息；

基于所述用户基础信息，从配置库中查询用户的用户归属区域，获取所述目标业务的业务流量；

基于所述目标业务的业务流量，从所述配置库中查询所述目标业务的业务流量切换信息，所述业务流量切换信息用于体现所述业务流量处于生产状态或应急状态或不可用状态；

基于所述业务流量切换信息，从应急库的ADG数据过滤表中查询所述用户基础信息，确认所述用户无待处理的应急业务数据。

可选地，业务流量指某区域的所有业务请求，单个用户的一次业务请求归属于某个业务流量。切换控制可以基于业务流量完成。

可选地，生产中心和应急中心之间为主备关系，生产中心正常运行的情况下，应急中心不承载业务，生产中心局部或全局停服的情况下，服务路由控制器将对应的业务流量切换到应急中心，由应急中心承载业务。

可选地，可以从所述业务请求报文中提取所述目标业务对应的用户基础信息和业务类型信息，比如用户号码、业务类型等信息；然后可以基于所述用户基础信息，从配置库中查询用户的用户归属区域，获取所述目标业务的业务流量；进一步可以基于所述目标业务的业务流量，从所述配置库中查询所述目标业务的业务流量切换信息，所述业务流量切换信息用于体现所述业务流量处于生产状态或应急状态或不可用状态；基于所述业务流量切换信息，从应急库的ADG数据过滤表中查询所述用户基础信息，确认所述用户无待处理的应急业务数据。

服务路由控制器的处理逻辑如下：

步骤1i：从请求报文中提取用户号码、业务类型等信息。

步骤2i：从配置库查询该用户的用户归属区域，从而获得本次请求的业务流量。

步骤3i：从配置库查询业务流量切换信息，从应急库的ADG数据过滤表查询该用户的信息，如果查询结果为空，认为该用户没有待处理的应急业务数据(或者没有办理过应急业务，或者应急业务数据已全部同步到生产库)。

可选地，在确认所述用户无待处理的应急业务数据之后，所述方法还包括:

若所述业务流量为生产状态，则确定将所述业务请求报文分发至所述目标业务对应的生产系统；若所述业务流量为应急状态，则在基于所述业务类型确定所述目标业务不在应急业务禁止名单的情况下，确定将目标业务的业务请求报文切换至应急系统；

若所述业务流量为不可用状态，则确定结束处理所述业务请求报文。

该业务流量为生产状态时，如该用户没有待处理的应急业务数据，业务请求分发到生产系统对应服务，否则，直接返回提示，结束处理；

该业务流量为应急状态时，根据业务类型判断本次业务是否在应急业务禁止名单，如不在应急业务禁止名单，业务请求分发到应急系统对应服务，否则，直接返回提示，结束处理；

该业务流量为不可用状态时，直接返回提示，结束处理。

可选地，所述方法还包括：

基于预设周期，更新所述业务流量的业务流量切换信息。

可选地，可以基于预设周期，定期更新业务流量的业务流量切换信息。

可选地，所述更新所述业务流量的业务流量切换信息，包括：

基于业务请求报文，访问配置库，获取生产系统的探测内容和应急系统的探测内容；

基于所述生产系统的探测内容和生产系统的系统指标，应急系统的探测内容和应急系统的系统指标，更新所述业务流量的业务流量切换信息。

可选地，可以在配置库中根据专家经验定义各类指标的异常阈值，生成切换规则。

可选地，指标值可能存在短时间的波动、异常，一般情况下切换规则需要综合多项指标的多个周期的值，以及多次探测的结果，才能够保证正确率。

可选地，图3是本发明提供的生产中心运行状态切换信息流程示意图，如图3所示，在更新所述业务流量的业务流量切换信息时，可以基于业务请求报文，访问配置库，获取生产系统的探测内容和应急系统的探测内容；然后基于所述生产系统的探测内容和生产系统的系统指标，应急系统的探测内容和应急系统的系统指标，更新所述业务流量的业务流量切换信息，具体包括如下步骤：

步骤1j：访问配置库，根据生产系统和应急系统的版本信息获取对应版本的探测内容，如接口请求报文、页面探测脚本等，定期探测生产服务和应急服务，记录探测结果。

其中，探测是多种业务的探测。一种业务探测成功且原来在应急业务禁止名单中，则将其从禁止名单中删除；探测失败且原来不在禁止名单，则将其加入禁止名单。

其中，探测需要直接访问生产和应急系统的接入层，而不是访问服务路由控制器，因为访问服务路由控制器，业务请求会根据业务流量切换信息一直往一个系统分发或者直接返回不分发，达不到探测效果。

步骤2j：定期获取生产系统和应急系统的系统指标，包含探测指标和系统指标。

探测指标是探测过程中的功能和性能指标，包含但不限于：失败次数、失败率、响应时长、超时次数等。

系统指标从生产系统监控平台或其他渠获取的各类软硬件和业务指标，包含但不限于：请求业务量、服务队列积压量、生产/应急中心相关主机的CPU/内存/磁盘占有率/IO、生产库/应急库的存储/连接数/热块/锁IO等。

步骤3j：根据预置的切换规则，判断生产系统和应急系统的可用性，将业务流量切换信息置为生产状态、应急状态、无可用等三种状态的一种。

步骤4j：休眠一个周期时间，重复上述步骤1j-3j。

本发明提供的一种应急切换装置，通过采用生产系统版本直接构建的应急系统接收异常生产中心对应的业务请求报文，执行对应的目标业务，实现在应急系统的全量业务支撑，避免开发和维护两套版本的巨大工作量。

下面对本发明提供的应急切换装置进行描述，下文描述的应急切换装置与上文描述的应急切换方法可相互对应参照。

图4是本发明提供的应急切换装置的结构示意图，如图4所示，该应急切换装置包括：切换模块410和处理模块420，其中：

切换模块410用于在生产系统中至少一个生产中心异常的情况下，将异常的生产中心对应的目标业务的业务请求报文切换至应急系统；

处理模块420用于所述应急系统基于所述业务请求报文处理所述目标业务；

其中，所述应急系统是基于所述生产系统版本直接构建而成。

可选地，应急切换装置可以在生产系统中至少一个生产中心异常的情况下，通过切换模块410将异常的生产中心对应的目标业务的业务请求报文切换至应急系统；然后通过处理模块420实现通过所述应急系统基于所述业务请求报文处理所述目标业务。

本发明提供的一种应急切换装置，通过采用生产系统版本直接构建的应急系统接收异常生产中心对应的业务请求报文，执行对应的目标业务，实现在应急系统的全量业务支撑，避免开发和维护两套版本的巨大工作量。

图5是本发明提供的电子设备的实体结构示意图，如图5所示，该电子设备可以包括：处理器(processor)510、通信接口(Communications Interface)520、存储器(memory)530和通信总线540，其中，处理器510，通信接口520，存储器530通过通信总线540完成相互间的通信。处理器510可以调用存储器530中的逻辑指令，以执行应急切换方法，该方法包括：

在至少一个生产中心异常的情况下，应急中心接收异常的生产中心对应的目标业务的业务请求报文；

基于所述业务请求报文执行所述目标业务，获得第一业务执行数据，其中，所述第一业务执行数据包括所述应急中心执行所述目标业务的记录；

其中，所述第一业务执行数据和第二业务执行数据相同，第二业务执行数据包括所述生产中心无异常时执行所述目标业务的记录。

此外，上述的存储器530中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述提供的应急切换方法，该方法包括：

在至少一个生产中心异常的情况下，应急中心接收异常的生产中心对应的目标业务的业务请求报文；

基于所述业务请求报文执行所述目标业务，获得第一业务执行数据，其中，所述第一业务执行数据包括所述应急中心执行所述目标业务的记录；

其中，所述第一业务执行数据和第二业务执行数据相同，第二业务执行数据包括所述生产中心无异常时执行所述目标业务的记录。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

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

Claims (10)

1.一种应急切换方法，其特征在于，包括：

在生产系统中至少一个生产中心异常的情况下，将异常的生产中心对应的目标业务的业务请求报文切换至应急系统；

所述应急系统基于所述业务请求报文处理所述目标业务；

其中，所述应急系统是基于所述生产系统版本直接构建而成。

2.根据权利要求1所述的应急切换方法，其特征在于，所述应急系统基于所述业务请求报文处理所述目标业务，包括：

所述应急系统基于所述业务请求报文处理所述目标业务，获取应急业务数据；

其中，所述应急系统中的所述应急业务数据的数据对象版本和所述生产系统中的数据对象版本相同。

3.根据权利要求2所述的应急切换方法，其特征在于，所述应急系统基于所述业务请求报文处理所述目标业务，获取应急业务数据，包括：

应急系统在基于所述业务请求报文处理所述目标业务的过程中产生的每个SQL都传入数据库访问控制器，以使数据库访问控制器对所述SQL进行数据处理获得处理结果；

应急系统获取所述处理结果，并基于所述处理结果完成所述目标业务的处理，在应急数据库中生成所述应急业务数据；

其中，所述应急数据库用于在切换至生产系统后将所述应急业务数据同步至生产数据库；

其中，所述生产数据库中包括所述生产系统中的生产业务数据。

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

从所述业务请求报文中提取所述目标业务对应的用户基础信息和业务类型信息；

基于所述用户基础信息，从配置库中查询用户的用户归属区域，获取所述目标业务的业务流量；

基于所述目标业务的业务流量，从所述配置库中查询所述目标业务的业务流量切换信息，所述业务流量切换信息用于体现所述业务流量处于生产状态或应急状态或不可用状态；

基于所述业务流量切换信息，从应急库的ADG数据过滤表中查询所述用户基础信息，确认所述用户无待处理的应急业务数据。

5.根据权利要求4所述的应急切换方法，其特征在于，在确认所述用户无待处理的应急业务数据之后，所述方法还包括:

若所述业务流量为生产状态，则确定将所述业务请求报文分发至所述目标业务对应的生产系统；若所述业务流量为应急状态，则在基于所述业务类型确定所述目标业务不在应急业务禁止名单的情况下，确定将目标业务的业务请求报文切换至应急系统；

若所述业务流量为不可用状态，则确定结束处理所述业务请求报文。

6.根据权利要求4所述的应急切换方法，其特征在于，所述方法还包括：

基于预设周期，更新所述业务流量的业务流量切换信息。

7.根据权利要求6所述的应急切换方法，其特征在于，所述更新所述业务流量的业务流量切换信息，包括：

基于业务请求报文，访问配置库，获取生产系统的探测内容和应急系统的探测内容；

基于所述生产系统的探测内容和生产系统的系统指标，应急系统的探测内容和应急系统的系统指标，更新所述业务流量的业务流量切换信息。

8.一种应急切换装置，其特征在于，包括：

切换模块，用于在生产系统中至少一个生产中心异常的情况下，将异常的生产中心对应的目标业务的业务请求报文切换至应急系统；

处理模块，用于所述应急系统基于所述业务请求报文处理所述目标业务；

其中，所述应急系统是基于所述生产系统版本直接构建而成。

9.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至7任一项所述应急切换方法的步骤。

10.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述应急切换方法的步骤。

Images