A disaster recovery method for a third-party payment system and a third-party payment system

By predicting load using the Prophet algorithm and adjusting resource allocation using the Isolation Forest algorithm, the problem of load imbalance in third-party payment systems is solved, improving user-friendliness and system stability, and ensuring uninterrupted operation of the payment system in the event of a failure.

CN119621444BActive Publication Date: 2025-12-02NANKAI UNIV +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202510163062.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-02-14
Publication Date
2025-12-02
Estimated Expiration
2045-02-14

AI Technical Summary

Technical Problem

Existing third-party payment systems suffer from language and usage habit differences in electronic and mobile payments, resulting in a poor user experience. Furthermore, uneven resource consumption leads to uneven node load, which can easily cause crashes or outages, affecting system stability.

Method used

The system employs the Prophet algorithm to predict future loads and combines it with the Isolation Forest algorithm to dynamically adjust resource allocation. Through a microservice architecture and a distributed database, it achieves load balancing and node isolation, ensuring stable system operation.

Benefits of technology

It improves user experience and system fault tolerance, ensures uninterrupted operation of the payment system in the event of node failure, prevents system crashes under excessive load, and enhances the system's high availability and security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119621444B_ABST
    Figure CN119621444B_ABST
Patent Text Reader

Abstract

This invention relates to the field of disaster recovery technology for payment systems, providing a disaster recovery method and system for a third-party payment system. The disaster recovery method includes: predicting the future load of distributed database nodes using a time-series prediction model and dynamically adjusting resource allocation; constructing a distributed database resource occupancy vector based on the resource parameters of the distributed database; calculating the anomaly score at each time step using an isolation tree; identifying abnormal nodes based on the anomaly score and a dynamic threshold, and reallocating resources to the abnormal nodes; and isolating a node if its anomaly score exceeds the dynamic threshold multiple times, thus ensuring the stable operation of the database. This invention enhances the system's high availability and disaster recovery capabilities by combining a distributed database and a microservice architecture. The time-series prediction model ensures the reliable operation of the microservice architecture, and the Isolation Forest algorithm promptly isolates abnormal nodes to maintain system stability.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of disaster recovery technology for payment systems, and in particular to a disaster recovery method and a third-party payment system. Background Technology

[0002] Currently, third-party payment systems suffer from language and usage habit differences in electronic and mobile payments, resulting in a poor user experience. During operation, uneven resource allocation can lead to some nodes being overloaded while others are underloaded, causing slow operation or even system crashes. Furthermore, when a node fails, the uneven load can cause system downtime or crashes, preventing the payment system from functioning properly. Therefore, disaster recovery is a critical issue that urgently needs to be addressed to ensure the stability and reliability of payment systems. Summary of the Invention

[0003] This invention aims to at least solve one of the technical problems existing in related technologies. To this end, this invention provides a disaster recovery method and a third-party payment system. This invention uses a time-series prediction algorithm to predict future load, avoiding situations where a single point bears too much load. When a node or database fails, the system detects service unavailability using an Isolation Forest algorithm and quickly activates a backup node. The backup node automatically takes over the business requests from the failed node, ensuring that normal user access is not affected, and distributes requests to available server nodes, improving the system's processing efficiency and fault tolerance.

[0004] This invention provides a disaster recovery method for a third-party payment system, comprising:

[0005] S1: Predict the future load of distributed database nodes using a time-series forecasting model, and dynamically adjust the resource allocation of the distributed database based on the future load;

[0006] S2: Obtain the resource parameters of the distributed database and construct the distributed database resource occupancy vector based on the resource parameters of the distributed database;

[0007] S3: Construct an isolation tree based on the distributed database resource usage vector, and calculate the anomaly score based on the isolation tree;

[0008] S4: Set dynamic thresholds based on abnormal scores;

[0009] S5: Identify abnormal nodes based on the abnormal score and dynamic threshold, and reallocate resources to the abnormal nodes;

[0010] S6: Repeat steps S2 to S5 to detect abnormal nodes at each time step. If a node has multiple abnormal scores that exceed the dynamic threshold, then isolate the node to ensure the stable operation of the distributed database.

[0011] Furthermore, in step S1, the time-series prediction model is the Prophet model, and the calculation expression for the future load of the distributed database nodes is:

[0012]

[0013] in, for Future load at each time point for The long-term trend function of load at any given time. for The periodic variation function of the load at any given time. This is a function representing the impact of holidays or important events on the load. for Server load at any given time.

[0014] Furthermore, by defining multiple inflection points, the slope of the long-term trend of load changes at each inflection point. The long-term trend function of load can be obtained by manually setting the number of inflection points or by automatically selecting the number of inflection points through the Prophet model.

[0015] The periodic variation function of the load is obtained by fitting the sine and cosine waveforms of multiple periods of Fourier series.

[0016] By defining holidays or important time events, the impact of holidays or important time events on the load is calculated, and the impact function of holidays or important time events on the load is obtained.

[0017] The expression for calculating server load at any given time is:

[0018]

[0019] in, For CPU load, For memory load, For disk I / O load, This refers to the CPU's weighting coefficient. For memory weighting coefficients, This represents the weighting factor for disk I / O.

[0020] Furthermore, the resource parameters of the distributed database are monitored and obtained, including CPU utilization, memory utilization, disk I / O utilization, and network traffic.

[0021] Furthermore, a distributed database resource occupancy vector is constructed based on the resource parameters of the distributed database. The expression for calculating the distributed database resource occupancy vector is as follows:

[0022]

[0023] in, for The resource consumption vector of a distributed database at any given time. for CPU utilization at any time for Real-time memory usage for Disk I / O utilization at any time for Real-time network traffic.

[0024] Furthermore, the process of constructing the isolation tree includes:

[0025] exist Randomly select a point within the range of values ​​as the dividing point;

[0026] like If the value of is greater than the value of the dividing point, then The right subtree;

[0027] like If the value of is less than the value of the dividing point, then Left subtree;

[0028] like The value of is equal to the value of the dividing point, then Main tree;

[0029] In the left subtree or the right subtree Then, randomly select a point within the range of values ​​as the dividing point, and repeat the above process until the range of values ​​has only one value point.

[0030] Furthermore, the expression for calculating the abnormal score is:

[0031]

[0032] in, for Outlier scores at time points To isolate the tree Path length, Based on sample size normalized length, for The average value.

[0033] Furthermore, using historical data, the historical average anomaly score and the standard deviation of the anomaly score for each resource parameter are calculated. The expression for calculating the dynamic threshold is:

[0034]

[0035] in, for The dynamic threshold at any given time. The historical average outlier score. As a regulatory factor, is the standard deviation of outlier scores.

[0036] Furthermore, step S5 includes:

[0037] If the abnormal score is less than or equal to the dynamic threshold, it is considered a normal node.

[0038] If the abnormal score is greater than the dynamic threshold, it is an abnormal node.

[0039] Set the allocation coefficient, and distribute part of the load from the abnormal node to the normal node according to the allocation coefficient.

[0040] A third-party payment system for implementing the aforementioned third-party payment system disaster recovery method includes:

[0041] The language module provides a multilingual system interface to address language differences, allowing users to switch the system language at any time as needed.

[0042] The disaster recovery module adopts a microservice architecture and a distributed database. In the microservice architecture, the Prophet model is used to predict the future load of each node in the distributed database and perform load balancing. In the distributed database, when a node fails, the Isolation Forest algorithm is used to isolate the node.

[0043] The future load of distributed database nodes is predicted by a time-series forecasting model, and the resource allocation of the distributed database is dynamically adjusted according to the future load.

[0044] Obtain the resource parameters of the distributed database, and construct the distributed database resource usage vector based on the resource parameters;

[0045] An isolation tree is constructed based on the distributed database resource usage vector, and anomaly scores are calculated based on the isolation tree.

[0046] Set dynamic thresholds based on abnormal scores;

[0047] Abnormal nodes are identified based on their abnormal scores and dynamic thresholds, and resources are reallocated to these abnormal nodes.

[0048] Detect abnormal nodes at each time point. If a node has multiple abnormal scores exceeding a dynamic threshold, then isolate the node to ensure the stable operation of the distributed database.

[0049] The above-described one or more technical solutions in the embodiments of the present invention have at least one of the following technical effects:

[0050] This invention addresses the language compatibility issues of existing payment systems by integrating multilingual support, enhancing user experience, providing suitable payment method options for local users, and improving the user-friendliness and ease of use of the payment system. Through multiple verification and encryption technologies, it ensures the security of user transaction passwords and financial information, avoiding the risk of payment data leakage during transmission.

[0051] By combining a distributed database and a microservice architecture, the system's high availability and disaster recovery capabilities are enhanced. The Prophet algorithm is used to predict the load of each node, enabling timely and effective load balancing to ensure the reliable operation of the microservice architecture. At the same time, the Isolation Forest algorithm is used to detect the availability of each node in the distributed database, allowing for timely isolation of abnormal nodes and ensuring that the server nodes in the distributed database can continuously serve the payment system.

[0052] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0053] 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.

[0054] Figure 1 This is a flowchart illustrating a disaster recovery method for a third-party payment system provided by the present invention.

[0055] Figure 2 This is a schematic diagram of the structure of a third-party payment system provided by the present invention. Detailed Implementation

[0056] 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. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention. The following embodiments are used to illustrate this invention but cannot be used to limit the scope of this invention.

[0057] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0058] The following is combined with Figures 1 to 2 This invention describes a disaster recovery method for a third-party payment system and a third-party payment system.

[0059] like Figure 1 As shown, a disaster recovery method for a third-party payment system includes:

[0060] S1: Predict the future load of each node in the distributed database using a time-series forecasting model, and dynamically adjust the resource allocation of the distributed database based on the future load;

[0061] The time-series forecasting model is the Prophet model, and the expression for calculating the future load of the distributed database nodes is:

[0062]

[0063] in, for Future load at each time point for The long-term trend function of load at any given time. for The periodic variation function of the load at any given time. This is a function representing the impact of holidays or important events on the load. for Server load at any given time.

[0064] The Prophet model uses a piecewise linear model to describe the long-term trend of load variation. It defines multiple "changepoints," allowing the slope of the trend to change at each changepoint. The expression for calculating the long-term trend function of the load at any given time is:

[0065]

[0066] in, The initial slope, in a payment system, represents the initial trend or growth rate (e.g., the base growth rate of transactions) within the payment system. Store it as a constant or configuration variable, such as in the server's environment or configuration file; The slope of the trend change at each inflection point represents the adjustment of the trend over time (e.g., adjustments due to seasonal changes or sudden increases in trading volume). Model it as a function of time or update it based on a specific inflection point. It can be adjusted periodically.

[0067] Temporal functions are used to capture periodic patterns in load, such as daily load peaks (e.g., load increases during peak hours); Prophet models temporality using Fourier series, fitting the periodicity of load data with sine and cosine waveforms over multiple periods.

[0068] The expression for calculating the periodic change function of the load at any given time is:

[0069]

[0070] in, Let be the order of the Fourier series. For the first The coefficients of the cosine terms of an order Fourier series. For the first The coefficients of the sinusoidal term of an order Fourier series. The working cycle of the payment system;

[0071] In some specific embodiments of the present invention, by setting appropriate It can precisely capture the temporal fluctuations of the load.

[0072] By defining holidays or important time events, the impact of holidays or important time events on the load can be obtained.

[0073] The expression for calculating the impact function of holidays or important events on the load is as follows:

[0074]

[0075] in, For holidays or important events, for The extent of the impact on the load, This is an indicator function.

[0076] A suitable value can be selected by observing the impact of holidays on the payment system load. For when belong The value is 1 if the condition is met, and 0 otherwise.

[0077] In some specific embodiments of the present invention, the short-term peak or trough value of the load caused by the important time event or holiday is obtained by calculating the impact of the holiday or important time event on the load. In the Prophet model, the user can define the important time event or holiday and give the impact of the important time event or holiday on the load, such as specifying an annual promotional activity.

[0078] The expression for calculating server load at any given time is:

[0079]

[0080] in, For CPU load, For memory load, For disk I / O load, This refers to the CPU's weighting coefficient. For memory weighting coefficients, This represents the weighting factor for disk I / O.

[0081] The expression for calculating CPU load is:

[0082]

[0083] in, The current CPU utilization rate, This represents the baseline utilization of the CPU.

[0084] The expression for calculating memory load is:

[0085]

[0086] in, This represents the current memory usage. This represents the baseline memory utilization rate.

[0087] The expression for calculating disk I / O load is:

[0088]

[0089] in, For the current I / O rate, The reference rate for I / O;

[0090] The baseline CPU utilization, current CPU utilization, baseline memory utilization, current memory utilization, current I / O rate, and baseline I / O rate can all be achieved by deploying corresponding shell scripts on the payment system. Used to adjust the impact of CPU on server load. Used to adjust the impact of memory on server load. Used to adjust the impact of I / O rate on server load.

[0091] By accurately capturing the long-term trends, periodic fluctuations, and impacts of significant time events in load data, reasonable predictions of future loads can be made, and finally, appropriate nodes can be selected to handle higher loads.

[0092] S2: Obtain the resource parameters of the distributed database and construct the distributed database resource occupancy vector based on the resource parameters of the distributed database;

[0093] Monitor and obtain the resource parameters of the distributed database, including CPU utilization, memory utilization, disk I / O utilization, and network traffic.

[0094] A database resource usage vector is constructed based on the database's resource parameters. The expression for calculating the resource usage vector of a distributed database is as follows:

[0095]

[0096] in, for The resource consumption vector of a distributed database at any given time. for CPU utilization at any time for Real-time memory usage for Disk I / O utilization at any time for Real-time network traffic.

[0097] The resource parameters of the distributed database are used as input features for the Isolation Forest algorithm, and the usage status of each resource affects the calculation of the anomaly score and disaster recovery decision.

[0098] S3: Construct an isolation tree based on the distributed database resource usage vector, and calculate the anomaly score based on the isolation tree;

[0099] The process of constructing an isolation tree includes:

[0100] exist Randomly select a point within the range of values ​​as the dividing point;

[0101] like If the value of is greater than the value of the dividing point, then The right subtree;

[0102] like If the value of is less than the value of the dividing point, then Left subtree;

[0103] like The value of is equal to the value of the dividing point, then Main tree;

[0104] In the left subtree or the right subtree Then, randomly select a point within the range of values ​​as the dividing point, and repeat the above process until the range of values ​​has only one value point.

[0105] The Isolation Forest algorithm uses distributed database resource occupancy vectors to calculate anomaly scores;

[0106] The expression for calculating the abnormal score is:

[0107]

[0108] in, for Outlier scores at time points To isolate the tree Path length, Based on sample size normalized length, for The average value,

[0109] If a parameter of a distributed database resource (such as CPU utilization) fluctuates extremely high within a short period of time, the Isolation Forest will quickly isolate that point, resulting in a high outlier score.

[0110] S4: Set dynamic thresholds based on abnormal scores;

[0111] To better reflect actual resource usage, dynamic thresholds can be dynamically adjusted according to fluctuations in resource load. Historical data is used to calculate the historical average anomaly score and standard deviation of each resource parameter. The expression for calculating the dynamic threshold is:

[0112]

[0113] in, for The dynamic threshold at any given time. The historical average outlier score. As a regulatory factor, is the standard deviation of outlier scores.

[0114] S5: Identify abnormal nodes based on the abnormal score and dynamic threshold, and reallocate resources to the abnormal nodes;

[0115] If the abnormal score is less than or equal to the dynamic threshold, it is considered a normal node.

[0116] If the abnormal score is greater than the dynamic threshold, it is an abnormal node.

[0117] Set the allocation coefficient, and distribute part of the load from the abnormal node to the normal node according to the allocation coefficient.

[0118] The mathematical expression for distributing a portion of the load from abnormal nodes to normal nodes based on the allocation coefficient is as follows:

[0119]

[0120] in, After adjustment Node load, Before adjustment Node load, For allocation coefficients, for Node load.

[0121] Allocation coefficient Control the extent of resource transfer to prevent nodes from being overwhelmed by excessive load transfer.

[0122] In some specific embodiments of the present invention, the allocation coefficient The default setting is 50%. When a node crashes or other abnormal situation occurs, the allocation coefficient will be adjusted. Setting it to 100% will transfer all the load from the current node to healthy nodes. This ensures that the load on abnormal nodes is gradually reduced, preventing resource exhaustion or further deterioration.

[0123] S6: Repeat steps S2 to S5 to detect abnormal nodes at each time step. If a node has multiple abnormal scores that exceed the dynamic threshold, then isolate the node to ensure the stable operation of the distributed database.

[0124] If a node's anomaly score exceeds the dynamic threshold in multiple checks, the node's resource reallocation is abnormally frequent, potentially causing cluster instability. In this case, the node can be isolated and removed from the active node pool of the distributed database to ensure the overall normal operation of the distributed database.

[0125] like Figure 2 As shown, a third-party payment system is used to implement a third-party payment system disaster recovery method, including:

[0126] The user module allows users to register and log in to gain access to the payment system.

[0127] Users register to obtain an account, log in using their username and password, and are granted access after the system verifies their identity.

[0128] Users open the main interface of the payment system, click the "Register" button to enter the registration page. On the registration page, users need to enter the following identity information: the user's name or other identification information, and a valid mobile phone number to receive SMS verification codes.

[0129] The system calls the local mobile operator's SMS service interface to send an SMS verification code to the mobile phone number entered by the user. After receiving the verification code, the user enters it into the verification code input box of the payment system.

[0130] The system verifies the verification code to confirm its correctness and expiration. If verification fails, the user is prompted to obtain or re-enter the verification code. If the SMS verification code is successfully verified, the user needs to set a login password and a payment password. The login password is used for system login authentication, and the payment password is used for payment security verification during transactions. The user-entered passwords are encrypted using a specific encryption algorithm (such as AES) to ensure security during data transmission and storage. The encrypted password information is stored in a distributed database for subsequent authentication and payment verification.

[0131] After successful user registration, the user is returned to the main system interface and enters the username and password set during registration to log in. The system retrieves the corresponding user information from the database and encrypts the entered password. It then matches and verifies the password with the encrypted password stored in the distributed database. If the verification is successful, the system switches the user's status to an accessible state, allowing the user to enter the system interface and access the functions of other modules. If the verification fails, the system prompts the user to re-enter the password or retrieve it.

[0132] The QR code module generates corresponding payment QR codes during the transaction process, and users can complete payment or receipt operations by scanning the payment QR codes;

[0133] When a user initiates a transaction request, the payee clicks the "Generate QR Code" button through the payment system to request the generation of a QR code. The payment system generates a dynamic QR code based on the transaction information provided by the user (such as the payment amount and payee's account). The QR code information includes the following: transaction amount, payee information, and timestamp. To ensure transaction security, the QR code has a time limit and is only valid for three minutes after generation. After three minutes, the QR code will automatically expire, and the system will prompt that the QR code has expired and require regeneration.

[0134] The payer scans the QR code generated by the payee using a payment device. The payment system reads the information in the QR code and displays the payment amount, payee information, and other details on the payment interface. The user can then enter or confirm the transaction amount. Before the user confirms the payment, the system verifies the validity of the QR code. If the QR code has expired, the system will prompt "QR code has expired, please regenerate," and the user will need to scan a valid QR code again.

[0135] The transaction module is used by users to initiate transaction requests. The payment system generates corresponding transaction information based on the transaction requests and processes and transmits it securely.

[0136] The transaction process includes steps such as initiating a transaction, verifying the transaction, and transferring funds. The payment system uses encryption technology to ensure data security.

[0137] When a user initiates a transaction, the system requires the user to enter a transaction password to verify the transaction's legitimacy and the user's identity. The entered transaction password is encrypted using an encryption algorithm (such as RSA or AES) to ensure password security during transmission. Upon receiving the encrypted transaction password, the payment system decrypts and verifies it. If the transaction password is incorrect, the payment system displays "Incorrect transaction password" and prompts the user to re-enter it. After successful password verification, the payment system further checks the user's wallet account balance to determine if it meets the transaction requirements. If the user's account balance is insufficient, the system displays "Insufficient balance, transaction cannot be completed."

[0138] When the verification conditions are met, the payment system deducts the corresponding transaction amount from the payer's wallet. This deduction is recorded in a distributed database for subsequent auditing and financial reconciliation. Simultaneously, the payment system adds the corresponding amount to the recipient's wallet account and saves the transaction record in the billing module for easy access. The system uses encryption technology to ensure data security during fund transfers and prevents transaction data from being tampered with during transmission. After the transaction is completed, the system sends a transaction completion notification to both users, including the transaction amount, transaction time, and recipient / payer information.

[0139] The billing module generates a corresponding year, month, and day bill record after a user completes a transaction. Users can view and download the bill record.

[0140] After the transaction is completed, the payment system automatically generates a bill, which is stored in categories according to year, month, and day. Users can choose to view or download historical bills for convenient financial management.

[0141] After logging into the system, users can access the billing module and select the time range for querying bills, including the start and end times. The payment system retrieves bill records for the corresponding time period from the distributed database based on the user's selected time range and returns the query results. Each bill record includes detailed information such as transaction time, transaction amount, and transaction type (e.g., receipt or payment). The system also calculates the total transaction amount within the selected time range for the user's reference.

[0142] The system will automatically generate a monthly statement at the beginning or end of each month, summarizing all transaction records and total transaction amount for that month. The generated monthly statement will be automatically sent to the user's email address or system notification, and the user can view, download and save the statement records at any time.

[0143] The language module provides a multilingual system interface to address language differences, allowing users to switch the system language at any time as needed.

[0144] After a user clicks the "Switch Language" button on the payment system interface, a language selection menu will pop up, allowing the user to choose the desired language. Based on the user's selection, the payment system dynamically loads the corresponding language for the interface text, system prompts, and help information. This real-time language switching enhances the payment system's adaptability in multilingual environments, making it suitable for users with different language backgrounds and significantly improving the user experience.

[0145] In some specific embodiments of the present invention, the payment system supports Chinese, English, and French.

[0146] The disaster recovery module adopts a microservice architecture and a distributed database. In the microservice architecture, the Prophet model is used to predict the future load of each node in the distributed database and perform load balancing. In the distributed database, when a node fails, the Isolation Forest algorithm is used to isolate the node.

[0147] The future load of distributed database nodes is predicted by a time-series forecasting model, and the resource allocation of the distributed database is dynamically adjusted according to the future load.

[0148] Obtain the resource parameters of the distributed database, and construct the distributed database resource usage vector based on the resource parameters;

[0149] An isolation tree is constructed based on the distributed database resource usage vector, and anomaly scores are calculated based on the isolation tree.

[0150] Set dynamic thresholds based on abnormal scores;

[0151] Abnormal nodes are identified based on their abnormal scores and dynamic thresholds, and resources are reallocated to these abnormal nodes.

[0152] Detect abnormal nodes at each time point. If a node has multiple abnormal scores that exceed the dynamic threshold, then isolate the node to ensure the stable operation of the distributed database.

[0153] The user module calls the information of the QR code module, and the QR code module returns QR code information to the user module;

[0154] The user module calls the transaction module information, and the transaction module returns transaction information to the user module.

[0155] The user module calls the billing module information;

[0156] The transaction module returns transaction information to the billing module;

[0157] The user module, the QR code module, the transaction module, and the billing module are all connected to the language module;

[0158] The user module, the QR code module, the transaction module, and the billing module are all connected to the disaster recovery module.

[0159] The payment system of this invention adopts a microservice architecture, with each functional module being independent and loosely coupled. Modules are deployed on different clusters, improving the scalability and stability of the payment system. Each service module is configured with multiple instances, distributed across different servers or virtual machines. The Prophet algorithm is also used to predict the load, preventing a single point from bearing too much load.

[0160] User information, transaction data, and billing records are stored in a distributed database, employing a "one primary, two backup" model. When a node or database fails, the payment system detects service unavailability using the Isolation Forest algorithm and quickly activates a backup node. The backup node automatically takes over the business requests from the failed node, ensuring uninterrupted user access and distributing requests to available server nodes, thus improving the payment system's processing efficiency and fault tolerance.

[0161] This invention addresses the language compatibility issues of existing payment systems by integrating multilingual support, enhancing user experience, providing suitable payment method options for local users, and improving the user-friendliness and ease of use of the payment system. Through multiple verification and encryption technologies, it ensures the security of user transaction passwords and financial information, avoiding the risk of payment data leakage during transmission.

[0162] By combining a distributed database and a microservice architecture, the system's high availability and disaster recovery capabilities are enhanced. The Prophet algorithm is used to predict the load of each node, enabling timely and effective load balancing to ensure the reliable operation of the microservice architecture. At the same time, the Isolation Forest algorithm is used to detect the availability of each node in the distributed database, allowing for timely isolation of abnormal nodes and ensuring that the server nodes in the distributed database can continuously serve the payment system.

[0163] 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 disaster recovery method for a third-party payment system, characterized in that, include: S1: Predict the future load of distributed database nodes through a time-series forecasting model, and dynamically adjust the resource allocation of the distributed database according to the future load to ensure the reliable operation of the microservice architecture; The time-series prediction model is the Prophet model, and the expression for calculating the future load of the distributed database nodes is: in, for Future load at each time point for The long-term trend function of load at any given time. for The periodic variation function of the load at any given time. This is a function representing the impact of holidays or important events on the load. for Real-time server load By defining holidays or important time events, the impact of these events on the load is obtained. The calculation expression for the function of the impact of holidays or important time events on the load is as follows: in, For holidays or important events, for The extent of the impact on the load, For indicator functions; The Prophet model calculates the impact of holidays or important time events on the load to obtain short-term peaks or troughs caused by these events. In the Prophet model, users define important time events or holidays and specify their impact on the load. The expression for calculating server load at any given time is: in, For CPU load, For memory load, For disk I / O load, This refers to the CPU's weighting coefficient. For memory weighting coefficients, This represents the weighting factor for disk I / O. S2: Obtain the resource parameters of the distributed database, and construct a distributed database resource occupancy vector based on these parameters. Use the distributed database resource parameters as input features for the Isolation Forest algorithm. The usage status of each resource affects the calculation of the anomaly score and disaster recovery decision. The expression for calculating the resource consumption vector of a distributed database is: in, for The resource consumption vector of a distributed database at any given time. for CPU usage at any time for Real-time memory usage for Disk I / O utilization rate at any time for Real-time network traffic; S3: Construct an isolation tree based on the distributed database resource usage vector, and calculate the anomaly score based on the isolation tree; S4: Set dynamic thresholds based on abnormal scores; S5: Identify abnormal nodes based on the abnormal score and dynamic threshold, and reallocate resources to the abnormal nodes; S6: Repeat steps S2 to S5 to detect abnormal nodes at each time point. If a node has multiple abnormal scores that exceed the dynamic threshold, then the node is isolated. When a node or database fails, the payment system detects service unavailability through the IsolationForest algorithm and quickly activates a backup node to ensure the stable operation of the distributed database.

2. The disaster recovery method for a third-party payment system according to claim 1, characterized in that, By defining multiple inflection points, the slope of the long-term load change trend changes at each inflection point. The long-term load change trend function can be obtained by manually setting the number of inflection points or by automatically selecting the number of inflection points through the Prophet model. The periodic variation function of the load is obtained by fitting the sine and cosine waveforms of multiple periods of Fourier series. By defining holidays or important time events, the impact of holidays or important time events on the load is calculated, and the impact function of holidays or important time events on the load is obtained.

3. The disaster recovery method for a third-party payment system according to claim 1, characterized in that, Monitor and obtain the resource parameters of the distributed database, including CPU utilization, memory utilization, disk I / O utilization, and network traffic.

4. The disaster recovery method for a third-party payment system according to claim 1, characterized in that, The process of constructing an isolation tree includes: exist Randomly select a point within the range of values ​​as the dividing point; like If the value of is greater than the value of the dividing point, then The right subtree; like If the value of is less than the value of the dividing point, then Left subtree; like The value of is equal to the value of the dividing point, then Main tree; In the left subtree or the right subtree Then, randomly select a point within the range of values ​​as the dividing point, and repeat the above process until the range of values ​​has only one value point.

5. A disaster recovery method for a third-party payment system according to claim 4, characterized in that, The expression for calculating the abnormal score is: in, for outlier scores at time points To isolate the tree Path length, Based on sample size normalized length, for The average value.

6. A disaster recovery method for a third-party payment system according to claim 1, characterized in that, Using historical data, the historical average anomaly score and standard deviation of the anomaly score for each resource parameter are calculated. The expression for calculating the dynamic threshold is as follows: in, for The dynamic threshold at any given time. The historical average outlier score. As a regulatory factor, is the standard deviation of outlier scores.

7. A disaster recovery method for a third-party payment system according to claim 1, characterized in that, The S5 steps include: If the abnormal score is less than or equal to the dynamic threshold, it is considered a normal node. If the abnormal score is greater than the dynamic threshold, it is an abnormal node. Set the allocation coefficient, and distribute part of the load from the abnormal node to the normal node according to the allocation coefficient.

8. A third-party payment system, characterized in that, To implement a third-party payment system disaster recovery method as described in any one of claims 1 to 7, comprising: The language module provides a multilingual system interface to address language differences, allowing users to switch the system language at any time as needed. The disaster recovery module adopts a microservice architecture and a distributed database. In the microservice architecture, the Prophet model is used to predict the future load of each node in the distributed database and perform load balancing. In the distributed database, when a node fails, the Isolation Forest algorithm is used to isolate the node. The future load of distributed database nodes is predicted by a time-series forecasting model, and the resource allocation of the distributed database is dynamically adjusted according to the future load. Obtain the resource parameters of the distributed database, and construct the distributed database resource usage vector based on the resource parameters; An isolation tree is constructed based on the distributed database resource usage vector, and anomaly scores are calculated based on the isolation tree. Set dynamic thresholds based on abnormal scores; Abnormal nodes are identified based on their abnormal scores and dynamic thresholds, and resources are reallocated to these abnormal nodes. Detect abnormal nodes at each time point. If a node has multiple abnormal scores exceeding a dynamic threshold, then isolate the node to ensure the stable operation of the distributed database.

Citation Information

Patent Citations

  • Asset data acquisition method based on Internet of Things

    CN119254791A

  • Resource allocation method for cloud server, and scheduling apparatus

    WO2024213010A1