Disaster recovery method for third-party payment system and third-party payment system

Abstract

The invention relates to the technical field of payment system disaster recovery, and provides a third-party payment system disaster recovery method and a third-party payment system.The disaster recovery method comprises the steps that future loads of distributed database nodes are predicted through a time sequence prediction model, and resource allocation is dynamically adjusted; constructing a distributed database resource occupation vector according to the resource parameters of the distributed database; calculating an abnormal score of each moment according to the isolation tree; judging an abnormal node according to the abnormal score and a dynamic threshold value, and carrying out resource redistribution on the abnormal node; and if the multiple abnormal scores of the node are greater than the dynamic threshold, the node is isolated, and stable operation of the database is ensured. According to the invention, through combination of the distributed database and the micro-service architecture, the high availability and disaster recovery capability of the system are enhanced, reliable operation of the micro-service architecture is ensured by adopting the time sequence prediction model, and abnormal nodes are isolated in time through the Isolation Forest algorithm to maintain the stability of the system.

Description

Technical Field

[0001] The present invention relates to the technical field of payment system disaster recovery, and in particular to a third-party payment system disaster recovery method and a third-party payment system. Background Art

[0002] At present, there are differences in language and usage habits in the third-party payment system in terms of electronic payment and mobile payment, and users have a poor experience when using it. During the operation of the payment system, due to the uneven resource usage, some nodes are prone to high loads while other nodes are low loads, causing the payment system to run slowly or even crash. When a node fails, the node load is unbalanced and the system goes down or crashes, making the payment system unable to operate normally. In order to ensure the stability and reliability of the payment system, the disaster recovery problem of the payment system needs to be solved urgently. Summary of the invention

[0003] The present invention aims to solve at least one of the technical problems existing in the related art. To this end, the present invention provides a third-party payment system disaster recovery method and a third-party payment system. The present invention predicts future loads through a time series prediction (Prophet) algorithm to avoid a single point bearing too much load. When a node or database fails, the system will detect that the service is unavailable through the isolation forest algorithm and quickly enable the backup node. The backup node automatically takes over the service request of the failed node to ensure that the normal use of the user is not affected, and distributes the request to the available server nodes to improve the processing efficiency and fault tolerance of the system.

[0004] The present invention provides a third-party payment system disaster recovery method, comprising: S1: Predict the future load of distributed database nodes through the time series prediction model, and dynamically adjust the resource allocation of the distributed database according to the future load; S2: Obtain resource parameters of the distributed database, and construct a distributed database resource occupancy vector according to the resource parameters of the distributed database; S3: Build an isolation tree based on the distributed database resource occupancy vector and calculate the anomaly score based on the isolation tree; S4: Set dynamic thresholds based on anomaly scores; S5: Determine abnormal nodes based on anomaly scores and dynamic thresholds, and reallocate resources to abnormal nodes; S6: Repeat steps S2 to S5 to detect abnormal nodes at each moment. If a node has an abnormal score greater than the dynamic threshold multiple times, the node is isolated to ensure the stable operation of the distributed database.

[0005] Furthermore, in step S1, the time series prediction model is a Prophet model, and the calculation expression of the future load of the distributed database node is: in, for The future load of the node at time instant, for The long-term trend function of the moment load, for The periodic variation function of the load at each moment, is the impact function of holidays or important time events on load, for The server load at the moment.

[0006] Furthermore, by defining multiple inflection points, the slope of the long-term change trend of the load changes at each inflection point, and by manually setting the number of inflection points or automatically selecting the number of inflection points through the Prophet model, the long-term change trend function of the load is obtained; The periodic variation of the load is fitted by using sine waveforms and cosine waveforms of multiple periods of Fourier series to obtain a periodic variation function of the load; By defining holidays or important time events, calculating the impact of holidays or important time events on the load, and obtaining the impact function of holidays or important time events on the load; The calculation expression of server load at a certain moment is: in, is the CPU load, is the memory load, is the disk I / O load, is the CPU weight coefficient, is the memory weight coefficient, The weight coefficient of disk I / O.

[0007] Furthermore, resource parameters of the distributed database are monitored and obtained, and the resource parameters of the distributed database include CPU usage, memory usage, disk I / O usage, and network traffic.

[0008] Furthermore, a distributed database resource occupancy vector is constructed according to the resource parameters of the distributed database. The calculation expression of the distributed database resource occupancy vector is: in, for The resource occupancy vector of the distributed database at each moment, for CPU usage at all times, for Memory usage at all times, for Disk I / O usage at the moment, for Network traffic at all times.

[0009] Furthermore, the isolation tree construction process includes: exist Randomly select a point within the value range of as the split point; like If the value of is greater than the split point, is the right subtree; like The value of is less than the split point value, then is the left subtree; like The value of is equal to the value of the split point, then The main tree; In the left or right subtree The value range then randomly selects a point as the split point, and repeats the above process until there is only one value point in the value range.

[0010] Furthermore, the calculation expression of the anomaly score is: in, for The anomaly score at the time, To isolate the tree The path length, Based on sample size The normalized length of for The average value of .

[0011] Furthermore, the historical data is used to calculate the historical average anomaly score and the standard deviation of the anomaly score for each resource parameter. The calculation expression of the dynamic threshold is: in, for The dynamic threshold at the moment, is the historical average anomaly score, As a regulatory factor, is the standard deviation of the anomaly score.

[0012] Furthermore, step S5 includes: If the anomaly score is less than or equal to the dynamic threshold, it is a normal node. If the anomaly score is greater than the dynamic threshold, it is an abnormal node. A distribution coefficient is set, and part of the load of the abnormal node is diverted to the normal node according to the distribution coefficient.

[0013] A third-party payment system, used to execute the above-mentioned third-party payment system disaster recovery method, comprising: Language module, which provides a multi-language system interface to address language differences, and users can switch the system language at any time as needed; Disaster recovery module, which adopts microservice architecture and distributed database. In the microservice architecture, the Prophet model is used to predict the future load of each node of 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; Predict the future load of distributed database nodes through the time series prediction model, and dynamically adjust the resource allocation of the distributed database according to the future load; Obtain resource parameters of the distributed database, and construct a distributed database resource occupancy vector according to the resource parameters of the distributed database; Build an isolation tree based on the distributed database resource occupancy vector, and calculate the anomaly score based on the isolation tree; Set dynamic thresholds based on anomaly scores; Determine abnormal nodes based on abnormal scores and dynamic thresholds, and reallocate resources to abnormal nodes; Detect abnormal nodes at each moment. If a node has multiple abnormal scores greater than the dynamic threshold, the node will be isolated to ensure the stable operation of the distributed database.

[0014] The above one or more technical solutions in the embodiments of the present invention have at least one of the following technical effects: The present invention solves the language adaptability of the existing payment system by integrating multi-language support, improves the user experience, provides payment method options suitable for local users, and improves the user friendliness and ease of use of the payment system. Through multiple verification and encryption technologies, the security of user transaction passwords and financial information is guaranteed, avoiding the risk of leakage of payment data during transmission.

[0015] Through the combination of distributed database and microservice architecture, the high availability and disaster recovery capabilities of the system are enhanced. The Prophet algorithm is used to predict the load conditions of each node, which can promptly and effectively balance the excessive load conditions and ensure the reliable operation of the microservice architecture. At the same time, the Isolation Forest algorithm is used to detect whether each node in the distributed database is available, and abnormal nodes can be isolated in time to ensure that the server nodes in the distributed database can always serve the payment system.

[0016] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 The present invention is a flowchart of a third-party payment system disaster recovery method.

[0019] Figure 2 It is a structural schematic diagram of a third-party payment system provided by the present invention. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical scheme and advantages of the present invention clearer, the technical scheme in the present invention will be clearly and completely described below. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present invention. The following embodiments are used to illustrate the present invention, but cannot be used to limit the scope of the present invention.

[0021] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the embodiment of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0022] Combine the following Figure 1 to Figure 2 The present invention describes a third-party payment system disaster recovery method and a third-party payment system.

[0023] like Figure 1 As shown, a third-party payment system disaster recovery method includes: S1: Predict the future load of each node of the distributed database through the time series prediction model, and dynamically adjust the resource allocation of the distributed database according to the future load; The time series prediction model is the Prophet model, and the calculation expression of the future load of the distributed database node is: in, for The future load of the node at time instant, for The long-term trend function of the moment load, for The periodic variation function of the load at each moment, is the impact function of holidays or important time events on load, for The server load at the moment.

[0024] The Prophet model uses a piecewise linear model to describe the long-term change trend of the load. It defines multiple "changepoints" and allows the slope of the trend to change at each inflection point. The calculation expression of the long-term change trend function of the moment load is: in, The initial slope is the initial trend or growth rate in the payment system (such as the basic growth rate of transactions). Stored as a constant or configuration variable, such as in a server's environment or configuration file; The change in the slope of the trend at each inflection point indicates the adjustment of the trend over time (for example, due to seasonal changes or sudden increases in trading volume). Modeled as a function of time or updated based on specific inflection points, Can be adjusted periodically.

[0025] Temporal functions are used to capture periodic patterns in load, such as daily load peaks (e.g., increased load during peak hours). Prophet models temporality through Fourier series, fitting the period of the load data with multiple cycles of sine and cosine waveforms. The calculation expression of the periodic change function of the load at each moment is: in, is the order of the Fourier series, For the The coefficient of the order cosine term of the order Fourier series, For the The coefficient of the order sine term of the order Fourier series, To pay for the system work cycle; In some specific embodiments of the present invention, by setting appropriate , which can accurately capture the temporal fluctuations of the load.

[0026] By defining holidays or important time events, you can obtain the impact of holidays or important time events on the load.

[0027] The calculation expression of the impact function of holidays or important time events on load is: in, For holidays or important time events, for The magnitude of the impact on the load, is the indicator function.

[0028] The appropriate value can be selected by observing the impact of holidays on the payment system load. For belong The value is 1 when it is set, otherwise the value is 0.

[0029] In some specific embodiments of the present invention, the short-term peak or valley value in the load caused by important time events or holidays is obtained by calculating the impact of holidays or important time events on the load. In the Prophet model, the user can define important time events or holidays and give the impact of important time events or holidays on the load, such as specifying annual promotional activities.

[0030] The calculation expression of server load at a certain moment is: in, is the CPU load, is the memory load, is the disk I / O load, is the CPU weight coefficient, is the memory weight coefficient, is the weight coefficient of disk I / O; The calculation expression of CPU load is: in, is the current CPU usage, is the baseline CPU usage; The calculation expression of memory load is: in, is the current memory usage, is the baseline usage of memory; The calculation expression of disk I / O load is: in, is the current I / O rate, is the base rate of I / O; The CPU baseline usage, current CPU usage, memory baseline usage, current memory usage, current I / O rate, and I / O baseline 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. By accurately capturing the long-term trends, periodic fluctuations, and the impact of important time events in load data, reasonable predictions of future loads can be made, and finally appropriate nodes can be selected to handle higher loads.

[0031] S2: Obtain resource parameters of the distributed database, and construct a distributed database resource occupancy vector according to the resource parameters of the distributed database; Monitor and obtain resource parameters of the distributed database, wherein the resource parameters of the distributed database include CPU usage, memory usage, disk I / O usage, and network traffic.

[0032] The database resource occupancy vector is constructed according to the database resource parameters. The calculation expression of the resource occupancy vector of the distributed database is: in, for The resource occupancy vector of the distributed database at each moment, for CPU usage at all times, for Memory usage at all times, for Disk I / O usage at the moment, for Network traffic at all times.

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

[0034] S3: Build an isolation tree based on the distributed database resource occupancy vector and calculate the anomaly score based on the isolation tree; The isolation tree construction process includes: exist Randomly select a point within the value range of as the split point; like If the value of is greater than the split point, is the right subtree; like The value of is less than the split point value, then is the left subtree; like The value of is equal to the value of the split point, then The main tree; In the left or right subtree The value range then randomly selects a point as the split point, and repeats the above process until there is only one value point in the value range.

[0035] The Isolation Forest algorithm uses the distributed database resource occupancy vector to calculate the anomaly score; The calculation expression of the anomaly score is: in, for The anomaly score at the time, To isolate the tree The path length, Based on sample size The normalized length of for The average value of If a parameter of a distributed database resource (such as CPU usage) fluctuates extremely rapidly in a short period of time, the point will be quickly isolated in Isolation Forest, resulting in a higher anomaly score.

[0036] S4: Set dynamic thresholds based on anomaly scores; In order to better fit the actual usage of resources, the dynamic threshold can be dynamically adjusted as the load of resource usage fluctuates. The historical average anomaly score and standard deviation of the anomaly score of each resource parameter are calculated using historical data. The calculation expression of the dynamic threshold is: in, for The dynamic threshold at the moment, is the historical average anomaly score, As a regulatory factor, is the standard deviation of the anomaly score.

[0037] S5: Determine abnormal nodes based on anomaly scores and dynamic thresholds, and reallocate resources to abnormal nodes; If the anomaly score is less than or equal to the dynamic threshold, it is a normal node. If the anomaly score is greater than the dynamic threshold, it is an abnormal node. A distribution coefficient is set, and part of the load of the abnormal node is diverted to the normal node according to the distribution coefficient.

[0038] The mathematical expression for distributing part of the load of abnormal nodes to normal nodes according to the distribution coefficient is: in, After adjustment The load of the node, Before adjustment The load of the node, is the distribution coefficient, for The load of the node.

[0039] Partition coefficient Control the magnitude of resource transfer to prevent nodes from being overwhelmed by excessive load transfer.

[0040] In some specific embodiments of the present invention, the partition coefficient The default setting is 50%. When a node goes down or experiences other abnormal conditions, the allocation coefficient Set to 100%, and the load of the current node will be completely transferred to the healthy node. This method can ensure that the abnormal node gradually reduces the load and avoids resource exhaustion or further deterioration.

[0041] S6: Repeat steps S2 to S5 to detect abnormal nodes at each moment. If a node has an abnormal score greater than the dynamic threshold multiple times, the node is isolated to ensure the stable operation of the distributed database.

[0042] If the anomaly score of a node exceeds the dynamic threshold in multiple tests, the resource reallocation of the node is abnormally frequent, which may cause cluster instability. In this case, the node can be isolated and removed from the active node pool of the distributed database to ensure the normal operation of the distributed database as a whole.

[0043] like Figure 2 As shown, a third-party payment system is used to implement a third-party payment system disaster recovery method, including: A user module, through which users register and log in to obtain access to the payment system; The user obtains an account by registering, logs in with a username and password, and the system allows the system to authenticate the identity; The user opens the main interface of the payment system and clicks the "Register" button to enter the registration page. On the registration page, the user needs to enter the following identity information: the user's name or other identity information, and a valid mobile phone number in order to receive a text message verification code; The system calls the SMS service interface of the local mobile operator and sends a 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; The system verifies the verification code to confirm whether the entered verification code is correct and has not expired; if the verification fails, the user is prompted to obtain the verification code again or re-enter it. 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 identity authentication, and the payment password is used for payment security verification during the transaction process. The password entered by the user is encrypted using a specific encryption algorithm (such as AES, etc.) to ensure security during data transmission and storage. The encrypted password information is stored in a distributed database for subsequent identity authentication and payment verification.

[0044] After the user successfully registers, he returns to the main interface of the system and enters the user name and password set during registration to log in. The system retrieves the corresponding user information from the database, encrypts the entered password, and then matches and verifies it with the encrypted password stored in the distributed database. If the verification is successful, the system switches the user's status to accessible, allowing him 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 the password.

[0045] A QR code module, which generates a corresponding payment QR code during a transaction, and the user completes the payment or collection operation by scanning the payment QR code; When a user initiates a transaction request, the payee clicks the "Generate Payment Code" button through the payment system to initiate a request to generate a QR code to the payment system. The payment system generates a dynamic payment QR code based on the transaction information provided by the user (such as the payment amount, the payee account, etc.). The QR code information includes the following: transaction amount, payee information, timestamp, etc. In order to ensure the security of the transaction, the QR code is set with a time limit and is only valid within 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 requires regeneration.

[0046] The payer uses the payment device to scan the QR code generated by the payee. The payment system reads the information in the QR code and displays the payment amount, payee information and other content on the payment interface. The user can enter or confirm the transaction amount. Before the user confirms the payment, the system will verify the validity of the QR code. If the QR code has expired, the system will prompt "The QR code has expired, please regenerate it", and the user needs to rescan the valid QR code.

[0047] Transaction module, which is used for users to initiate transaction requests. The payment system generates corresponding transaction information based on the transaction requests and performs secure processing and transmission; The transaction process includes steps such as initiating a transaction, transaction verification, and fund transfer. The payment system uses encryption technology to ensure data security.

[0048] When a user initiates a transaction, the system requires the user to enter a transaction password to verify the legitimacy of the transaction and the user's identity. The transaction password entered by the user will be encrypted using an encryption algorithm (such as RSA or AES, etc.) to ensure the security of the password during transmission. After receiving the encrypted transaction password, the payment system will decrypt and verify it. If the transaction password is incorrect, the payment system will prompt "Transaction password error" and require re-entry; after the transaction password is successfully verified, the payment system will further check the balance of the user's wallet account to determine whether it meets the amount required for the transaction; if the balance in the user's account is insufficient, the system will prompt "Insufficient balance, unable to complete the transaction."

[0049] When the verification conditions are met, the payment system will deduct the corresponding transaction amount from the payer's wallet, and the deduction operation will be recorded in the distributed database for subsequent audits and financial reconciliations; at the same time, the payment system will add the corresponding amount to the payee's wallet account and save the transaction record in the bill module for users to review at any time. The system uses encryption technology to ensure data security during fund transfers and prevent 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, payee / payer information, etc.

[0050] The billing module, when the user completes the transaction, the payment system will generate the corresponding year-month-day billing record, and the user can view and download the billing record; After the transaction is completed, the payment system automatically generates a bill and stores it by year, month, and day. Users can choose to view or download historical bills to facilitate financial management. After the user logs in to the system, he / she can enter the bill module and select the time range for querying the bill, including the start time and end time. The payment system retrieves the bill records of the corresponding time period in the distributed database according to the time range selected by the user and returns the query results; each bill record includes detailed information such as transaction time, transaction amount, transaction type (such as collection or payment), etc. The system also counts the total transaction amount within the selected time range for the user's reference; The system will automatically generate a monthly bill at the beginning or end of each month, summarizing all transaction records and total transaction amounts for that month; the generated monthly bill will be automatically sent to the user's email or system notification, and the user can view, download and save the bill records at any time.

[0051] Language module, which provides a multi-language system interface to address language differences, and users can switch the system language at any time as needed; After the user clicks the "Language Switch" button on the payment system interface, the payment system will pop up a language selection menu, and the user can select the language to be switched; the payment system dynamically loads the interface text, system prompts and help information in the corresponding language according to the language selected by the user. The real-time switching language support improves the adaptability of the payment system in a multilingual environment, is suitable for users with different language backgrounds, and greatly improves the user experience.

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

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

[0054] Predict the future load of distributed database nodes through the time series prediction model, and dynamically adjust the resource allocation of the distributed database according to the future load; Obtain resource parameters of the distributed database, and construct a distributed database resource occupancy vector according to the resource parameters of the distributed database; Build an isolation tree based on the distributed database resource occupancy vector, and calculate the anomaly score based on the isolation tree; Set dynamic thresholds based on anomaly scores; Determine abnormal nodes based on abnormal scores and dynamic thresholds, and reallocate resources to abnormal nodes; Detect abnormal nodes at each moment. If a node has multiple abnormal scores greater than the dynamic threshold, isolate the node to ensure the stable operation of the distributed database. The user module calls the two-dimensional code module information, and the two-dimensional code module returns the two-dimensional code information to the user module; The user module calls the transaction module information, and the transaction module returns transaction information to the user module; The user module calls the bill module information; The transaction module returns the transaction information to the bill module; The user module, the QR code module, the transaction module, and the bill module are all connected to the language module; The user module, the QR code module, the transaction module, and the bill module are all connected to the disaster recovery module.

[0055] The payment system of the present invention adopts a microservice architecture, each functional module is independent of each other, has low coupling, and the modules are deployed on different clusters to improve the scalability and stability of the payment system. Each service module is configured with multiple instances, which are distributed on different servers or virtual machines. At the same time, the Prophet algorithm is used to predict the load to avoid the situation where a single point bears too much load.

[0056] User information, transaction data and bill records are stored in a distributed database, using a "one master and two backup" backup mode. When a node or database fails, the payment system will detect that the service is unavailable through the Isolation Forest algorithm and quickly enable the backup node. The backup node automatically takes over the business requests of the failed node to ensure that the normal use of users is not affected, and distributes the requests to available server nodes, improving the processing efficiency and fault tolerance of the payment system.

[0057] The present invention solves the language adaptability of the existing payment system by integrating multi-language support, improves the user experience, provides payment method options suitable for local users, and improves the user friendliness and ease of use of the payment system. Through multiple verification and encryption technologies, the security of user transaction passwords and financial information is guaranteed, avoiding the risk of leakage of payment data during transmission.

[0058] Through the combination of distributed database and microservice architecture, the high availability and disaster recovery capabilities of the system are enhanced. The Prophet algorithm is used to predict the load conditions of each node, which can promptly and effectively balance the excessive load conditions and ensure the reliable operation of the microservice architecture. At the same time, the Isolation Forest algorithm is used to detect whether each node in the distributed database is available, and abnormal nodes can be isolated in time to ensure that the server nodes in the distributed database can always serve the payment system.

[0059] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A third-party payment system disaster recovery method, characterized in that: include: S1: Predict the future load of distributed database nodes through the time series prediction model, and dynamically adjust the resource allocation of the distributed database according to the future load; S2: Obtain resource parameters of the distributed database, and construct a distributed database resource occupancy vector according to the resource parameters of the distributed database; S3: Build an isolation tree based on the distributed database resource occupancy vector and calculate the anomaly score based on the isolation tree; S4: Set dynamic thresholds based on anomaly scores; S5: Determine abnormal nodes based on anomaly scores and dynamic thresholds, and reallocate resources to abnormal nodes; S6: Repeat steps S2 to S5 to detect abnormal nodes at each moment. If a node has an abnormal score greater than the dynamic threshold multiple times, the node is isolated to ensure the stable operation of the distributed database.

2. A third-party payment system disaster recovery method according to claim 1, characterized in that: In step S1, the time series prediction model is the Prophet model, and the calculation expression of the future load of the distributed database node is: in, for The future load of the node at time instant, for The long-term trend function of the moment load, for The periodic variation function of the load at each moment, is the impact function of holidays or important time events on load, for The server load at the moment.

3. A third-party payment system disaster recovery method according to claim 2, characterized in that: By defining multiple inflection points, the slope of the long-term change trend of the load changes at each inflection point, and by manually setting the number of inflection points or automatically selecting the number of inflection points through the Prophet model, the long-term change trend function of the load is obtained; The periodic variation of the load is fitted by using sine waveforms and cosine waveforms of multiple periods of Fourier series to obtain a periodic variation function of the load; By defining holidays or important time events, calculating the impact of holidays or important time events on the load, and obtaining the impact function of holidays or important time events on the load; The calculation expression of server load at a certain moment is: in, is the CPU load, is the memory load, is the disk I / O load, is the weight coefficient of the CPU, is the memory weight coefficient, The weight coefficient of disk I / O.

4. A third-party payment system disaster recovery method according to claim 1, characterized in that: Monitor and obtain resource parameters of the distributed database, wherein the resource parameters of the distributed database include CPU usage, memory usage, disk I / O usage, and network traffic.

5. A third-party payment system disaster recovery method according to claim 1, characterized in that: The distributed database resource occupancy vector is constructed according to the resource parameters of the distributed database. The calculation expression of the distributed database resource occupancy vector is: in, for Resource occupancy vector of the distributed database at each moment, for CPU usage at all times, for Memory usage at all times, for Disk I / O usage at the moment, for Network traffic at all times.

6. A third-party payment system disaster recovery method according to claim 5, characterized in that: The isolation tree construction process includes: exist Randomly select a point within the value range of as the split point; like If the value of is greater than the split point, is the right subtree; like The value of is less than the split point value, then is the left subtree; like The value of is equal to the value of the split point, then The main tree; In the left or right subtree The value range then randomly selects a point as the split point, and repeats the above process until there is only one value point in the value range.

7. A third-party payment system disaster recovery method according to claim 6, characterized in that: The calculation expression of the anomaly score is: in, for The anomaly score at the time, To isolate the tree The path length, Based on sample size The normalized length of for The average value of .

8. A third-party payment system disaster recovery method according to claim 1, characterized in that: The historical average anomaly score and standard deviation of the anomaly score of each resource parameter are calculated using historical data. The calculation expression of the dynamic threshold is: in, for The dynamic threshold at the moment, is the historical average anomaly score, As a regulatory factor, is the standard deviation of the anomaly score.

9. A third-party payment system disaster recovery method according to claim 1, characterized in that: Step S5 includes: If the anomaly score is less than or equal to the dynamic threshold, it is a normal node. If the anomaly score is greater than the dynamic threshold, it is an abnormal node. A distribution coefficient is set, and part of the load of the abnormal node is diverted to the normal node according to the distribution coefficient.

10. A third-party payment system, characterized in that: A method for performing a third-party payment system disaster recovery method as claimed in any one of claims 1 to 9, comprising: Language module, which provides a multi-language system interface to address language differences, and users can switch the system language at any time as needed; Disaster recovery module, which adopts microservice architecture and distributed database. In the microservice architecture, the Prophet model is used to predict the future load of each node of 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; Predict the future load of distributed database nodes through the time series prediction model, and dynamically adjust the resource allocation of the distributed database according to the future load; Obtain resource parameters of the distributed database, and construct a distributed database resource occupancy vector according to the resource parameters of the distributed database; Build an isolation tree based on the distributed database resource occupancy vector, and calculate the anomaly score based on the isolation tree; Set dynamic thresholds based on anomaly scores; Identify abnormal nodes based on anomaly scores and dynamic thresholds, and reallocate resources to abnormal nodes; Detect abnormal nodes at each moment. If a node has multiple abnormal scores greater than the dynamic threshold, the node will be isolated to ensure the stable operation of the distributed database.

Images