Emergency handover method and apparatus, electronic device, and storage medium

Abstract

The application provides an emergency switching method and device, electronic equipment and a storage medium. The method comprises the following steps: in the case that at least one production center in a production system is abnormal, switching a service request message of a target service corresponding to the abnormal production center to an emergency system; the emergency system processes the target service based on the service request message; wherein the emergency system is directly constructed based on a production system version. The emergency system directly constructed based on the production system version is adopted to receive the service request message corresponding to the abnormal production center, execute the corresponding target service, and realize full-amount service support in the emergency system, thereby avoiding huge workload of developing and maintaining two sets of versions.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an emergency switching method, apparatus, electronic device, and storage medium. Background Technology

[0002] Production systems are real-time systems that serve users. To ensure a good user experience, downtime should be minimized. In daily operations, various situations such as system upgrades, equipment failures, and network interruptions can cause production system downtime. Traditional support solutions include high availability, database disaster recovery failover, and emergency failover. Emergency failover can address downtime scenarios at both the application and database levels.

[0003] The existing emergency response system's services are divided into two categories: inquiry services and acceptance services.

[0004] Emergency query services only involve read operations, using disaster recovery databases such as Active DataGuard (ADG) libraries and Business Continuity Volumes (BCV) as data sources, and the processing logic is the same as that of the production system.

[0005] The processing logic for emergency response services differs from that of the production system. Production system processing handles all sub-processes of a service in real-time; emergency response system breaks down a service into core and non-core sub-processes. Core sub-processes are processed in real-time, while non-core sub-processes are not processed immediately, only their information is saved to an emergency database. After the production system recovers, the business information is reassembled into a message, and the write-back service is invoked to redo the service. During the redo process, already processed core sub-processes are filtered out to avoid duplication. Through real-time processing of core sub-processes and business redoing, the entire service is fully processed. Emergency response services involve read and write operations. Read operations use the disaster recovery database as the data source, while write operations use the emergency database.

[0006] Taking the recharge service as an example, the entire business process can be divided into four sub-processes: verification, account posting, system reactivation, and transaction record recording. Verification and system reactivation affect the user experience and are core sub-processes, while account posting and transaction record recording do not affect the user experience and are non-core sub-processes. The processing of this business in the production system, emergency system, and production system write-back service is shown in Table 1.

[0007] Table 1

[0008] System / Subprocess check Upload Restart Record business transaction history Production System deal with deal with deal with deal with Emergency system Real-time processing Keep only information Real-time processing Keep only information Write-back service No action taken deal with No action taken deal with

[0009] It is evident that existing emergency response systems are based on business processes and are strongly correlated with business operations. Each business must develop its own specific emergency response logic, resulting in a huge workload for development and maintenance. They are only suitable for supporting emergency response for a small number of businesses, and providing full-scale emergency support for all businesses is extremely difficult. Summary of the Invention

[0010] This invention provides an emergency switching method, device, electronic device, and storage medium to address the shortcomings of existing technologies in providing full-scale emergency support for services, thereby achieving full-scale service support in the emergency system and reducing the enormous workload of developing and maintaining two versions.

[0011] In a first aspect, the present invention provides an emergency switching method, comprising:

[0012] In the event that at least one production center in the production system is abnormal, the business request messages of the target business corresponding to the abnormal production center will be switched to the emergency system.

[0013] The emergency system processes the target service based on the service request message;

[0014] The emergency system is built directly from the production system version.

[0015] Optionally, according to the emergency handover method provided by the present invention, the emergency system processes the target service based on the service request message, including:

[0016] The emergency system processes the target service based on the service request message and obtains emergency service data.

[0017] The data object version of the emergency business data in the emergency system is the same as the data object version in the production system.

[0018] Optionally, according to the emergency switching method provided by the present invention, the emergency system processes the target service based on the service request message and obtains emergency service data, including:

[0019] Each SQL statement generated by the emergency system during the process of processing the target business based on the business request message is transmitted to the database access controller so that the database access controller can process the SQL to obtain the processing result.

[0020] The emergency system obtains the processing result and completes the processing of the target business based on the processing result, and generates the emergency business data in the emergency database;

[0021] The emergency database is used to synchronize the emergency business data to the production database after switching to the production system;

[0022] The production database includes production business data from the production system.

[0023] Optionally, according to the emergency switching method provided by the present invention, the method further includes:

[0024] Extract the user basic information and service type information corresponding to the target service from the service request message;

[0025] Based on the user's basic information, the user's home region is queried from the configuration library to obtain the service traffic of the target service;

[0026] Based on the service traffic of the target service, query the service traffic switching information of the target service from the configuration library. The service traffic switching information is used to indicate whether the service traffic is in production status, emergency status, or unavailable status.

[0027] Based on the service traffic switching information, the user's basic information is queried from the ADG data filtering table in the emergency database to confirm that the user has no pending emergency service data.

[0028] Optionally, according to the emergency handover method provided by the present invention, after confirming that the user has no pending emergency service data, the method further includes:

[0029] If the service traffic is in production status, then the service request message will be distributed to the production system corresponding to the target service; if the service traffic is in emergency status, then if the target service is not on the emergency service prohibition list based on the service type, then the service request message of the target service will be switched to the emergency system.

[0030] If the service traffic is unavailable, then the processing of the service request message will be terminated.

[0031] Optionally, according to the emergency switching method provided by the present invention, the method further includes:

[0032] The service traffic switching information of the service traffic is updated based on a preset period.

[0033] Optionally, according to the emergency switching method provided by the present invention, updating the service traffic switching information of the service traffic includes:

[0034] Based on the business request message, access the configuration library to obtain the detection content of the production system and the detection content of the emergency system;

[0035] Based on the detection content and system indicators of the production system, and the detection content and system indicators of the emergency system, update the business traffic switching information of the business traffic.

[0036] Secondly, the present invention provides an emergency switching device, comprising:

[0037] The switching module is used to switch the business request messages of the target business corresponding to the abnormal production center to the emergency system when at least one production center in the production system is abnormal.

[0038] The processing module is used by the emergency system to process the target service based on the service request message;

[0039] The emergency system is built directly from the production system version.

[0040] Thirdly, the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the emergency switching method as described in the first aspect.

[0041] Fourthly, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the emergency switching method as described in the first aspect.

[0042] The present invention provides an emergency switching method, device, electronic device and storage medium, which receives business request messages corresponding to the abnormal production center by directly building an emergency system using the production system version, and executes the corresponding target business, thereby achieving full business support in the emergency system and avoiding the huge workload of developing and maintaining two versions. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0044] Figure 1 This is a flowchart illustrating the emergency switching method provided by the present invention;

[0045] Figure 2 This is a schematic diagram of the business processing system provided by the present invention;

[0046] Figure 3 This is a schematic diagram of the production center operation status switching information flow provided by the present invention;

[0047] Figure 4 This is a schematic diagram of the emergency switching device provided by the present invention;

[0048] Figure 5 This is a schematic diagram of the physical structure of the electronic device provided by the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0050] Figure 1 This is a flowchart illustrating the emergency switching method provided by the present invention, as shown below. Figure 1 As shown, the method includes the following steps:

[0051] Step 100: In the event of an anomaly in at least one production center in the production system, the business request message of the target business corresponding to the anomaly production center is switched to the emergency system.

[0052] Step 110: The emergency system processes the target service based on the service request message;

[0053] The emergency system is built directly from the production system version.

[0054] Production systems are real-time systems that serve users. To ensure user satisfaction, downtime should be minimized to guarantee business continuity. In daily operations, various planned adjustments and unplanned emergencies, such as system upgrades, equipment failures, and network interruptions, may cause partial or complete downtime of the production system. High availability, data center switchover, database disaster recovery switchover, and emergency switchover solutions can be implemented to ensure uninterrupted user service.

[0055] High availability primarily addresses scenarios where individual applications or hosts in a production system are out of service. Centralized failover primarily addresses scenarios where all applications at a single central level are out of service. Database disaster recovery failover primarily addresses scenarios where production databases are out of service. Emergency failover can handle production application or production database outages of all levels. In terms of severity, high availability addresses lightweight scenarios, while other solutions address heavyweight scenarios. In terms of recovery time, database disaster recovery requires 30-60 minutes, while other solutions require less than 1 minute. Therefore, emergency failover has advantages such as wide applicability, short recovery time, and the ability to handle heavyweight scenarios, making it a core assurance solution.

[0056] Therefore, in the event of an anomaly in at least one production center in the production system, the present invention can switch the business request messages of the target business corresponding to the anomaly production center to the emergency system, and the emergency system processes the target business based on the business request messages, thus ensuring uninterrupted user service.

[0057] Figure 2 This is a schematic diagram of the business processing system provided by the present invention, such as... Figure 2 As shown, taking an emergency response system including an emergency center as an example, the business processing system can include multiple production centers and one emergency center, with the multiple production centers collectively forming the production system. It also includes a configuration repository, the main data stored in which the configuration repository and its functions are as follows:

[0058] (1) User's home region information: used to determine which center a user's business request needs to be distributed to; used to determine which database in the production system needs to be accessed for emergency business processing and emergency data synchronization.

[0059] Users can be represented in the data table in various ways, such as user number, user code (ID), etc., as long as they are globally unique. This scheme uniformly uses user number to represent them.

[0060] (2) Business traffic switching information: used to determine whether a business request needs to be distributed to the production system, the emergency system or returned directly; used to determine whether emergency business data should be automatically synchronized.

[0061] (3) Abnormal threshold and switching rules for detection indicators: used to determine the abnormal status of the system and business, and to automatically update the business traffic switching information accordingly.

[0062] (4) Version information and corresponding detection content: Based on the different version information of different systems, obtain the detection content of the corresponding version and complete the detection.

[0063] The emergency system needs to use a number of configuration data from the configuration library. From the perspective of convenience, data that is not frequently updated, such as user's home region information, version information and corresponding detection content, can be periodically synchronized from the configuration library to the emergency system, or even put into memory, to improve access efficiency.

[0064] Optionally, the business processing system may also include a service routing controller;

[0065] Optionally, the service routing controller extracts parameters such as user number and service type from the service request, and determines the subsequent routing process based on user home region information and service traffic switching information in the configuration library.

[0066] For multi-center systems, the key issue is which center a business request should be routed to. This routing can be implemented in the service routing controller or in the access layer; essentially, there's no difference. This solution assumes it's implemented in the access layer.

[0067] Optionally, the business processing system may also include a detection device;

[0068] Optionally, the detection device can periodically detect production services and emergency services based on the version information of the configuration library and the corresponding detection content (request messages, automated test scripts, or others). Based on the detection results, combined with the abnormal thresholds of the detection indicators and switching rules in the configuration library, the device can automatically update the business traffic switching information.

[0069] Optionally, the detection device can automatically verify version compatibility based on the version information of the configuration library and the corresponding detection content.

[0070] Optionally, the business processing system may also include a data access controller;

[0071] For application services, the data access controller is equivalent to the database.

[0072] Optionally, the data access controller can parse the incoming SQL, determine whether it is a read or write operation, and identify and access the relevant database based on the incoming user number and the user's region information in the configuration database. In a multi-datacenter scenario, there are multiple production system ADG databases. Read operations will inevitably require routed access; write operations depend on the number of emergency databases. If there is only one emergency database, direct access is possible, and transaction control uses ordinary transactions. Otherwise, routed access is required, and transaction control uses distributed transactions.

[0073] Optionally, the data access controller can transform the parsed SQL operation type and conditions to generate emergency business data that can be directly synchronized to the production database and saved to the emergency database.

[0074] Optionally, the business processing system also includes a synchronization distributor;

[0075] Optionally, the synchronization distributor can automatically synchronize emergency business data to the production database based on the configuration database user's home region information and business traffic switching information.

[0076] The existing emergency handling logic and production handling logic are the same business processes in different scenarios, ultimately producing the same production business data. The two are related, and the two application versions need to be upgraded synchronously to ensure compatibility. Compatibility assurance depends on version and development management. If the system itself does not provide a guarantee mechanism, the maintenance workload is large.

[0077] Therefore, in order to overcome the above-mentioned defects, the emergency system in this invention can be directly built based on the production system version, so as to achieve full business support and reduce the huge workload of developing and maintaining two versions.

[0078] Optionally, there are multiple versions of the production system, each of which can be divided into an application service version and a data object version. The application service version of the emergency system can be different from that of the production system. The data object selection of the emergency database in the emergency system is the same as that of the production system. Since the application service version and the data object version may be different, compatibility issues need to be considered. Therefore, further compatibility testing can be performed.

[0079] Optionally, the production system version includes application service versions and data object versions. The application service versions of the production system and the emergency system may differ, while the data object versions are the same. Within the production system, the application service version and data object version need to be consistent, while within the emergency system, they can be inconsistent. The emergency system deploys two sets of services and corresponding data objects: one for emergency business processing and one for detection. Other version details are shown in Table 2 below.

[0080] Table 2

[0081]

[0082] Optionally, the emergency system can directly deploy the application service version of the production system, choosing from the currently used version, a lower version, or a higher version. Considering stability and availability, a lower version is preferable because it has undergone extensive testing and verification within the production system. If multiple lower versions exist, the version with the closest release date to the currently used version should be selected, taking into account compatibility probability. If no suitable lower version is available, the currently used version of the production system can be chosen.

[0083] Optionally, different application versions may have different processing logic and steps, but as long as the final queried or generated business data is consistent, the application versions can be considered compatible.

[0084] Optionally, verification involves probing the production service and the detection service, comparing their detection results to determine compatibility. Since the emergency service and the detection service use the same application version, as long as the production service and the detection service are compatible, the production service and the emergency service are also compatible.

[0085] Optionally, version compatibility applies to business types, allowing for some businesses to be compatible and others to be incompatible. Incompatible businesses can be added to an emergency business prohibition list.

[0086] Alternatively, the compatibility detection mechanism can be implemented as follows:

[0087] Step 1a: You can delete all business data in the probe database and copy the probe user's business data from the production database to the probe database as baseline data.

[0088] Step 2a: It can detect users performing probing in the production system and obtain the probing business data Dc (production database); it can detect users performing probing in the emergency system (probing service) and obtain the probing business data Dt (probing database).

[0089] Incompatibility can be considered to occur if any of the following incompatibilities are present:

[0090] Case 1b: Probe failed. Common cases include API call failure, parameter mismatch, and inability to insert data into the database.

[0091] Scenario 2b: Dc and Dt are not completely consistent. Common situations include different numbers of records, different field values ​​for the corresponding records in Dc and Dt, etc.

[0092] Alternatively, detection can employ mature industry technologies such as automated testing tools, message simulation tools, and scripts, which will not be elaborated upon here.

[0093] Optionally, emergency service processing may involve different versions of various application services. For example, if the system's services are exposed to a third-party platform, and the third-party platform uses the VC version interface to call the service, but the system switches to emergency mode, the internal processing logic uses the Ve version. This situation does not affect the correctness of compatibility checks.

[0094] Alternatively, consistency between Dc and Dt can be achieved using code. A more convenient approach is to use Oracle's dblink to perform forward and reverse minus operations on the results of the production and probe databases.

[0095] Optionally, compatibility detection is a one-time event, performed after each upgrade of the production or emergency system. Detection of business traffic switching states is periodic.

[0096] Step 3a: If the versions are incompatible, the corresponding business type can be added to the emergency business prohibition list.

[0097] The data object version of the emergency system is consistent with that of the production system, which can ensure that information is not lost when emergency business data is saved to the emergency database, and allows for direct data comparison of detection results.

[0098] For purposes such as high concurrency, fault isolation, and decentralized management, the production system is divided into multiple production centers based on attributes such as region. Similarly, the emergency system can also be divided into multiple emergency centers. However, considering that the emergency system is used less frequently, only one emergency center can be built, which helps to save costs.

[0099] Based on a multi-center production architecture, this invention utilizes the production system version to build an emergency system. Through business detection and service routing control, it achieves automatic emergency switching after production business service interruption and automatic production rollback after production business recovery. During the emergency switching period, when handling business, emergency business data that can be directly synchronized with the production database is generated through parsing and transformation of business data. After the production rollback, the automatic synchronization of this data is completed, ensuring the integrity and consistency of global data.

[0100] The present invention provides an emergency switching method that receives business request messages corresponding to the abnormal production center by directly building an emergency system using the production system version, and executes the corresponding target business, thereby achieving full business support in the emergency system and avoiding the huge workload of developing and maintaining two versions.

[0101] Optionally, the emergency system processes the target service based on the service request message, including:

[0102] The emergency system processes the target service based on the service request message and obtains emergency service data.

[0103] The data object version of the emergency business data in the emergency system is the same as the data object version in the production system.

[0104] The existing emergency system business redo methods can be essentially divided into two parts: service invocation and emergency business data synchronization. Service invocation is the means of emergency business data synchronization, and both are completed after the switchback to production.

[0105] The existing emergency system uses a mechanism of caching and redoing business information. If a switchback to the production system is needed, all business information cached in the emergency system must be processed first; otherwise, production data will be incomplete, and the production system will be unusable. The longer the production system outage lasts, the more cached information there is after the emergency switchover, the longer the redo process takes, and the slower the production system recovery, severely impacting user experience.

[0106] Therefore, in order to overcome the above-mentioned defects, the present invention can directly call the services of all business processes without splitting the business sub-processes, extract the SQL of the service access database through the database access controller and parse it, and combine it with the processing and transformation of ADG inventory business data to generate the final business data in the emergency database that can be directly batch synchronized to the production database, thereby improving the synchronization efficiency.

[0107] Therefore, when the emergency system processes the target service based on the service request message, it can obtain emergency service data; wherein, if the data object version of the emergency service data in the emergency system is the same as the data object version in the production system, the emergency service data of the emergency center can be directly synchronized to the production database.

[0108] Optionally, the emergency system processes the target service based on the service request message to obtain emergency service data, including:

[0109] Each SQL statement generated by the emergency system during the process of processing the target business based on the business request message is transmitted to the database access controller so that the database access controller can process the SQL to obtain the processing result.

[0110] The emergency system obtains the processing result and completes the processing of the target business based on the processing result, and generates the emergency business data in the emergency database;

[0111] The emergency database is used to synchronize the emergency business data to the production database after switching to the production system;

[0112] The production database includes production business data from the production system.

[0113] Optionally, when switching back to the production system, the present invention supports the simultaneous synchronization of emergency data and the release of production services, eliminating the gap between switching between emergency and production in the existing solution, and realizing seamless switching between the production system and the emergency system.

[0114] Optionally, each production center can have a database in a master-slave configuration. The master database is the production database, providing read and write functionality, while the slave database is the ADG database, providing read-only functionality. Data can be synchronized from the master database to the ADG database in real time using Oracle ADG technology.

[0115] Optionally, each emergency center may have an emergency database for reading and writing business data during emergency switchover, with read operations simultaneously reusing the production center's ADG database.

[0116] Optionally, both query-type and processing-type services consist of several sub-processes. For a specific sub-process, database access may or may not be involved. The implementation of this invention does not need to consider the specific number of sub-processes or the business processing logic of each sub-process, but only needs to consider the SQL and data processing of the sub-processes involving database access.

[0117] The business processing flow includes the following steps:

[0118] Step 1c: The service routing controller parses the business request and distributes it to the emergency center if it meets the rules.

[0119] Step 2c: The emergency service of the emergency center initiates a transaction to the database access controller, and the database access controller initiates a transaction to the emergency database.

[0120] Step 3c: Every SQL statement generated by the emergency service during business processing is passed to the database access controller, which processes the SQL and data and returns the processing result to the emergency service. The emergency service then continues to process subsequent sub-processes based on the returned processing result.

[0121] Step 4c: After the emergency service has finished processing all sub-processes, or if it is abnormally terminated during the process, it notifies the database access controller to end the transaction (commit or rollback). The database access controller then commits or rolls back the transaction in the emergency database according to the notification.

[0122] The SQL statements are divided into operation types such as query (select), insert (insert), update (update), and delete (delete). The processing method for each operation type can be different. The overall processing logic can include: query SQL, which retrieves data from the ADG database and the emergency database, filters out invalid data, and returns the query results to the emergency service; insert / update / delete SQL, which parses and transforms the SQL, queries and filters relevant data from the ADG database and the emergency database, generates final business data that can be directly synchronized to the production database, and saves it to the emergency database. At the same time, information such as user number, business data table, ADG related rowid, SQL operation type, and processing time are recorded in the "ADG data filtering table". This table is used for filtering invalid data in ADG and for data synchronization processing after switching back to production.

[0123] Optionally, since there are multiple ADG databases, the specific ADG database can be determined based on the user's number's regional information before accessing the ADG database.

[0124] Among them, rowid is a built-in field of the data table in Oracle database, which has global uniqueness at the database level.

[0125] Optionally, the specific processing methods for various SQL operation types are as follows:

[0126] (1) Query (select);

[0127] Step 1d: Parse the original SQL to obtain information such as user number and business data table, and query the ADG data filter table for the rowid that needs to be filtered based on this information.

[0128] Step 2d: If the filtered rowid can be found, add the rowid filter condition to the WHERE clause of the original SQL and query the data in the ADG database; if it cannot be found, execute the original SQL in the ADG database.

[0129] Step 3d: Use raw SQL to query data from the emergency database.

[0130] Step 4d: Merge the query data from the ADG library and the emergency library to obtain the final dataset, and return it to the emergency service.

[0131] (2) Insert;

[0132] Step 1e: The original SQL is executed directly in the emergency database.

[0133] Step 2e: Record information such as user number, business data table, and rowid into the ADG data filter table. Among them, rowid should be filled with a null value, indicating that there is no such data record in the production system.

[0134] (3) Modify (update);

[0135] Step 1f: Parse the original SQL to obtain information such as user number and business data table, and query the ADG data filtering table to find the rowid that needs to be filtered.

[0136] Step 2f: Convert the original SQL into a select statement, add a rowid field to the field list, and use the original SQL's WHERE clause; if the filtered rowid can be found, add a rowid filter condition; execute the converted select statement in the ADG database to query the data.

[0137] Step 3f: Insert the query results into the emergency database.

[0138] Step 4f: Execute the original SQL in the emergency database.

[0139] Step 5f: Record information such as user number, business data table, and rowid into the ADG data filter table, where rowid is obtained from the query in step 2f.

[0140] (4) Delete;

[0141] Step 1g: Parse the original SQL to obtain information such as user number and business data table, and query the ADG data filtering table to find the rowid that needs to be filtered based on this information.

[0142] Step 2g: Convert the original SQL into a select statement, add a rowid field to the field list, and use the original SQL's WHERE clause; if the filtered rowid can be found, add a rowid filter condition; execute the converted select statement in the ADG database to query the data.

[0143] Step 3g: Record information such as user number, business data table, and rowid into the ADG data filter table, where rowid is obtained from the query in step 2g.

[0144] (5) Compound statements;

[0145] All operation-type statements may contain a select clause, such as:

[0146] insert into table_name(field_list)select field_list from table_name;

[0147] At this point, starting from the innermost select clause, the processes proceed sequentially from the inside out, following the AD processing principles outlined above.

[0148] Optionally, the emergency center can periodically read the service traffic switching information from the configuration database. Upon detecting that the service traffic has returned to production status, it will synchronize the service data from the emergency database to the production database. The specific processing steps are as follows:

[0149] Step 1h: Pause the detection of business traffic switching status.

[0150] Step 2h: Read the ADG data filter table from the emergency database and retrieve the first user number.

[0151] Step 3h: Based on the user number, query the ADG data filter table in the emergency database to find the business data table involved in the user's emergency business and the rowid of the business data table in the production database.

[0152] Step 4h: Query the user's region information based on the user number, confirm the specific production database to be synchronized, and delete the corresponding business data in the corresponding production database based on the business table name and rowid.

[0153] Step 5h: Based on the user number and business table name, query the corresponding business data in the emergency database and directly insert the queried business data into the production database.

[0154] Step 6h: Back up and delete all records for this user in the ADG data filter table of the emergency database. At this point, the user is allowed to conduct business in the production system.

[0155] Step 7h: Repeat steps 2h-6h until all users have been processed. At this point, all users can conduct business in the production system, and the synchronization process ends.

[0156] Step 8h: Detection of business traffic switching status.

[0157] Taking user 1 and user 2 as examples, corresponding to coupon A and coupon B respectively, the processing method of a single SQL statement is described exemplarily.

[0158] The business scenario and rules are as follows: Users have coupons, which they can use themselves or give to other users. Coupons have an expiration date, and expired coupons are deleted. Coupon information is stored in the business table "YHQ". Assuming user 1 and user 2 each currently have one coupon, the initial data is as follows:

[0159] Production database and ADG database: 2 records;

[0160] user product state rowid User 1 Coupon A Unused 1111 User 2 Coupon B Unused 2222

[0161] Emergency database: 0 records, table structure is the same as the production database (rowid of data records in the emergency database does not need to be controlled, so it is not listed);

[0162] user product state No record

[0163] The ADG data filtering table "GL" in the emergency database contains 0 records. The table structure is as follows:

[0164] user Business table Generate rowid No record

[0165] A series of operations can be simulated, assuming these operations are processed in the production system and the emergency system respectively (the premise of the emergency system is that the production system is shut down and the ADG library retains the original static data). By comparing the results of the two processes in the final business data, it can be seen that the results are consistent.

[0166] Operation 1: User 1 checks available coupons;

[0167] Original SQL: select * from YHQ where user = 'user1' and status = 'not used';

[0168] In the production system: a query of the production database yielded the following results:

[0169] user product state rowid User 1 Coupon A Unused 1111

[0170] In the emergency system: Querying table GL yielded no data. The original SQL was executed directly in the ADG database, and the results are shown in the table below:

[0171] user product state rowid User 1 Coupon A Unused 1111

[0172] Therefore, the production system and the emergency system produce the same result;

[0173] The current full data in the emergency database is as follows:

[0174] Table YHQ (No records):

[0175] user product state No record

[0176] Table GL (No records):

[0177] user Business table Generate rowid No record

[0178] Operation 2: User 1 gives coupon A to User 2;

[0179] Original SQL: update YHQ set user='user2'where user='user1'and product='coupon A';

[0180] In the production system:

[0181] user product state rowid User 2 Coupon A Unused 1111

[0182] In the emergency system: querying table GL, SQL: select * from GL where user = 'user1' and business table = 'YHQ', no records were found;

[0183] user Business table Generate rowid No record

[0184] The original SQL was converted into the following query SQL: `select *,rowid from YHQ where user = 'user1' and product = 'coupon A'`. This was executed in the ADG database, and the results are shown in the table below.

[0185] user product state rowid User 1 Coupon A Unused 1111

[0186] The result was inserted into the emergency database, and the results are shown in the table below:

[0187] user product state User 1 Coupon A Unused

[0188] The emergency database executes the original SQL, and the results are shown in the table below:

[0189] user product state User 2 Coupon A Unused

[0190] Record table GL, the results are shown in the following table:

[0191] user Business table Generate rowid User 1 YHQ 1111

[0192] Therefore, the production system and the emergency system have the same processing results;

[0193] The current emergency database contains different data compared to the emergency database obtained in Operation 1, specifically:

[0194] Table YHQ:

[0195] user product state User 2 Coupon A Unused

[0196] Table GL:

[0197] user Business table Generate rowid User 1 YHQ 1111

[0198] Operation 3: User 1 checks available coupons again;

[0199] Original SQL: select * from YHQ where user = 'user1' and status = 'not used';

[0200] In the production system: a query of the production database yielded the following results:

[0201] user product state rowid No record

[0202] In the emergency system: Query table GL, SQL: select * from GL where user = 'user1' and business table = 'YHQ', the query results are shown in the table below (the rowid to be filtered is 1111):

[0203] user Business table Generate rowid User 1 YHQ 1111

[0204] The original SQL was transformed into a query SQL with added filtering conditions: `select * from YHQ where user = 'user1' and status = 'not used' and rowid not in (1111)`. When executed in the ADG database, no records were found, as shown in the table below:

[0205] user product state No record

[0206] The emergency database executes raw SQL, but no records are found, as shown in the following table:

[0207] user product state No record

[0208] The execution results of merging the ADG library and the emergency library, i.e., the final result, are shown in the table below:

[0209] user product state No record

[0210] Therefore, the production system and the emergency system produce the same result;

[0211] The full data in the emergency database is unchanged compared to the emergency database obtained in Operation 2, specifically:

[0212] Table YHQ:

[0213] user product state User 2 Coupon A Unused

[0214] Table GL:

[0215] user Business table Generate rowid User 1 YHQ 1111

[0216] Operation 4: User 2 checks available coupons;

[0217] Original SQL: select * from YHQ where user = 'user2' and status = 'not used';

[0218] In the production system:

[0219] user product state rowid User 2 Coupon A Unused 1111 User 2 Coupon B Unused 2222

[0220] In the emergency system: Querying table GL, SQL: select * from GL where user = 'user2' and business table = 'YHQ', no records were found, as shown in the table below:

[0221] user Business table Generate rowid No record

[0222] The original SQL was executed directly in the ADG database, and the results are shown in the table below:

[0223] user product state User 2 Coupon B Unused

[0224] The original SQL was executed directly in the emergency database, and the results are shown in the table below:

[0225] user product state User 2 Coupon A Unused

[0226] The execution results of merging the ADG library and the emergency library, i.e., the final result, are shown in the table below:

[0227] user product state User 2 Coupon A Unused User 2 Coupon B Unused

[0228] Therefore, the production system and the emergency system produce the same result;

[0229] The emergency database currently shows no change in its full data volume compared to Operation 3, specifically:

[0230] Table YHQ:

[0231] user product state User 2 Coupon A Unused

[0232] Table GL:

[0233] user Business table Generate rowid User 1 YHQ 1111

[0234] Operation 5: The system gives user 2 a coupon (coupon name: Coupon C).

[0235] Original SQL: insert into YHQ values('User2','Coupon C','Unused')

[0236] In the production system:

[0237] user product state rowid User 2 Coupon C Unused 3333

[0238] In the emergency system: the original SQL is executed directly in the emergency database, and the results are shown in the table below:

[0239] user product state User 2 Coupon C Unused

[0240] The record table GL has the following results (because there is no record for coupon C in the original production system records, the production rowid is empty):

[0241] user Business table Generate rowid User 2 YHQ null

[0242] Therefore, the production system and the emergency system produce the same result;

[0243] The emergency database currently contains data that has changed compared to Operation 4, specifically as follows:

[0244] Table YHQ:

[0245] user product state User 2 Coupon A Unused User 2 Coupon C Unused

[0246] Table GL:

[0247] user Business table Generate rowid User 1 YHQ 1111 User 2 YHQ null

[0248] Operation 6: User 2 uses coupon A;

[0249] Original SQL: update YHQ set status = 'used' where user = 'user2' and product = 'coupon A';

[0250] In the production system:

[0251] user product state rowid User 2 Coupon A Used 1111

[0252] In the emergency system: Querying table GL, SQL: select * from GL where user = 'user2' and business table = 'YHQ', no records were found, as shown in the table below:

[0253] user Business table Generate rowid No record

[0254] The original SQL was converted into the following query SQL: `select *,rowid from YHQ where user = 'user2' and product = 'coupon A'`. When executed in the ADG database, no records were found, as shown in the table below:

[0255] user product state No record

[0256] The result was inserted into the emergency database, and the results are shown in the table below (no records were found in the ADG database, so the insertion operation was a null operation):

[0257] user product state No record

[0258] The emergency database executes the original SQL, and the results are shown in the table below:

[0259] user product state User 2 Coupon A Used

[0260] The record filtering table shows the results as follows (no records were found in the ADG database, so the insert operation was a null operation):

[0261] user Business table Generate rowid No record

[0262] The production system and the emergency system produced the same results.

[0263] The emergency database currently contains data that has changed compared to Operation 5, specifically as follows:

[0264] Table YHQ:

[0265] user product state User 2 Coupon A Used User 2 Coupon C Unused

[0266] Table GL:

[0267] user Business table Generate rowid User 1 YHQ 1111 User 2 YHQ null

[0268] Operation 7: User 2's coupon B has expired;

[0269] Original SQL: delete from YHQ where user = 'user2' and product = 'coupon B';

[0270] In the production system: Deletion successful. Using SQL: select * from YHQ where user = 'user2' and product = 'coupon B', no records were found, as shown in the table below:

[0271] user product state rowid No record

[0272] In the emergency system: Query table GL, SQL: select * from GL where user = 'user2' and business table = 'YHQ', the results are as follows (no filtering is needed for rows with null rowids):

[0273] user Business table Generate rowid User 2 YHQ null

[0274] The original SQL was converted into the following query SQL: `select *,rowid from YHQ where user = 'user2' and product = 'coupon B'`. This was executed in the ADG database, and the results are shown in the table below.

[0275] user product state User 2 Coupon B Unused

[0276] Record table GL, the results are shown in the following table:

[0277] user Business table Generate rowid User 2 YHQ 2222

[0278] The production system and the emergency system produced the same results.

[0279] The emergency database currently contains data that has changed compared to Operation 6, specifically as follows:

[0280] Table YHQ:

[0281] user product state User 2 Coupon A Used User 2 Coupon C Unused

[0282] Table GL:

[0283]

[0284]

[0285] Operation 8: User 2 checks available coupons and finds 1 (coupon C);

[0286] Original SQL: select * from YHQ where user = 'user2' and status = 'not used';

[0287] In the production system:

[0288] user product state rowid User 2 Coupon C Unused 3333

[0289] In the emergency system: Query table GL, SQL: select * from GL where user = 'user2' and business table = 'YHQ', execute in the ADG database, the result is shown in the table below (no filtering is needed for rows with null rowids):

[0290] user Business table Generate rowid User 2 YHQ null User 2 YHQ 2222

[0291] The original SQL statement, with added filtering conditions: `select * from YHQ where user = 'user2' and status = 'not used' and rowid not in (2222)`, returns no records when executed in the ADG database, as shown in the table below:

[0292] user product state No record

[0293] The original SQL was executed directly in the emergency database, and the results are shown in the table below:

[0294] user product state User 2 Coupon C Unused

[0295] The execution results of merging the ADG library and the emergency library, i.e., the final result, are shown in the table below:

[0296] user product state User 2 Coupon C Unused

[0297] The production system and the emergency system produced the same results.

[0298] The emergency database currently shows no change in its full data volume compared to Operation 7, specifically:

[0299] Table YHQ:

[0300] user product state User 2 Coupon A Used User 2 Coupon C Unused

[0301] Table GL:

[0302] user Business table Generate rowid User 1 YHQ 1111 User 2 YHQ null User 2 YHQ 2222

[0303] Operation 9: User 2 uses coupon C;

[0304] Original SQL: update YHQ set status = 'used' where user = 'user2' and product = 'coupon C';

[0305] In the production system:

[0306] user product state rowid User 2 Coupon C Used 3333

[0307] In the emergency system: Query table GL, SQL: select * from GL where user = 'user2' and business table = 'YHQ', the results are shown in the table below (no filtering is needed for rows with null rowids):

[0308] user Business table Generate rowid User 2 YHQ null User 2 YHQ 2222

[0309] The original SQL was transformed into a query SQL with added filtering conditions: `select *,rowid from YHQ where user = 'user2' and product = 'coupon C' and rowid not in (2222)`. When executed in the ADG database, no records were found, as shown in the table below:

[0310] user product state No record

[0311] The result was inserted into the emergency database, and the results are shown in the table below (no records were found in the ADG database, so the insertion operation was a null operation):

[0312] user product state No record

[0313] The emergency database executes the original SQL, and the results are shown in the table below:

[0314] user product state User 2 Coupon C Used

[0315] The record filtering table shows the results as follows (no records were found in the ADG database, so the insert operation was a null operation):

[0316] user Business table Generate rowid No record

[0317] The production system and the emergency system produced the same results.

[0318] The emergency database currently shows no change in its full data volume compared to Operation 8, specifically:

[0319] Table YHQ:

[0320] user product state User 2 Coupon A Used User 2 Coupon C Used

[0321] Table GL:

[0322] user Business table Generate rowid User 1 YHQ 1111 User 2 YHQ null User 2 YHQ 2222

[0323] Operation 10: User 2 checks available coupons, but no records are found;

[0324] Original SQL: select * from YHQ where user = 'user2' and status = 'not used';

[0325] In the production system:

[0326] user product state rowid No record 3333

[0327] In the emergency system: Query table GL, SQL: select * from GL where user = 'user2' and business table = 'YHQ', execute in the ADG database, the result is shown in the table below (no filtering is needed for rows with null rowids):

[0328] user Business table Generate rowid User 2 YHQ null User 2 YHQ 2222

[0329] The original SQL statement, with added filtering conditions: `select * from YHQ where user = 'user2' and status = 'not used' and rowid not in (2222)`, returns no records when executed in the ADG database, as shown in the table below:

[0330] user product state No record

[0331] The original SQL was executed directly in the emergency database, but no records were found, as shown in the table below:

[0332] user product state No record

[0333] The execution results of merging the ADG library and the emergency library, i.e., the final result, are shown in the table below:

[0334] user product state No record

[0335] The production system and the emergency system produced the same results.

[0336] The emergency database currently shows no change in its full data volume compared to Operation 9, as detailed in the table below: Table YHQ:

[0337] user product state User 2 Coupon A Used User 2 Coupon C Used

[0338] Table GL:

[0339] user Business table Generate rowid User 1 YHQ 1111 User 2 YHQ null User 2 YHQ 2222

[0340] After the operation is completed, a data synchronization scenario can be simulated.

[0341] 1) Assume all processing is completed within the production system;

[0342] The final business data of the production system is shown in the table below:

[0343] user product state rowid User 2 Coupon A Used 1111 User 2 Coupon C Used 3333

[0344] 2) Assume all processing is completed within the emergency system;

[0345] The raw data for the production system and ADG are shown in the table below:

[0346] user product state rowid User 1 Coupon A Unused 1111 User 2 Coupon B Unused 2222

[0347] The emergency system data is as follows:

[0348] Table YHQ:

[0349] user product state User 2 Coupon A Used User 2 Coupon C Used

[0350] Table GL:

[0351] user Business table Generate rowid User 1 YHQ 1111 User 2 YHQ null User 2 YHQ 2222

[0352] Synchronization is handled as follows:

[0353] A. Read table GL and obtain the first user "User1";

[0354] B. Based on "User 1", query the ADG data filtering record in table GL;

[0355] SQL: select user, business table, production rowid from GL where user = 'user1', the result is shown in the table below:

[0356] user Business table Generate rowid User 1 YHQ 1111

[0357] C. Delete the record with the corresponding rowid from the data table YHQ in the production database;

[0358] SQL: delete from YHQ where rowid in(1111), executed in the production database. The full data in the production database is shown in the table below (all records for user 1 are deleted):

[0359] user product state rowid User 2 Coupon B Unused 2222

[0360] D. User 1's data in the emergency database is directly inserted into the production database. After execution in the production database, the full data in the production database is as follows:

[0361] SQL: insert into YHQ@production_database_dblink_name select *from YHQ where_user='user1' (assuming dblink synchronization is used, synchronization can also be done via application or other methods);

[0362] user product state rowid User 2 Coupon B Unused 2222

[0363] Among them, User 1 has no data in the emergency database and the synchronous production database is empty.

[0364] E. Delete the relevant data of user 1 from the emergency database tables YHQ and GL. At this point, the emergency business data of user 1 has been processed and the production system allows user 1 to conduct business.

[0365] F. Continue processing User 2's emergency business data. First, based on "User 2", query the ADG data filtering record in table GL.

[0366] SQL: select user, business table, production rowid from GL where user = 'user2', the result is shown in the table below:

[0367] user Business table Generate rowid User 2 YHQ null User 2 YHQ 2222

[0368] G. Delete the record with the corresponding rowid from the data table YHQ in the production database;

[0369] SQL: delete from YHQ where rowid in(2222), executed in the production database. The full data in the production database is shown in the table below (all records for user 2 are deleted):

[0370] user product state rowid No record

[0371] H. User 1's data in the emergency database is directly inserted into the production database. After execution in the production database, the full data in the production database is shown in the following table (note that a new value will be generated for rowid):

[0372] SQL: insert into YHQ@production_database_dblink_name select *from YHQ where_user='user2';

[0373] user product state rowid User 2 Coupon A Used New value User 2 Coupon C Used New value

[0374] I. Delete the relevant data of user 2 from the emergency database tables YHQ and GL. At this point, the emergency business data of user 2 has been processed, and the production system allows user 2 to conduct business.

[0375] J. Once all emergency business data in the emergency database has been processed, all users can now conduct business in the production system, and the process ends synchronously.

[0376] Optionally, this invention summarizes and filters ADG inventory business data and emergency database new business data to form complete business data, thus solving the problem of incomplete query results for query-type business.

[0377] Optionally, the method further includes:

[0378] Extract the user basic information and service type information corresponding to the target service from the service request message;

[0379] Based on the user's basic information, the user's home region is queried from the configuration library to obtain the service traffic of the target service;

[0380] Based on the service traffic of the target service, query the service traffic switching information of the target service from the configuration library. The service traffic switching information is used to indicate whether the service traffic is in production status, emergency status, or unavailable status.

[0381] Based on the service traffic switching information, the user's basic information is queried from the ADG data filtering table in the emergency database to confirm that the user has no pending emergency service data.

[0382] Optionally, service traffic refers to all service requests in a certain region, and a single user's service request belongs to a specific service traffic. Switching control can be performed based on service traffic.

[0383] Optionally, the production center and the emergency center are in a primary / backup relationship. When the production center is operating normally, the emergency center does not carry any business. In the event of a partial or global outage of the production center, the service routing controller will switch the corresponding business traffic to the emergency center, which will then carry the business.

[0384] Optionally, user basic information and service type information corresponding to the target service, such as user number and service type, can be extracted from the service request message. Then, based on the user basic information, the user's user home region can be queried from the configuration library to obtain the service traffic of the target service. Further, based on the service traffic of the target service, the service traffic switching information of the target service can be queried from the configuration library. The service traffic switching information is used to indicate whether the service traffic is in production, emergency, or unavailable status. Based on the service traffic switching information, the user basic information can be queried from the ADG data filtering table in the emergency database to confirm that the user has no pending emergency service data.

[0385] The service routing controller's processing logic is as follows:

[0386] Step 1i: Extract information such as user number and service type from the request message.

[0387] Step 2i: Query the user's home region from the configuration library to obtain the business traffic for this request.

[0388] Step 3i: Query the business traffic switching information from the configuration database and query the user's information from the ADG data filter table in the emergency database. If the query result is empty, it is assumed that the user has no pending emergency business data (or has not handled any emergency business, or the emergency business data has been fully synchronized to the production database).

[0389] Optionally, after confirming that the user has no pending emergency service data, the method further includes:

[0390] If the service traffic is in production status, then the service request message will be distributed to the production system corresponding to the target service; if the service traffic is in emergency status, then if the target service is not on the emergency service prohibition list based on the service type, then the service request message of the target service will be switched to the emergency system.

[0391] If the service traffic is unavailable, then the processing of the service request message will be terminated.

[0392] When the business traffic is in production status, if the user does not have any pending emergency business data, the business request will be distributed to the corresponding service in the production system; otherwise, a prompt will be returned directly and the processing will end.

[0393] When the traffic is in an emergency state, determine whether the current business is on the emergency business prohibition list based on the business type. If it is not on the emergency business prohibition list, the business request is distributed to the corresponding service of the emergency system; otherwise, return a prompt directly and end the processing.

[0394] When the service traffic is unavailable, return a prompt directly and end the process.

[0395] Optionally, the method further includes:

[0396] The service traffic switching information of the service traffic is updated based on a preset period.

[0397] Optionally, the business traffic switching information can be updated periodically based on a preset period.

[0398] Optionally, updating the service traffic switching information includes:

[0399] Based on the business request message, access the configuration library to obtain the detection content of the production system and the detection content of the emergency system;

[0400] Based on the detection content and system indicators of the production system, and the detection content and system indicators of the emergency system, update the business traffic switching information of the business traffic.

[0401] Optionally, abnormal thresholds for various indicators can be defined in the configuration library based on expert experience to generate switching rules.

[0402] Optionally, indicator values ​​may fluctuate or become abnormal in the short term. Generally, the switching rules need to take into account the values ​​of multiple indicators over multiple periods, as well as the results of multiple probes, in order to ensure accuracy.

[0403] Optionally, Figure 3 This is a schematic diagram of the production center operation status switching information flow provided by the present invention, such as... Figure 3 As shown, when updating the service traffic switching information of the service traffic, the configuration library can be accessed based on the service request message to obtain the detection content of the production system and the detection content of the emergency system; then, based on the detection content and system indicators of the production system, and the detection content and system indicators of the emergency system, the service traffic switching information of the service traffic is updated, specifically including the following steps:

[0404] Step 1j: Access the configuration library and obtain the corresponding detection content based on the version information of the production system and the emergency system, such as interface request messages, page detection scripts, etc., and periodically detect production services and emergency services, and record the detection results.

[0405] The detection process involves multiple services. If a service is successfully detected and was previously on the emergency service ban list, it will be removed from the ban list; if the detection fails and the service was not previously on the ban list, it will be added to the ban list.

[0406] The detection process requires direct access to the access layer of production and emergency systems, rather than accessing the service routing controller. Accessing the service routing controller would cause business requests to be continuously distributed to a single system based on business traffic switching information, or to be returned without being distributed at all, thus failing to achieve the desired detection effect.

[0407] Step 2j: Periodically obtain system indicators for the production system and emergency system, including detection indicators and system indicators.

[0408] Detection metrics are functional and performance indicators during the detection process, including but not limited to: number of failures, failure rate, response time, number of timeouts, etc.

[0409] System metrics are various software, hardware, and business metrics obtained from the production system monitoring platform or other channels, including but not limited to: request volume, service queue backlog, CPU / memory / disk occupancy / IO of relevant hosts in the production / emergency center, storage / connection count / hot block / lock IO of the production / emergency database, etc.

[0410] Step 3j: Based on the preset switching rules, determine the availability of the production system and the emergency system, and set the business traffic switching information to one of three states: production status, emergency status, or unavailable.

[0411] Step 4j: Sleep for one cycle and repeat steps 1j-3j above.

[0412] The present invention provides an emergency switching device that receives business request messages corresponding to the abnormal production center by directly building an emergency system using the production system version, and executes the corresponding target business, thereby achieving full business support in the emergency system and avoiding the huge workload of developing and maintaining two versions.

[0413] The emergency switching device provided by the present invention is described below. The emergency switching device described below and the emergency switching method described above can be referred to in correspondence.

[0414] Figure 4 This is a schematic diagram of the emergency switching device provided by the present invention, as shown below. Figure 4 As shown, the emergency switching device includes: a switching module 410 and a processing module 420, wherein:

[0415] The switching module 410 is used to switch the business request message of the target business corresponding to the abnormal production center to the emergency system when at least one production center in the production system is abnormal.

[0416] Processing module 420 is used by the emergency system to process the target service based on the service request message;

[0417] The emergency system is built directly from the production system version.

[0418] Optionally, the emergency switching device can, in the event of an anomaly at at least one production center in the production system, switch the service request message of the target service corresponding to the abnormal production center to the emergency system via the switching module 410; then, the processing module 420 can process the target service based on the service request message through the emergency system.

[0419] The present invention provides an emergency switching device that receives business request messages corresponding to the abnormal production center by directly building an emergency system using the production system version, and executes the corresponding target business, thereby achieving full business support in the emergency system and avoiding the huge workload of developing and maintaining two versions.

[0420] Figure 5 This is a schematic diagram of the physical structure of the electronic device provided by the present invention, such as... Figure 5 As shown, the electronic device may include: a processor 510, a communications interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communications interface 520, and the memory 530 communicate with each other via the communication bus 540. The processor 510 can call logical instructions in the memory 530 to execute an emergency switching method, which includes:

[0421] In the event of an anomaly at at least one production center, the emergency center receives the business request message for the target business corresponding to the anomaly production center.

[0422] The target service is executed based on the service request message to obtain first service execution data, wherein the first service execution data includes records of the emergency center executing the target service;

[0423] The first business execution data and the second business execution data are the same, and the second business execution data includes records of the execution of the target business when the production center has no abnormalities.

[0424] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0425] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the emergency switching method provided above, the method comprising:

[0426] In the event of an anomaly at at least one production center, the emergency center receives the business request message for the target business corresponding to the anomaly production center.

[0427] The target service is executed based on the service request message to obtain first service execution data, wherein the first service execution data includes records of the emergency center executing the target service;

[0428] The first business execution data and the second business execution data are the same, and the second business execution data includes records of the execution of the target business when the production center has no abnormalities.

[0429] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0430] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0431] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for emergency handover, the method comprising: include: In the event that at least one production center in the production system is abnormal, the business request messages of the target business corresponding to the abnormal production center will be switched to the emergency system. The emergency system processes the target service based on the service request message; The emergency system is built directly from the production system version. The method further includes: Extract the user basic information and service type information corresponding to the target service from the service request message; Based on the user's basic information, the user's home region is queried from the configuration library to obtain the service traffic of the target service; Based on the service traffic of the target service, the service traffic switching information of the target service is queried from the configuration library. The service traffic switching information is used to indicate whether the service traffic is in production, emergency, or unavailable status. The service traffic switching information is automatically updated based on the detection results of production and emergency services, combined with the abnormal threshold of detection indicators and switching rules in the configuration library. Based on the service traffic switching information, the user's basic information is queried from the ADG data filtering table in the emergency database to confirm that the user has no pending emergency service data. The ADG data filtering table is used to record user numbers, business data tables, database row identifiers, and SQL operation type information generated during the processing of the target business by the emergency system.

2. The method of emergency handover according to claim 1, wherein, The emergency system processes the target service based on the service request message, including: The emergency system processes the target service based on the service request message and obtains emergency service data. The data object version of the emergency business data in the emergency system is the same as the data object version in the production system.

3. The emergency switching method according to claim 2, characterized in that, The emergency system processes the target service based on the service request message and obtains emergency service data, including: Each SQL statement generated by the emergency system during the process of processing the target business based on the business request message is transmitted to the database access controller so that the database access controller can process the SQL to obtain the processing result. The emergency system obtains the processing result and completes the processing of the target business based on the processing result, and generates the emergency business data in the emergency database; The emergency database is used to synchronize the emergency business data to the production database after switching to the production system; The production database includes production business data from the production system.

4. The emergency switching method according to claim 1, characterized in that, After confirming that the user has no pending emergency service data, the method further includes: If the service traffic is in production status, then the service request message will be distributed to the production system corresponding to the target service; if the service traffic is in emergency status, then if the target service is not on the emergency service prohibition list based on the service type, then the service request message of the target service will be switched to the emergency system. If the service traffic is unavailable, then the processing of the service request message will be terminated.

5. The emergency switching method according to claim 1, characterized in that, The method further includes: The service traffic switching information of the service traffic is updated based on a preset period.

6. The emergency switching method according to claim 5, characterized in that, The updated service traffic switching information includes: Based on the business request message, access the configuration library to obtain the detection content of the production system and the detection content of the emergency system; Based on the detection content and system indicators of the production system, and the detection content and system indicators of the emergency system, update the business traffic switching information of the business traffic.

7. An emergency switching device, characterized in that, include: The switching module is used to switch the business request messages of the target business corresponding to the abnormal production center to the emergency system when at least one production center in the production system is abnormal. The processing module is used by the emergency system to process the target service based on the service request message; The emergency system is built directly from the production system version. The processing module is further configured to: Extract the user basic information and service type information corresponding to the target service from the service request message; Based on the user's basic information, the user's home region is queried from the configuration library to obtain the service traffic of the target service; Based on the service traffic of the target service, query the service traffic switching information of the target service from the configuration library. The service traffic switching information is used to reflect whether the service traffic is in production, emergency, or unavailable state. The service traffic switching information is automatically updated based on the detection results of production and emergency services, combined with the abnormal threshold of detection indicators and switching rules in the configuration library. Based on the business traffic switching information, the user's basic information is queried from the ADG data filter table in the emergency database to confirm that the user has no pending emergency business data; wherein, the ADG data filter table is used to record user number, business data table, database row identifier and SQL operation type information generated by the emergency system in processing the target business.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the emergency switching method as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the emergency switching method as described in any one of claims 1 to 6.

Images