Business system disaster recovery configuration determination method and device and electronic equipment

Abstract

The invention discloses a business system disaster recovery configuration determination method and device and electronic equipment. The method comprises the following steps: determining dependency between a target system and an associated system; under the condition that the dependency is smaller than a preset dependency threshold value, determining that the first disaster recovery strategy of the associated system comprises the step of controlling interaction between the associated system and the target system; and determining disaster recovery configuration of the target system based on the first disaster recovery strategy. According to the invention, the technical problem that the disaster recovery capability of a business system is not ideal in the prior art is solved.

Description

Technical Field

[0001] The present application relates to the field of software development, and more specifically, to a method, device, and electronic device for determining disaster recovery configuration of a business system. Background Art

[0002] In distributed systems and microservices architectures, interdependencies between systems are fundamental to their normal operation. However, this interdependence also complicates disaster recovery design, especially when a system relies on multiple external services. The failure of any one of these external services could impact the stability and business continuity of the core system. Furthermore, with technological advancements, disaster recovery configurations for inter-system dependencies are shifting towards more refined and dynamic strategies. System disaster recovery configurations are no longer static; instead, they must be dynamically adjusted based on real-time assessments of inter-system dependencies and business needs. Therefore, an efficient and reliable disaster recovery configuration has become an integral part of system design. Disaster recovery configurations in related technologies primarily rely on redundancy and failover. For example, deploying multiple data centers for off-site data backup or using load balancing technology to distribute requests across multiple servers to mitigate single points of failure. However, these approaches have limitations in terms of resource cost, complexity, and maintainability, especially in scenarios with high concurrency and large-scale data processing. Furthermore, the inability to dynamically adjust disaster recovery strategies makes it difficult to adapt to changing business needs and system environments. Consequently, related technologies suffer from suboptimal disaster recovery capabilities.

[0003] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0004] The embodiments of the present application provide a method, device, and electronic device for determining disaster recovery configuration of a business system, so as to at least solve the technical problem of unsatisfactory disaster recovery capability of a business system existing in the related art.

[0005] According to one aspect of an embodiment of the present application, a method for determining disaster recovery configuration of a business system is provided, including: determining the dependency between a target system and an associated system; when the dependency is less than a predetermined dependency threshold, determining a first disaster recovery strategy for the associated system including controlling the interaction between the associated system and the target system; and determining the disaster recovery configuration of the target system based on the first disaster recovery strategy.

[0006] Optionally, after determining that the first disaster recovery strategy of the associated system includes controlling the interaction between the associated system and the target system, the method further includes: determining the state of a degradation switch of the associated system, wherein the degradation switch is a component that controls the state of the interaction between the associated system and the target system; when the state of the degradation switch is closed, executing the interaction between the target system and the associated system; and when the state of the degradation switch is open, stopping the interaction between the target system and the associated system.

[0007] Optionally, the method further includes: when the dependency is greater than or equal to a dependency threshold, determining that the second disaster recovery strategy of the associated system includes adjusting the data source for data acquisition by the target system; and determining the disaster recovery configuration of the target system based on the second disaster recovery strategy. Optionally, after determining that the second disaster recovery strategy of the associated system includes adjusting the data source for data acquisition by the target system, the method further includes: determining the state of a cache switch of the associated system, wherein the cache switch is a component that controls the data source for the target system to acquire target data, the data source includes a first cache and a second cache, and the storage duration of the first cache is less than the storage duration of the second cache; when the cache switch is closed, controlling the target system to execute acquisition of target data from the first cache; and when the cache switch is open, controlling the target system to execute acquisition of target data from the second cache.

[0008] Optionally, controlling the target system to execute acquisition of target data from the first cache includes: determining a first existence state of the target data in the second cache; if the first existence state is that the target data exists, determining a second existence state of the target data in the first cache; if the second existence state is that the target data exists, acquiring the target data from the first cache; if the second existence state is that the target data does not exist, controlling the target system to interact with the associated system to acquire the target data; storing the target data in the first cache; if the first existence state is that the target data does not exist, controlling the target system to interact with the associated system to acquire the target data; storing the target data in the second cache; and updating the target data to the first cache.

[0009] Optionally, controlling the target system to execute obtaining target data from the second cache includes: determining a first existence state of the target data in the second cache; if the first existence state is that the target data exists, obtaining the target data from the second cache; if the first existence state is that the target data does not exist, controlling the target system to interact with an associated system to obtain the target data; storing the target data in the second cache; and updating the target data to the first cache.

[0010] Optionally, determining the dependency between the target system and the associated system includes: determining the business type processed by the target system; obtaining the average response time of the associated system to the business type within a predetermined historical time period; and determining the dependency based on the business type and the average response time.

[0011] Optionally, the method further includes: obtaining a data update notification from the associated system; and updating the updated data of the associated system to the first cache of the target system according to the data update notification.

[0012] According to another aspect of an embodiment of the present application, a business system disaster recovery configuration determination device is provided, including: a dependency determination module, used to determine the dependency between a target system and an associated system; a disaster recovery strategy determination module, used to determine, when the dependency is less than a predetermined dependency threshold, that a first disaster recovery strategy of the associated system includes controlling the interaction between the associated system and the target system; and a disaster recovery configuration determination module, used to determine the disaster recovery configuration of the target system based on the first disaster recovery strategy.

[0013] According to another aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors implement any one of the methods for determining a disaster recovery configuration of a business system.

[0014] In an embodiment of the present application, the dependency between a target system and an associated system is determined; if the dependency is less than a predetermined dependency threshold, a first disaster recovery strategy for the associated system is determined, including controlling the interaction between the associated system and the target system; and based on the first disaster recovery strategy, the disaster recovery configuration of the target system is determined. This achieves the goal of determining the disaster recovery strategy of the associated system based on the dependency between the target system and the associated system, and further determining the disaster recovery configuration of the target system, thereby achieving the technical effect of improving the disaster recovery capability of the system and resolving the technical problem of suboptimal disaster recovery capability of business systems existing in related technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0016] Figure 1 This is a flowchart of a method for determining disaster recovery configuration of a business system provided in accordance with an embodiment of the present application;

[0017] Figure 2 This is a schematic diagram of an optional method for determining a disaster recovery configuration of a business system provided according to an embodiment of the present application;

[0018] Figure 3 It is a schematic diagram of an optional business system disaster recovery configuration determination device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0020] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0021] For ease of description, some nouns or terms involved in the embodiments of the present application are explained below:

[0022] Disaster tolerance (DRT) is a technical approach that ensures business continuity and availability across diverse physical devices, locations, or network environments. Its purpose is to ensure rapid recovery of critical services, minimize disruption, and maintain data integrity and security when a disaster strikes.

[0023] Circuit breaking and degradation is a protection and fault tolerance mechanism used by distributed systems in microservice architectures to deal with service call timeouts and service unavailability, and to prevent the entire service cluster from crashing due to abnormalities in some services.

[0024] Kafka is a high-throughput distributed publish-subscribe messaging system used to process large amounts of real-time data. It has the characteristics of low latency, high reliability, and high scalability when processing data streams.

[0025] According to an embodiment of the present application, a method embodiment of a method for determining a disaster recovery configuration of a business system is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0026] Figure 1 Flowchart of a method for determining disaster recovery configuration of a business system provided in accordance with an embodiment of the present application. Figure 1 As shown, the method includes the following steps:

[0027] Step S102, determining the dependency between the target system and the associated systems;

[0028] It can be understood that identifying the associated systems that have dependencies on the target system, as well as the dependencies between the target system and the associated systems, quantifies the dependencies between the target system and the associated systems. By determining the dependencies between the target system and the associated systems, the system can more effectively respond to instability in some services, thereby improving the overall stability of the system.

[0029] In an optional embodiment, determining the dependency between the target system and the associated system includes: determining the business type processed by the target system; obtaining the average response time of the associated system to the business type within a predetermined historical time period; and determining the dependency based on the business type and the average response time.

[0030] It is understandable that the type of business processed by the target system is determined. For example, the target system can be, but is not limited to, a system for processing transaction business, that is, the target system can be, but is not limited to, a transaction system, and the transaction system is mainly used to process transaction business between the transaction system and the transaction object. The operation records of the associated system within a predetermined historical time period are obtained, and the average response time of the associated system for the business type within the predetermined historical time period is determined. Based on the above business type and the average response time of the associated system, the dependency between the target system and the associated system is determined. By accurately assessing the dependency, a reasonable disaster recovery strategy can be set for the associated system, thereby protecting the continuity of the core business process and the consistency of the data when some associated systems fail, thereby improving the stability and robustness of the entire system.

[0031] Alternatively, for transaction processing within a trading system, if the average response time of a dependent system (i.e., an associated system) is excessively long, perhaps exceeding one second, then its impact on transaction speed is significant and can be assessed as a strong dependency, meaning the dependency is greater than or equal to the dependency threshold. Conversely, if the average response time is very short, such as in the millisecond range, then its impact on transaction immediacy is minimal and can be considered a weak or non-strong dependency, meaning the dependency is less than the dependency threshold.

[0032] Optionally, the dependency between the transaction system and the associated system can be assessed based on the impact of failures in the associated system over a historical period, data consistency, and resource consumption. Regarding the impact of failures, if the impact on the entire transaction process due to a failure in the associated system over a historical period is significant, the associated system can be assigned a lower dependency, and a circuit breaker degradation strategy can be adopted as the disaster recovery strategy for the associated system. Regarding data consistency, if the data accuracy of the associated system over a historical period is poor, a higher dependency can be assigned to the associated system, and data can be backed up using a long-short cache strategy. Regarding resource consumption, if the associated system consumes a large amount of resources on the transaction system during operation, a higher dependency can be assigned to the associated system, and data can be backed up using a long-short cache strategy to reduce the process of obtaining data through interaction. Because the dependency of associated systems is affected by multiple factors, the dependency of associated systems can be determined by comprehensively considering these factors.

[0033] Step S104, when the dependency is less than a predetermined dependency threshold, determining that the first disaster recovery strategy of the associated system includes controlling the interaction between the associated system and the target system;

[0034] It can be understood that by comparing the dependency between the target system and the associated system with the predetermined dependency threshold, if the dependency is less than the dependency threshold, it means that the associated system is a weakly dependent system. In this case, the first disaster recovery strategy (i.e., the circuit breaker degradation strategy) is adopted for the associated system. By introducing a degradation switch for the associated system, the interaction between the associated system and the target system is controlled. The first disaster recovery strategy can effectively reduce the risk of core system crashes or service interruptions caused by failures in non-strongly dependent systems. This allows the system to maintain basic functionality even when some dependent systems are unstable, thereby enhancing the overall robustness and fault resistance of the system and ensuring the continuity and high availability of key business processes.

[0035] In an optional embodiment, after determining that the first disaster recovery strategy of the associated system includes controlling the interaction between the associated system and the target system, the method further includes: determining the state of a degradation switch of the associated system, wherein the degradation switch is a component that controls the interaction state between the associated system and the target system; when the state of the degradation switch is closed, executing the interaction between the target system and the associated system; and when the state of the degradation switch is open, stopping the interaction between the target system and the associated system.

[0036] It can be understood that if the associated system adopts the first disaster recovery strategy (i.e., the fuse degradation strategy), when receiving an interaction request with the associated system, the state of the degradation switch of the associated system is first determined. Among them, the above-mentioned degradation switch is a component that controls the interaction state between the associated system and the target system. If the state of the degradation switch is closed, the interaction between the target system and the associated system is executed; if the state of the degradation switch is open, the interaction between the target system and the associated system is stopped, the target system skips the interaction with the associated system, and continues to execute the next business process to avoid business interruption. By dynamically controlling the interaction process between the target system and the associated system through the degradation switch, the target system can continue to process business when some non-critical associated systems fail, avoiding the entire system from completely collapsing due to partial failures, thereby enhancing the stability and disaster recovery capabilities of the system.

[0037] Step S106: Determine the disaster recovery configuration of the target system based on the first disaster recovery strategy.

[0038] As you can see, the target system's disaster recovery configuration is determined based on the primary disaster recovery strategy of the associated system. By distinguishing between highly dependent and less dependent systems and adopting different disaster recovery strategies, system design and maintenance becomes simpler and more efficient, reducing the complexity and cost of system maintenance.

[0039] In an optional embodiment, the method further includes: when the dependency is greater than or equal to a dependency threshold, determining a second disaster recovery strategy of the associated system includes adjusting a data source for acquiring data for the target system; and determining a disaster recovery configuration of the target system based on the second disaster recovery strategy.

[0040] As can be understood, the dependency between the target system and the associated system is compared against a predetermined dependency threshold. If the dependency is greater than or equal to the dependency threshold, indicating a strong dependency, a second disaster recovery strategy (i.e., a long-short cache strategy) is implemented for the associated system. This strategy introduces a cache switch in the associated system to control the data source from which the target system retrieves data. Based on the second disaster recovery strategy for the associated system, the target system's disaster recovery configuration is determined. This dual-cache strategy reduces the need for real-time queries to external systems, thereby minimizing the impact of external system failures on the target system and improving system autonomy and stability.

[0041] Optionally, in order to ensure the stability of the target system link, learn from the historical risks of link unavailability caused by external systems, sort out all external systems that the link depends on, use a circuit breaker degradation strategy for non-strongly dependent systems, and uniformly connect the degradation switch. When a failure occurs in a related system that the target system depends on, the degradation switch is turned on and the call to the related system (i.e., interaction) is skipped; for strongly dependent systems, use a long-short cache strategy and add a control switch for switching between long and short caches (i.e., cache switch). In normal transactions, the switch is closed and the short cache data is used for transactions. When a failure occurs, it is downgraded to the long cache and the backup data in the long cache is used for transactions.

[0042] Optionally, sort out all the related systems that the target system depends on. In order to solve the problem of uncontrollable related systems and risk degradation, the results of external calls (i.e. interactions) (i.e. target data) can be cached to guarantee the results of external queries. Taking the transaction system of third-party payment (i.e. target system) as an example, determine which external systems (i.e. related systems) the transaction system depends on, what are the interfaces, which fields are required for input and output parameters, what is the purpose of calling external interfaces, whether there is currently any caching of the return parameters of these dependent external systems, and determine whether these external systems are strongly dependent. For example, for a transaction system, the dependent external systems involve the transaction subjects - individuals, merchants, basic product information, and the corresponding permissions required for the transaction - agreements, solutions, channels and other related information.

[0043] Alternatively, for external systems determined by the transaction system, basic information such as individuals, merchants, and products is considered subject information and is a highly dependent external system of the transaction system. Without the basic information of users or merchants, the closed loop of transaction information flow and capital flow cannot be completed. Therefore, such systems cannot adopt a circuit breaker degradation strategy (i.e., the first disaster recovery strategy) and can only improve the system's fault tolerance by adopting a long-short dual cache strategy (i.e., the second disaster recovery strategy). For external systems such as protocols and channel verification that are not highly dependent, when these external systems fail, a circuit breaker degradation strategy can be adopted, adding a degradation switch to skip the verification with these external systems (i.e., interacting with these external systems) to ensure the normal progress of transactions. However, under normal circumstances, relevant verification and increased caching are still required to further improve the system's fault tolerance.

[0044] In an optional embodiment, after determining that the second disaster recovery strategy of the associated system includes adjusting the data source for data acquisition by the target system, the method further includes: determining the state of a cache switch of the associated system, wherein the cache switch is a component that controls the data source for the target system to acquire target data, the data source includes a first cache and a second cache, and the storage duration of the first cache is shorter than the storage duration of the second cache; when the cache switch is closed, controlling the target system to execute acquisition of target data from the first cache; and when the cache switch is open, controlling the target system to execute acquisition of target data from the second cache.

[0045] It can be understood that if the associated system adopts the second disaster recovery strategy (i.e., the long-short cache strategy), when receiving an interaction request with the associated system and obtaining the target data, the state of the cache switch of the associated system is first determined. Among them, the above-mentioned cache switch is a component that controls the data source of the target system to obtain the target data. The data source is divided into a first cache (i.e., a short cache) and a second cache (i.e., a long cache), and the storage duration of the short cache is shorter than the storage duration of the long cache. If the state of the cache switch is off, the target system is controlled to obtain the target data from the short cache; if the state of the cache switch is on, the target system is controlled to obtain the target data from the long cache. The long-short cache strategy reduces real-time calls to external systems, reduces network latency and resource consumption, while avoiding the software and hardware resource costs brought about by active-active deployment, and improving the overall robustness and disaster recovery capabilities of the system.

[0046] Optionally, for strongly dependent systems, query and verify the results returned by these systems, creating a new long cache and short cache to cache external query results. The long cache provides a data backup, typically set to 2-7 days. The short cache is used for regular transaction verification and to reduce external interface queries, typically set to 2 hours. When the switch is on, the long cache is used as a backup.

[0047] In an optional embodiment, controlling the target system to execute acquisition of target data from the first cache includes: determining a first existence state of the target data in the second cache; if the first existence state is that the target data exists, determining a second existence state of the target data in the first cache; if the second existence state is that the target data exists, acquiring the target data from the first cache; if the second existence state is that the target data does not exist, controlling the target system to interact with an associated system to acquire the target data; storing the target data in the first cache; if the first existence state is that the target data does not exist, controlling the target system to interact with an associated system to acquire the target data; storing the target data in the second cache; and updating the target data to the first cache.

[0048] It will be understood that if the cache switch is off, that is, when the target system is controlled to retrieve target data from the short cache, the first existence status of the target data in the second cache is determined, that is, whether the target data exists in the second cache. If the first existence status is that the target data exists, that is, the target data exists in the second cache, then the second existence status of the target data in the first cache is determined, that is, whether the target data exists in the first cache. If the second existence status is that the target data exists, that is, the target data exists in the first cache, then the target system is controlled to retrieve the target data from the first cache. If the second existence status is that the target data does not exist, that is, the target data does not exist in the first cache, then the target system is controlled to interact with the associated system to retrieve the target data and store the target data in the first cache. If the first existence status is that the target data does not exist, that is, the target data does not exist in the second cache, then the target system is controlled to interact with the associated system to retrieve the target data, store the target data in the second cache, and update the target data in the first cache. By prioritizing data retrieval from the first cache, the target system can quickly respond to requests, significantly reducing the time waiting for query results from external systems and improving the speed and efficiency of business processing.

[0049] In an optional embodiment, controlling the target system to execute acquisition of target data from the second cache includes: determining a first existence state of the target data in the second cache; if the first existence state is that the target data exists, acquiring the target data from the second cache; if the first existence state is that the target data does not exist, controlling the target system to interact with an associated system to acquire the target data; storing the target data in the second cache; and updating the target data to the first cache.

[0050] It can be understood that if the state of the cache switch is on, that is, when the target system is controlled to obtain the target data from the long cache, first, the first existence state of the target data in the second cache is determined, that is, whether the target data exists in the second cache. If the first existence state is that the target data exists, that is, the target data exists in the second cache, then the target system is controlled to obtain the target data from the second cache. If the first existence state is that the target data does not exist, that is, the target data does not exist in the second cache, then the target system is controlled to interact with the associated system to obtain the target data, and store the target data in the second cache, and update the target data to the first cache. By using the data in the second cache, the target system can continue to process transactions when the associated system fails, reducing the probability of transaction interruption, and enhancing the disaster recovery capability and stability of the system. At the same time, during the recovery of the associated system failure, the second cache acts as a data backup and can immediately provide the required data, avoiding transaction delays caused by waiting for the associated system to fully recover, shortening the failure recovery time, and ensuring business continuity.

[0051] Optionally, for a trading system, when a transaction request is made to the trading system, when calling all dependent external systems, for weakly dependent systems, the trading system first determines whether the degradation switch is on. If the switch is off, the external system call is performed normally. For strongly dependent systems, before the call, it will first determine whether the cache switch is on. Under normal circumstances, the cache switch is off and will only be turned on in case of an emergency in the downstream system. When the cache switch is off, the content of the short cache (i.e., the target data) is used to first determine whether the target data is in the long cache. If not, the external system is called for query, and the query result (i.e., the target data) is updated to the long cache before continuing to process downwards. If the content in the long cache is determined to exist, the content in the short cache is used for the transaction. If the content in the short cache does not exist, indicating that the content has expired, the external system is called for query, and the query result is updated to the short cache before continuing to process downwards. When the long cache switch is on, the snapshot information in the long cache is used as the target data. First, determine whether there is target data in the long cache. If so, take the content of the long cache for transaction. If there is no target data in the long cache, call the external system query, and update the query result to the long cache before continuing the transaction.

[0052] In an optional embodiment, the method further includes: obtaining a data update notification from the associated system; and updating the updated data of the associated system to the first cache of the target system according to the data update notification.

[0053] As you can understand, the target system acquires the message queue of the associated system and sends a data update notification to the target system when the data in the associated system changes. Upon receiving the data update notification, the target system parses the notification, determines the updated data, and then updates the updated data to the target system's first cache. By receiving data update notifications in real time, the target system can quickly reflect the latest changes to the associated system's data, ensuring the real-time and accuracy of the first cache data, thereby improving system responsiveness and user experience.

[0054] Optionally, the trading system can update the short cache data by accessing Kafka messages from each associated system. When certain data in an associated system changes, the trading system's Kafka message notification updates the short cache data, ensuring the accuracy of the short cache data and the real-time and integrity of transactions under normal circumstances.

[0055] In step S102, the dependency between the target system and the associated system is determined. In step S104, if the dependency is less than a predetermined dependency threshold, a first disaster recovery strategy for the associated system is determined, including controlling the interaction between the associated system and the target system. In step S106, the disaster recovery configuration of the target system is determined based on the first disaster recovery strategy. This method can achieve the purpose of determining the disaster recovery strategy of the associated system based on the dependency between the target system and the associated system, and further determining the disaster recovery configuration of the target system, thereby achieving the technical effect of improving the disaster recovery capability of the system and solving the technical problem of unsatisfactory disaster recovery capability of business systems existing in related technologies.

[0056] Based on the above embodiments and optional embodiments, the present application proposes an optional implementation method, which implements a system disaster recovery practice method based on a degradation switch + dual cache, configures the transaction system (i.e., the target system) for disaster recovery, and improves the disaster recovery capability of the transaction system. This method sorts each associated system according to strong and weak dependencies, adopts a first disaster recovery strategy (i.e., a fuse degradation strategy) for the weakly dependent associated system, and controls the interaction between the associated system and the target system by introducing a degradation switch to the associated system. When a weakly dependent associated system fails, the degradation switch is turned on and the call to the associated system is skipped. A second disaster recovery strategy (i.e., a long-short cache strategy) is adopted for the strongly dependent system, and a cache switch is introduced to the associated system to control the data source from which the target system obtains data. Under normal circumstances, transactions are conducted based on the content of the short cache to ensure data accuracy. When an application fails, the real-time data may be inaccurate due to problems such as human versioning. The cache switch is switched to the long cache, and transactions are conducted using the snapshot data in the long cache (i.e., the target data), ensuring that the transaction link is not completely blocked due to external system failures, thereby improving system stability and user experience.

[0057] Step S1: sort out the dependent external system information.

[0058] Determine the external systems (i.e., related systems) that the trading system depends on, their interfaces, the fields required for input and output parameters, the purpose of calling external interfaces, whether the parameters returned by these dependent external systems are currently cached, and whether these external systems are strongly dependent. For example, for a trading system, the dependent external systems include the basic information of the transaction subjects (individuals, merchants, and products), as well as the corresponding permissions required for transactions (protocols, solutions, channels, etc.). For external systems determined by the trading system, basic information such as individuals, merchants, and products is considered subject information and is a strong external dependency of the trading system. Without basic user or merchant information, the closed loop of transaction information and capital flows cannot be completed. Therefore, such systems cannot adopt a circuit breaker degradation strategy (i.e., the first disaster recovery strategy) and can only improve the system's fault tolerance by adopting a long-short dual buffering strategy (i.e., the second disaster recovery strategy). For external systems that are not strongly dependent, such as protocol and channel verification, when these external systems fail, a circuit breaker degradation strategy can be implemented. This degradation switch can skip the verification (i.e., interaction with these external systems) to ensure normal transaction processing. However, under normal circumstances, it is still necessary to perform relevant checks and increase cache to further improve the fault tolerance of the system.

[0059] Step S2: Add a long and short cache to the external query results.

[0060] For strongly dependent systems, the results returned by query verification for these systems will be cached using new long and short caches to cache external query results. The long cache provides a data backup, typically set to 2-7 days. The short cache is used for routine transaction verification and to reduce external interface queries, typically set to 2 hours. When enabled, the long cache is used as a backup.

[0061] When a transaction request arrives at the trading system, the system calls all dependent external systems. For weakly dependent systems, the system first checks whether the degradation switch is enabled. If it is, the external system call proceeds normally. For strongly dependent systems, the system first checks whether the cache switch is enabled. Normally, the cache switch is disabled and only enabled in the event of a downstream system failure. When the cache switch is disabled, the system uses the contents of the short cache (i.e., the target data) to first determine whether the target data exists in the long cache. If not, the system calls the external system for a query, updates the query result (i.e., the target data) to the long cache before continuing with the transaction. If the long cache contains the target data, the system uses the contents of the short cache for the transaction. If the short cache does not contain the target data, indicating that the content has expired, the system calls the external system for a query, updates the query result to the short cache, and continues with the transaction. When the long cache is enabled, the system uses the snapshot information in the long cache as the target data. First, the system checks whether the target data exists in the long cache. If so, the transaction proceeds using the contents of the long cache. If not, the system calls the external system for a query, updates the query result to the long cache, and continues with the transaction.

[0062] Figure 2 is a schematic diagram of an optional method for determining a disaster recovery configuration of a business system provided in an embodiment of the present application, such as Figure 2 The following is a diagram showing the execution process of the long and short cache strategies. Figure 2 As shown, the cache switch status is first determined. If the cache switch is off, the target system is directed to retrieve the target data from the short cache. First, the target data is determined to exist in the long cache. If the target data exists in the long cache, the target data is determined to exist in the short cache. If the target data exists in the short cache, the trading system is directed to retrieve the target data from the short cache. If the target data does not exist in the short cache, an external message is called to return the query result (i.e., the target data), thereby controlling the trading system to interact with the associated system to obtain the target data. A determination is then made as to whether the query result is empty. If not, the query result is used and stored in the short cache. If not, the transaction status is intercepted, with the logic remaining unchanged. If the target data does not exist in the long cache, an external message is called to return the query result to retrieve the target data. A determination is then made as to whether the query result is empty. If not, the query result is used and stored in the long cache, and the target data is updated in the short cache. If not, the transaction status is intercepted, with the logic remaining unchanged.

[0063] like Figure 2As shown, if the cache switch is on, that is, when controlling the target system to obtain the target data from the long cache, first, determine whether the target data exists in the long cache. If the target data exists in the long cache, the long cache configuration is used, and the long cache configuration information is used as a backup cache configuration, that is, the target data in the long cache is used as a backup, and the target system is controlled to obtain and use the target data from the long cache. If the target data does not exist in the long cache, the external information is called to return the query result to obtain the target data. Determine whether the query result is empty. If it is not empty, use the query result, store the query result in the long cache, and update the target data to the short cache; if it is empty, intercept the transaction status, and the logic remains unchanged.

[0064] Step S3: Receive Kafka refresh cache from each dependent party.

[0065] Receive the Kafka message notification queue of each associated system of the trading system. When certain information of the associated system changes, the trading system can update the short cache information through message notification. This ensures that under normal circumstances, the information in the short cache is consistent with the information returned by the synchronous query interface of the associated system, ensuring the accuracy of the information in the short cache.

[0066] The above optional implementation methods achieve at least the following effects: the robustness and disaster recovery capabilities of the target system are enhanced through the degradation switch and long-short cache strategy, and the stability of the target system and user experience are improved; the long-short cache strategy reduces the dependency between systems, ensures the high availability of core business, and improves the security and stability of the system.

[0067] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0068] This embodiment also provides a device for determining a business system disaster recovery configuration. This device is used to implement the above-mentioned embodiments and preferred implementations, and details already described will not be repeated. As used below, the terms "module" and "device" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0069] According to an embodiment of the present application, there is also provided an embodiment of a device for implementing a method for determining a disaster recovery configuration of a business system. Figure 3 is a schematic diagram of a device for determining disaster recovery configuration of a business system according to an embodiment of the present application, such as Figure 3As shown, the above-mentioned business system disaster recovery configuration determination device includes a dependency determination module 302, a disaster recovery strategy determination module 304, and a disaster recovery configuration determination module 306. The device is described below.

[0070] A dependency determination module 302 is used to determine the dependency between the target system and the associated system;

[0071] a disaster recovery strategy determination module 304, connected to the dependency determination module 302, for determining, when the dependency is less than a predetermined dependency threshold, that a first disaster recovery strategy of the associated system includes controlling the interaction between the associated system and the target system;

[0072] The disaster recovery configuration determination module 306 is connected to the disaster recovery strategy determination module 304 and is configured to determine the disaster recovery configuration of the target system based on the first disaster recovery strategy.

[0073] In a business system disaster recovery configuration determination device provided in an embodiment of the present application, a dependency determination module 302 is provided for determining the dependency between a target system and an associated system; a disaster recovery strategy determination module 304 is connected to the dependency determination module 302 and is used to determine, when the dependency is less than a predetermined dependency threshold, a first disaster recovery strategy for the associated system, including controlling the interaction between the associated system and the target system; and a disaster recovery configuration determination module 306 is connected to the disaster recovery strategy determination module 304 and is used to determine the disaster recovery configuration of the target system based on the first disaster recovery strategy. The device achieves the purpose of determining the disaster recovery strategy of the associated system based on the size of the dependency between the target system and the associated system, and then determining the disaster recovery configuration of the target system, thereby achieving the technical effect of improving the disaster recovery capability of the system and solving the technical problem of unsatisfactory disaster recovery capability of the business system existing in the related art.

[0074] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0075] It should be noted that the dependency determination module 302, disaster recovery strategy determination module 304, and disaster recovery configuration determination module 306 correspond to steps S102 to S106 in the embodiment. The examples and application scenarios implemented by these modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above embodiment. It should be noted that these modules, as part of the device, can be run on a computer terminal.

[0076] It should be noted that the optional or preferred implementation of this embodiment can be found in the relevant description in the embodiment, which will not be repeated here.

[0077] The above-mentioned business system disaster recovery configuration determination device can also include a processor and a memory. The dependency determination module 302, the disaster recovery strategy determination module 304, the disaster recovery configuration determination module 306, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize the corresponding functions.

[0078] The processor includes a kernel, which retrieves the corresponding program unit from memory. There can be one or more kernels. Memory may include non-permanent memory in a computer-readable medium, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory includes at least one memory chip.

[0079] An embodiment of the present application provides a non-volatile storage medium having a program stored thereon, which, when executed by a processor, implements a method for determining a disaster recovery configuration of a business system.

[0080] An embodiment of the present application provides an electronic device comprising a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, the following steps are performed: determining a dependency between a target system and an associated system; when the dependency is less than a predetermined dependency threshold, determining a first disaster recovery strategy for the associated system, including controlling the interaction between the associated system and the target system; and determining a disaster recovery configuration for the target system based on the first disaster recovery strategy. The device herein may be a server, a PC, or the like.

[0081] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having the following method steps: determining the dependency between a target system and an associated system; when the dependency is less than a predetermined dependency threshold, determining a first disaster recovery strategy for the associated system including controlling the interaction between the associated system and the target system; and determining a disaster recovery configuration for the target system based on the first disaster recovery strategy.

[0082] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0083] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0084] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0085] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0086] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0087] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0088] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0089] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0090] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0091] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A method for determining disaster recovery configuration of a business system, characterized in that: include: Determine the dependencies between the target system and related systems; In a case where the dependency is less than a predetermined dependency threshold, determining a first disaster recovery strategy for the associated system includes controlling interaction between the associated system and the target system; Based on the first disaster recovery strategy, a disaster recovery configuration of the target system is determined.

2. The method according to claim 1, characterized in that After determining that the first disaster recovery strategy of the associated system includes controlling the interaction between the associated system and the target system, the method further includes: determining a state of a degradation switch of the associated system, wherein the degradation switch is a component that controls an interaction state between the associated system and the target system; Under the condition that the state of the degradation switch is off, executing the interaction between the target system and the associated system; Under the condition that the degradation switch is turned on, the interaction between the target system and the associated system is stopped.

3. The method according to claim 1, characterized in that The method further comprises: In a case where the dependency is greater than or equal to the dependency threshold, determining the second disaster recovery strategy of the associated system includes adjusting a data source for acquiring data by the target system; Based on the second disaster recovery strategy, a disaster recovery configuration of the target system is determined.

4. The method according to claim 2, characterized in that After determining that the second disaster recovery strategy of the associated system includes adjusting a data source for acquiring data from the target system, the method further includes: Determining a state of a cache switch of the associated system, wherein the cache switch is a component that controls the target system to obtain a data source of target data, the data source including a first cache and a second cache, and a storage duration of the first cache is shorter than a storage duration of the second cache; When the cache switch is in an off state, controlling the target system to obtain target data from the first cache; When the cache switch is turned on, the target system is controlled to obtain target data from the second cache.

5. The method according to claim 4, characterized in that The controlling the target system to obtain target data from the first cache includes: determining a first existence status of target data in the second cache; If the first existence status indicates that the target data exists, determining the second existence status of the target data in the first cache; if the second existence status indicates that the target data exists, obtaining the target data from the first cache; if the second existence status indicates that the target data does not exist, controlling the target system to interact with the associated system to obtain the target data; and storing the target data in the first cache; If the first existence state is that the target data does not exist, controlling the target system to interact with the associated system to obtain the target data; storing the target data in the second cache; and updating the target data in the first cache.

6. The method according to claim 4, characterized in that The controlling the target system to obtain target data from the second cache includes: determining a first existence status of target data in the second cache; If the first existence status indicates that the target data exists, obtaining the target data from the second cache; If the first existence state is that the target data does not exist, controlling the target system to interact with the associated system to obtain the target data; storing the target data in the second cache; and updating the target data in the first cache.

7. The method according to claim 1, characterized in that Determining the dependency between the target system and the associated systems includes: Determining the type of business processed by the target system; Obtaining an average response time of the associated system to services of the service type within a predetermined historical time period; The dependency is determined based on the service type and the average response time.

8. The method according to any one of claims 1 to 7, characterized in that The method further comprises: Obtaining data update notifications of the associated system; According to the data update notification, the updated data of the associated system is updated to the first cache of the target system.

9. A device for determining disaster recovery configuration of a business system, characterized in that: include: A dependency determination module, used to determine the dependencies between the target system and the associated systems; a disaster recovery strategy determination module, configured to, when the dependency is less than a predetermined dependency threshold, determine that a first disaster recovery strategy of the associated system includes controlling the interaction between the associated system and the target system; A disaster recovery configuration determination module is used to determine the disaster recovery configuration of the target system based on the first disaster recovery strategy.

10. An electronic device, characterized in that: include: One or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method for determining the disaster recovery configuration of a business system as described in any one of claims 1 to 8.

Images