Risk control server message recovery method and device, equipment and storage medium

Abstract

The embodiment of the invention relates to a message recovery method and device for a risk control server, equipment and a storage medium, and the method comprises the steps: obtaining a to-be-detected message, configuring a first self-increasing identifier for the to-be-detected message, sending the first self-increasing identifier to a main risk control process, if the main risk control process determines that message loss occurs according to the first self-increasing identifier, a data continuous transmission request is sent to the data management process; wherein the main risk control process is a software risk control process or a hardware risk control process; and receiving a data continuous transmission request returned by the main risk control process, determining an internal continuous transmission message based on the data continuous transmission request, and sending the internal continuous transmission message to the main risk control process. According to the embodiment of the invention, the possibility of abnormal external service of the risk control server is reduced through the setting of the main and standby processes in the risk control server, the data continuous transmission recovery and the like, high-stability and high-availability risk control processing is realized on the basis of meeting low time delay, and the user requirements are better met.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of computer technologies, and in particular, to a method, apparatus, device, and storage medium for message recovery of a risk control server. Background Art

[0002] For systems that need to perform risk control, such as financial software systems, relevant calculations can be performed through a risk control server, and a risk control result can be given. The upstream data system of the risk control server is usually high-frequency data, which has the characteristics of low latency and strict maintenance of time sequence. Therefore, in this scenario, the risk control system is required to have the characteristics of low latency, high stability, and high availability.

[0003] In related technologies, an additional data center needs to be set up for the risk control server, and data recovery is achieved through this data center so that the risk control server meets the scenario requirements. However, how to achieve efficient data recovery while processing high-frequency data based on the risk control server itself without additionally setting up a data center has become an urgent problem to be solved currently. Summary of the Invention

[0004] To solve the above technical problems or at least partially solve the above technical problems, embodiments of the present disclosure provide a method, apparatus, device, and storage medium for message recovery of a risk control server.

[0005] In a first aspect of the embodiments of the present disclosure, a method for message recovery of a risk control server is provided, which is applied to a data management process in the risk control server. The risk control server includes a Central Processing Unit (CPU) and a Field-Programmable Gate Array (FPGA). The CPU deploys the data management process and a software risk control process, and the FPGA deploys a hardware risk control process. The software risk control process and the hardware risk control process are mutually primary and backup. The method includes:

[0006] Obtain a message to be detected, configure a first incrementing identifier (Identity, ID) for the message to be detected, and send the first incrementing identifier to the primary risk control process, so that if the primary risk control process determines that a message loss has occurred based on the first incrementing identifier, it sends a data resumption request to the data management process; wherein, the primary risk control process is the software risk control process or the hardware risk control process;

[0007] Receive the data resumption request returned by the primary risk control process, determine an internal resending message based on the data resumption request, and send the internal resending message to the primary risk control process.

[0008] The second aspect of the embodiments of the present disclosure provides a message recovery device for a risk control server, which is applied to a data management process in the risk control server. The risk control server includes a central processing unit (CPU) and a field programmable gate array (FPGA). The CPU deploys the data management process and a software risk control process, and the FPGA deploys a hardware risk control process. The software risk control process and the hardware risk control process are mutual primary and standby. The device includes:

[0009] A request module, configured to obtain a message to be detected, configure a first incrementing identifier for the message to be detected, and send the first incrementing identifier to the primary risk control process, so that if the primary risk control process determines that a message loss has occurred based on the first incrementing identifier, it sends a data retransmission request to the data management process; wherein, the primary risk control process is the software risk control process or the hardware risk control process;

[0010] A retransmission module, configured to receive the data retransmission request returned by the primary risk control process, determine an internal retransmitted message based on the data retransmission request, and send the internal retransmitted message to the primary risk control process.

[0011] The third aspect of the embodiments of the present disclosure provides an electronic device, which includes: a processor and a memory. Wherein, a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the method of the first aspect above.

[0012] The fourth aspect of the embodiments of the present disclosure provides a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a processor, the method of the first aspect above can be implemented.

[0013] The technical solution provided by the embodiments of the present disclosure has the following advantages compared with the prior art:

[0014] In an embodiment of the present disclosure, the message recovery method of the risk control server is applied to a data management process in the risk control server. The risk control server includes a central processing unit (CPU) and a field programmable gate array (FPGA). The CPU deploys a data management process and a software risk control process, and the FPGA deploys a hardware risk control process. The software risk control process and the hardware risk control process are mutually primary and backup. The method includes: obtaining a message to be detected, configuring a first auto-increment identifier for the message to be detected, and sending the first auto-increment identifier to the primary risk control process, so that if the primary risk control process determines that a message loss occurs based on the first auto-increment identifier, it sends a data retransmission request to the data management process; wherein, the primary risk control process is the software risk control process or the hardware risk control process; receiving the data retransmission request returned by the primary risk control process, determining an internal retransmission message based on the data retransmission request, and sending the internal retransmission message to the primary risk control process. By adopting the above technical solution, the hardware-based risk control processing is realized through the hardware risk control process deployed on the FPGA, with rapid response and low latency. The mutual primary and backup of the hardware risk control process deployed on the FPGA and the software risk control process deployed on the CPU realizes the mutual primary and backup of risk control processes based on different hardware, reducing the probability of simultaneous failures of the two risk control processes. Moreover, the continuous detection of the received messages by the primary risk control process is realized based on the auto-increment identifier used inside the risk control server. In the case of message loss, the data retransmission and recovery inside the risk control server are performed. The setting of the primary and backup processes inside the risk control server and the data retransmission and recovery reduce the possibility of abnormal external services of the risk control server, realizing high-stability and high-availability risk control processing on the basis of meeting low latency, and better meeting the user requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings herein are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with the present disclosure and used together with the specification to explain the principles of the present disclosure.

[0016] To more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following will briefly introduce the accompanying drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0017] Figure 1 is a schematic flowchart of a message recovery method for a risk control server provided by an embodiment of the present disclosure;

[0018] Figure 2 is a schematic diagram of the server state provided by an embodiment of the present disclosure;

[0019] Figure 3 is a schematic diagram of the process state provided by an embodiment of the present disclosure;

[0020] Figure 4It is a schematic flowchart of another message recovery method for a risk control server provided by an embodiment of the present disclosure;

[0021] Figure 5 It is a schematic structural diagram of a message recovery device for a risk control server provided by an embodiment of the present disclosure;

[0022] Figure 6 It is a schematic structural diagram of an electronic device in an embodiment of the present disclosure. Detailed implementation manners

[0023] In order to more clearly understand the above objects, features and advantages of the present disclosure, the solutions of the present disclosure will be further described below. It should be noted that, without conflict, the embodiments of the present disclosure and the features in the embodiments may be combined with each other.

[0024] For systems that need to perform risk control, such as financial software systems, relevant calculations can be performed through a risk control server, and a risk control result can be given. The upstream system of the risk control server is usually a high-frequency data system, which has the characteristics of low latency and strict maintenance of time sequence. Therefore, in this scenario, the risk control server is required to have the characteristics of low latency, high stability, and high availability. Among them, high availability can be achieved through primary-backup redundancy, failover, disaster recovery, etc. The purpose of disaster recovery is to quickly and automatically resume operation when a process in the risk control server or the entire risk control server appears abnormal. Since the risk control server has a data state, the business progress must also be restored to the data state before the abnormality occurs, so that from the perspective outside the risk control server, the message output of the entire risk control server is non-repetitive, non-omissive, and correct.

[0025] In the related art, an additional data center needs to be set up for the risk control server. Through this data center, message copies are stored, and data recovery is achieved by comparing message contents in the case of an abnormality in the risk control server. However, how to achieve high-frequency data processing based on the risk control server itself and achieve efficient data recovery without setting up an additional data center has become an urgent problem to be solved currently.

[0026] Many specific details are set forth in the following description in order to provide a thorough understanding of the present disclosure, but the present disclosure may be practiced in other ways different from those described herein; obviously, the embodiments in the specification are only a part of the embodiments of the present disclosure, rather than all of the embodiments.

[0027] To solve the above at least one technical problem, the message recovery method for a risk control server provided by an embodiment of the present disclosure will be described below. This method can be executed by an electronic device. The electronic device can be exemplarily understood as devices such as mobile phones, tablet computers, laptop computers, desktop computers, smart TVs, etc.

[0028] In some embodiments of the present disclosure, the message recovery method of the risk control server is applied to the data management process in the risk control server. The risk control server includes a central processing unit (CPU) and a field programmable gate array (FPGA). The CPU deploys a data management process and a software risk control process, and the FPGA deploys a hardware risk control process. The software risk control process and the hardware risk control process are mutually primary and standby.

[0029] Among them, the risk control server can be a server for performing risk control on a target system such as a financial software system. A risk control system can run on the risk control server, and the risk control system can be software that specifically implements risk control in the risk control server. The risk control server is simultaneously configured with a central processing unit and a field programmable gate array. The data management process can be a transfer process for the risk control process to interact with the target system, and the data management process can run on the CPU of the risk control server. Through the data management process, one or more of the functions such as server status management of the risk control server, data persistence, retransmission of lost data within the risk control server, breakpoint judgment for transmission interruption between the risk control server and the target system, and post-disaster recovery of the risk control server can be achieved.

[0030] The software risk control process can be a process that implements risk control logic through software code, and the software risk control process can run on the CPU of the risk control server. The hardware risk control process can be a process that implements risk control logic through hardware circuit programming, and the hardware risk control process can be implemented based on the FPGA of the risk control server. It should be noted that the hardware risk control process is not a software process but a running process implemented through hardware circuits, and this running process can be understood as a "quasi-software process". In the risk control server, the software risk control process and the hardware risk control process are mutually primary and standby, that is, the software risk control process is the primary risk control process and the hardware risk control process is the standby risk control process; or the hardware risk control process is the primary risk control process and the software risk control process is the standby risk control process. The primary risk control process can be the process that actually performs risk control currently; the standby risk control process can be the process that is standby for performing risk control currently.

[0031] In the embodiments of the present disclosure, a data management process and a software risk control process are deployed on the CPU of each risk control server, and a hardware risk control process is deployed on the FPGA. And the software risk control process and the hardware risk control process are mutually primary and standby, that is: after the primary risk control process fails, the original standby risk control process automatically becomes the primary risk control process, and the original failed primary risk control process becomes the standby risk control process after restarting and resuming services.

[0032] In some embodiments of the present disclosure, the number of risk control servers may be two, and the two risk control servers may be primary and standby to each other. If the current risk control server is a standby server, neither the software risk control process nor the hardware risk control process on this risk control server performs risk control calculations. When the current risk control server is the primary server and the server status is in the intraday state, if the software risk control process deployed on this risk control server is the primary risk control process and the hardware risk control process is the standby risk control process, the risk control calculations are performed through this software risk control process to determine the detection result, and the hardware risk control process does not perform risk control calculations; if the hardware risk control process is the primary risk control process and the software risk control process is the standby risk control process, the risk control calculations are performed through this hardware risk control process to determine the detection result, and the software risk control process does not perform risk control calculations.

[0033] Figure 1 It is a schematic flowchart of a message recovery method for a risk control server provided by an embodiment of the present disclosure. As Figure 1 shown, the method provided in this embodiment includes the following steps:

[0034] Step 101: Obtain the message to be detected, configure a first incrementing identifier for the message to be detected, and send the first incrementing identifier to the primary risk control process, so that if the primary risk control process determines that a message loss has occurred based on the first incrementing identifier, it sends a data retransmission request to the data management process; wherein, the primary risk control process is a software risk control process or a hardware risk control process.

[0035] Among them, the message to be detected may be a message to be subjected to risk situation detection. Taking the system that sends the message to be detected as a financial software system as an example, the message to be detected may include transaction messages such as deal messages and order messages. In some embodiments of the present disclosure, the message to be detected is a message sent by the target system to the data management process. The target system may be a software system with risk control detection requirements. The target system may be a software system that implements a specific service. The target system may have a request interface for full-volume messages. The type of the target system is not limited in this embodiment. The first incrementing identifier may be an incrementing identifier corresponding to the message to be detected generated by the data management process. The incrementing identifier may be an identifier that is applied inside the risk control server and corresponds one-to-one with the message. The incrementing identifier is unique and ordered, and the sequentially generated incrementing identifiers may be sequentially increasing serial numbers.

[0036] The data resumption request can be used to instruct the data management process to continue data transmission based on the message risk control processing situation in the main risk control process. For example, message resumption can be performed after the latest message among multiple consecutive messages received from the main risk control process. This data resumption can include retransmission of the sent messages or transmission of the missed messages. In some embodiments of the present disclosure, the data resumption request includes a first resumption identifier corresponding to the main risk control process, and the first resumption identifier is the latest incremented identifier among the incremented identifiers received continuously by the main risk control process. It can be understood that since the main risk control process verifies the continuity of the identifiers for all messages sent by the data management process, the first resumption identifier can be the incremented identifier of the previous message received by the main risk control process for the message to be detected.

[0037] In an embodiment of the present disclosure, the risk control server performs asynchronous risk control on the target system, that is, after the target system sends a message to the risk control server, the target system does not need to wait for the risk control server to process the message and can send subsequent messages to the risk control server. The target system can continuously send messages to the risk control server. Since the FPGA resources in the risk control server are limited, and in the risk control scenario, the messages to be detected received by the risk control server are often high-frequency messages. To avoid loss of messages to be detected due to reasons such as limited FPGA storage space, the data management process can generate a corresponding first incremented identifier for each message to be detected in the order of incrementing the serial number after receiving the message to be detected.

[0038] Furthermore, the data management process can send the first incremented identifier and the message to be detected to the main risk control process. The main risk control process can determine the previous message as the message received before the message to be detected and determine the incremented identifier corresponding to the previous message as the previous incremented identifier. The main risk control process can judge whether the first incremented identifier is the next identifier of the previous incremented identifier in the order of incrementing the identifier. If not, it indicates that there is a message loss between the previous message and the message to be detected. The main risk control process can generate a data resumption request according to the first resumption identifier determined by the incremented identifier of the previous message, and send the data resumption request to the data management process through the data retransmission request interface.

[0039] Step 102: Receive the data resumption request returned by the main risk control process, determine the internal resumption message based on the data resumption request, and send the internal resumption message to the main risk control process.

[0040] Among them, the internal resumption message can be a message determined based on the sequentially consecutive messages already received by the main risk control process. The internal resumption message can be a message supplemented and sent by the data management process to the main risk control process when it is determined that there is a message loss inside the risk control server. The internal resumption message can be understood as a breakpoint in the internal message transmission process of the risk control server.

[0041] In an embodiment of the present disclosure, the data management process may receive a data resumption request sent by the main risk control process, analyze the received message situation of the main risk control process according to the data resumption request, determine an internal resumption message, and send the internal resumption message to the main risk control process.

[0042] In some embodiments of the present disclosure, determining an internal resumption message based on a data resumption request includes: among a plurality of candidate messages, determining a candidate message whose order of candidate increment identifiers is after a first resumption identifier as the internal resumption message.

[0043] Wherein, the candidate message may be a message received by the data management process from the target system. The candidate increment identifier may be an identifier corresponding to the candidate message.

[0044] In this embodiment, the data management process may parse the data resumption request to determine the first resumption identifier in the data resumption request. Compare the candidate increment identifier of the candidate message with the first resumption identifier, and determine the candidate message corresponding to the candidate increment identifier whose order is after the first resumption identifier as the internal resumption message. Subsequently, the internal resumption message is sequentially sent to the main risk control process according to the order of the increment identifiers. Thus, based on the breakpoint where data transmission anomaly occurs determined by the first resumption identifier, normal message transmission between the data management process and the main risk control process is achieved.

[0045] In this embodiment, the target system sends a message to be detected to the data management process. After receiving each message to be detected, the data management process generates a first increment identifier used inside the risk control server corresponding to each message to be detected, and sends the message to be detected and its corresponding first increment identifier to the main risk control process. After receiving the message to be detected, the main risk control process determines whether a message loss occurs according to whether the first increment identifiers corresponding to the sequentially received messages to be detected are continuous. The reasons for the message loss include that the FPGA queue is full, message transmission anomaly between the main risk control process and the data management process, etc. If the main risk control process determines that the first increment identifiers are not continuous, it determines that a message loss occurs. The main risk control process may delete the messages whose identifier order is after the first increment identifier, and determine the increment identifier corresponding to the latest message among the received continuous messages as the first resumption identifier. Generate a data resumption request according to the first resumption identifier, and send the data resumption request to the data management process through the retransmission interface. The data management process obtains the data resumption request through the retransmission interface, parses the data resumption request to obtain the first resumption identifier, and sequentially sends the messages whose increment identifier is after the first resumption identifier to the main risk control process. The main risk control process may receive the internal resumption message.

[0046] In the embodiments of the present disclosure, the message recovery method of the risk control server is applied to the data management process in the risk control server. The risk control server includes a central processing unit (CPU) and a field programmable gate array (FPGA). The CPU is deployed with a data management process and a software risk control process, and the FPGA is deployed with a hardware risk control process. The software risk control process and the hardware risk control process are mutually primary and backup. The method includes: obtaining a message to be detected, configuring a first incrementing identifier for the message to be detected, and sending the first incrementing identifier to the primary risk control process, so that if the primary risk control process determines that a message loss has occurred based on the first incrementing identifier, it sends a data retransmission request to the data management process; wherein, the primary risk control process is the software risk control process or the hardware risk control process; receiving the data retransmission request returned by the primary risk control process, determining an internal retransmission message based on the data retransmission request, and sending the internal retransmission message to the primary risk control process. By adopting the above technical solution, the hardware-based risk control processing is realized through the hardware risk control process deployed on the FPGA, with rapid response and low latency. The mutual primary and backup of the hardware risk control process deployed on the FPGA and the software risk control process deployed on the CPU realizes the mutual primary and backup of risk control processes based on different hardware, reducing the probability of simultaneous failures of the two risk control processes. Moreover, the continuous detection of the received messages by the primary risk control process is realized based on the incrementing identifier used inside the risk control server. In the case of message loss, the data retransmission and recovery inside the risk control server are performed. The probability of abnormal external services of the risk control server is reduced through the setting of the primary and backup processes and data recovery inside the risk control server. High-stability and high-availability risk control processing are achieved on the basis of meeting low latency, which better meets the user requirements.

[0047] In addition, the CPU and FPGA inside the risk control server are heterogeneous, and the message transmission between the risk control server and the target system is asynchronous. Different from the message processing method of pure software for risk control, there is a hardware risk control process in the risk control server. The data recovery method improves the accuracy and integrity of the messages received by the primary risk control process under this kind of hardware foundation.

[0048] In the embodiments of the present disclosure, the risk control server can be divided into multiple server states according to the running stage. In some embodiments of the present disclosure, the server states of the risk control server include the state of server initializing, the state of server initialization completed, the in-tray state, and the end state.

[0049] Among them, the server status can represent different stages in the life cycle of the risk control server running. The status during server initialization can be the state where computing resources such as processes are not yet ready after the risk control server starts. In this state, the risk control server can load necessary resources and complete self-check. The status after server initialization is completed can be the state where resources such as the processes of the risk control server are ready but have not entered the risk control processing stage. The in-trading status can be the state where the risk control server is in the risk control processing stage. The end status can be the state where the risk control server stops the risk control service and releases the occupied resources.

[0050] Figure 2 It is a schematic diagram of the server status provided by the embodiments of the present disclosure. As Figure 2 shown, in response to the user's start trigger operation, the risk control server starts and enters the status during server initialization. In this stage, the data management process triggers the start of the hardware risk control process and the software risk control process. If the start fails, the risk control system in the risk control server is shut down. If the start is successful, after the last process starts successfully, the data management process notifies the target system and converts the server status to the status after server initialization is completed. After the target system receives the notification of the status after server initialization is completed, it waits for the user to trigger an operation to start risk control on the target system to generate a ready message. The target system responds to this ready message, notifies the data management process to convert the server status to the in-trading status, and performs in-trading risk control through the risk control server. After the user triggers an operation to end risk control on the target system, the target system responds to this trigger operation, notifies the data management process to convert the server status to the end status, and stops performing the risk control service. Thus, the status management of the risk control server is realized, providing a basis for judging the server status for subsequent disaster recovery.

[0051] In some embodiments of the present disclosure, the status after server initialization is completed represents that the data management process completes the establishment of the first shared memory, the software risk control process completes the establishment of the second shared memory and obtains the first preset risk control logic, the hardware risk control process completes the establishment of the third shared memory and obtains the second preset risk control logic, and moreover, the data management process establishes heartbeats with the software risk control process and the hardware risk control process respectively.

[0052] Among them, the first shared memory can be the shared memory corresponding to the data management process. The shared memory can be used for data interaction between processes. The data recorded in the first shared memory can include data to be detected, risk control logic, etc. The second shared memory can be the shared memory corresponding to the software risk control process. The third shared memory can be the shared memory corresponding to the hardware risk control process. The data recorded in the second shared memory and the third shared memory can include detection results, etc.

[0053] In this embodiment, two risk control processes, namely a hardware risk control process and a software risk control process that are mutually primary and standby, are running on a risk control server. Through the risk control processes, the risk control server can receive messages to be detected, perform risk control calculations, reply with detection results, and manage the process status.

[0054] The process status of a process may include the status of being in process initialization and the status of completed process initialization. Since each process may be restarted independently, it is difficult to accurately describe the status of each process based on the server status. The process status can represent the stage where a single process is located. A newly started process is in the status of being in process initialization, performs necessary initializations, and converts the process status to the status of completed process initialization after being ready. Figure 3 The following is a schematic diagram of the process status provided by the embodiments of the present disclosure. As Figure 3 shown, in this embodiment, after the data management process is started, it is in the status of being in process initialization and establishes a corresponding first shared memory. After the software risk control process is started, it is in the status of being in process initialization, establishes a corresponding second shared memory, obtains a first preset risk control logic for risk control based on software, and initiates a heartbeat establishment to the data management process. After the hardware risk control process is started, it is in the status of being in process initialization, establishes a corresponding third shared memory, obtains a second preset risk control logic for risk control based on hardware, and initiates a heartbeat establishment to the data management process. Among them, the above-mentioned first preset risk control logic and second preset risk control logic may be sent by the target system to the data management process, and the data management process sends the first preset risk control logic to the software risk control process and the second preset risk control logic to the hardware risk control process. The data management process establishes heartbeats with the software risk control process and the hardware risk control process respectively. After the heartbeat establishment is completed, the process statuses of the software management process and the hardware management process are determined to be the status of completed process initialization, and their own statuses are returned to the data management process. After the data management process determines that both the software risk control process and the hardware risk control process are in the status of completed process initialization, it adjusts its own status to the status of completed process initialization.

[0055] In the above solution, based on the adjustment of the process status, before performing the risk control calculation, the relevant processes are all initialized to reach the ready state, realizing the orderly operation of the processes and reducing the possibility of anomalies occurring during the risk control calculation process.

[0056] In some embodiments of the present disclosure, sending the first auto-increment identifier to the primary risk control process includes: sending the message to be detected and the first auto-increment identifier to the primary risk control process, so that if the primary risk control process determines that the messages are consecutive according to the first auto-increment identifier, it determines the first detection result corresponding to the message to be detected according to the preset risk control logic and sends the first detection result to the data management process.

[0057] Among them, the preset risk control logic can be rules for risk control set in advance. The preset risk control logic corresponding to the software risk control process can be the first preset risk control logic, and the preset risk control logic corresponding to the hardware risk control process can be the second preset risk control logic. The preset risk control logic can be adjusted according to user requirements, etc., and this embodiment does not limit it. The first preset risk control logic and the second preset risk control logic can be the same. The first detection result can be the risk control detection result corresponding to the message to be detected, and the detection result can include prohibited, passed, or warned.

[0058] In this embodiment, the data management process can send the first increment identifier and the message to be detected to the main risk control process. The main risk control process can determine the message received immediately before the message to be detected as the previous message, and determine the increment identifier corresponding to the previous message as the previous increment identifier. The main risk control process can judge whether the first increment identifier is the next identifier of the previous increment identifier in the order of increment of the identifier. If so, it indicates that no message loss has occurred between the previous message and the message to be detected, and the previous message and the message to be detected are consecutive messages. The main risk control process can perform risk control detection on the message to be detected according to the preset risk control logic to obtain the corresponding first detection result. And send the first detection result to the data management process.

[0059] In some embodiments of the present disclosure, when the main risk control process determines that the message is complete, the message recovery method of the risk control server further includes: receiving the first detection result returned by the main risk control process, and performing persistent storage processing on the first detection result and the message to be detected.

[0060] In this embodiment, the data management process can receive the first detection result determined by the main risk control process for detecting the message to be detected, and store the message to be detected and its corresponding first detection result in the preset storage unit.

[0061] In the related art, only the messages transmitted by the target system to the risk control server are backed up, and the detection results generated by the risk control server are not backed up. In this embodiment, by backing up the detection results, the detection results can be obtained quickly and efficiently when the detection results are used later, which is more suitable for scenarios of risk control of high-frequency data.

[0062] Figure 4 It is a schematic flowchart of another message recovery method of the risk control server provided by the embodiments of the present disclosure. As Figure 4 shown, in some embodiments of the present disclosure, the method further includes:

[0063] Step 401, in response to the recovery operations of the software risk control process and the hardware risk control process, obtain the second resume transmission identifier corresponding to the detected message stored persistently; wherein, the second resume transmission identifier is the latest increment identifier corresponding to the detected message.

[0064] Among them, the recovery operation can be an operation to restart the process after the process exception, and this recovery operation can be understood as a post-disaster restart operation. The detected message can be a message that the risk control server has completed the risk control detection. If the message to be detected has completed the risk control detection, then this message to be detected can be understood as a detected message. The second detection result can be the detection result corresponding to the detected message. The second resume flag is the latest one among the second increment flags corresponding to the detected messages. The second increment flag can be the increment flag corresponding to the detected message.

[0065] In this embodiment, when a disaster occurs to the risk control server as a whole, or when both the software risk control process and the hardware risk control process have disasters at the same time, recovery operations need to be performed on both the software risk control process and the hardware risk control process. In response to this recovery operation, the data management process obtains a plurality of detected messages stored in the preset storage unit, and determines the latest second increment flag among the plurality of second increment flags corresponding to the plurality of detected messages as the second resume flag.

[0066] In some embodiments of the present disclosure, obtaining the second resume flag corresponding to the detected message stored persistently includes: if the server status of the risk control server is the in-disk state, then obtaining the second resume flag corresponding to the detected message stored persistently; wherein, the in-disk state indicates that the process statuses of the data management process, the software risk control process, and the hardware risk control process are the process initialization completed state, and the data management process receives a ready message sent by the target system.

[0067] In this embodiment, in response to the recovery operations on the software risk control process and the hardware risk control process, the data management process first determines whether the risk control server is in the in-disk state. If so, it means that the exception occurs during the risk control process, and then subsequent message resume is performed; if not, it means that the exception does not occur during the risk control process, and then the subsequent message transmission is performed normally without message resume. Thus, invalid message resume is avoided.

[0068] Step 402, determine the target external identifier corresponding to the second resume flag, and send the target external identifier to the target system, so that the target system determines the external resume message according to the target external identifier.

[0069] Among them, the target external identifier can be the external identifier corresponding to the second resume identifier outside the risk control server. It can be understood that the incrementing identifier is an identifier with uniqueness and sequentiality used inside the risk control server, and the external identifier can be an identifier with uniqueness used inside and outside the risk control server. The external identifier can be a serial number without sequentiality, and the external identifier and the incrementing identifier can be in one-to-one correspondence. In this embodiment, the message has both an incrementing identifier and an external identifier, which adds an incrementing identifier representing the message order on the basis of the existing external identifier for differentiating messages, creating a basis for realizing the sequential detection of messages to be detected. Optionally, the incrementing identifier can be of numerical type, and the external identifier can be of string type. The external resume message can be a message that needs to continue risk control processing determined based on the message for which the risk control server has already performed risk control processing. The external resume message can be understood as the breakpoint in the message transmission process between the risk control server and the target system.

[0070] In this embodiment, the message sent by the target system has a corresponding external identifier used inside and outside the risk control server, and the data management process configures an incrementing identifier used inside the risk control server for each message. Each message has a corresponding external identifier and incrementing identifier. In this embodiment, after the data management process determines the second resume identifier, since the second resume identifier is an identifier used inside the risk control server, it is necessary to determine the target external identifier corresponding to the second resume identifier according to the identifier relationship and send the target external identifier to the target system. Among them, the identifier relationship can record the mapping relationship between the incrementing identifier and the external identifier.

[0071] In some embodiments of the present disclosure, the message recovery method of the risk control server further includes: obtaining the detected messages stored persistently and the corresponding second detection results of the detected messages; sending the detected messages and the second detection results to the software risk control process and the hardware risk control process, so that the software risk control process and the hardware risk control process perform preprocessing of risk control calculation according to the detected messages and the second detection results.

[0072] Among them, the second detection result can be the detection result corresponding to the detected message.

[0073] In this embodiment, when the risk control server is started after a disaster or when both risk control processes need to be started after a disaster, the data management process obtains the persistent data, which may include the server status, the detected messages, the second detection results, and the second auto-increment identifier. The data management process may determine whether the server status is the in-trading state. If so, it indicates that post-disaster data recovery is required. The data management process may obtain the detected messages and their corresponding second detection results from the persistent data, and send both the detected messages and the second detection results to the software risk control process and the hardware risk control process. The software risk control process and the hardware risk control process perform preprocessing for subsequent risk control calculations based on the received detected messages and second detection results, so as to perform subsequent risk control calculations based on the preprocessing results, bringing forward the calculation process, reducing the amount of calculation required for subsequent risk control calculations, and improving the risk control efficiency.

[0074] Moreover, after the data recovery of the software risk control process and the hardware risk control process is completed, the data management process may determine the second resume transmission identifier according to the second auto-increment identifier in the persistent data, and send the second resume transmission identifier to the target system. The target system determines the external resume transmission message according to the second resume transmission identifier, and continues the message transmission from the target system to the risk control server. Thus, the data recovery within the risk control process after a disaster and the message resume transmission between the target system and the risk control server are realized, and the post-disaster risk control processing recovery is realized in two dimensions, namely, inside and outside the risk control server, enabling the risk control processing to run normally and improving the operation stability of the risk control server.

[0075] Step 403: Receive the external resume transmission message returned by the target system.

[0076] In this embodiment, the data management process receives the external resume transmission message returned by the target system based on the second resume transmission identifier.

[0077] In the above solution, when both the software risk control process and the hardware risk control process need post-disaster recovery, the message transmission between the target system and the risk control server continues based on the second resume transmission identifier corresponding to the message stored persistently, realizing the accurate determination of the post-disaster message transmission endpoint and improving the message integrity after a failure.

[0078] In some embodiments of the present disclosure, the message recovery method of the risk control server further includes: in response to a recovery operation on the software risk control process or the hardware risk control process, determining the software risk control process or the hardware risk control process as the standby risk control process; sending the detected messages and the second detection results corresponding to the detected messages to the standby risk control process, so that the standby risk control process performs preprocessing for risk control calculations according to the detected messages and the second detection results.

[0079] In this embodiment, when the software risk control process needs to be restarted after a disaster and the hardware risk control process is normal, a recovery operation is performed on the software risk control process. In this case, the software risk control process is restarted as a standby risk control process, and the hardware risk control process is used as the primary risk control process. In response to this recovery operation, the data management process obtains the detected messages and their corresponding second detection results from the persistent data, and sends both the detected messages and the second detection results to the software risk control process. The software risk control process performs preprocessing for subsequent risk control calculations based on the received detected messages and second detection results.

[0080] When the hardware risk control process needs to be restarted after a disaster and the software risk control process is normal, a recovery operation is performed on the hardware risk control process. In this case, the hardware risk control process is restarted as a standby risk control process, and the software risk control process is used as the primary risk control process. In response to this recovery operation, the data management process obtains the detected messages and their corresponding second detection results from the persistent data, and sends both the detected messages and the second detection results to the hardware risk control process. The hardware risk control process performs preprocessing for subsequent risk control calculations based on the received detected messages and second detection results.

[0081] In the above solution, when one risk control process needs to be restarted after a disaster and the other risk control process is running normally, the risk control process to be restarted after the disaster is started as a standby risk control process. At this time, only the data recovery of the standby risk control process needs to be considered. The data management process sends the detected messages and their corresponding second detection results to the standby risk control process for data recovery. The data recovery in the standby risk control process is realized, providing data support for the subsequent switch of the standby risk control process to the primary risk control process.

[0082] The message recovery method of the risk control server provided by the embodiments of the present disclosure introduces an incrementing identifier of the numeric type, which improves the performance of the FPGA for comparing message identifiers. Based on this incrementing identifier, it is possible to determine whether the messages are continuous. The incrementing identifier is mapped and bound to an external identifier of the string type, and the identifier relationship can be queried through this incrementing identifier to determine the corresponding external identifier, creating a basis for disaster recovery. Based on the incrementing identifier applied inside the risk control server, it is possible to support the hardware to perform functions such as message loss judgment, lost message positioning, and resume from breakpoint, improving data security, ensuring that messages are not duplicated, not missed, and in the correct order. The retransmission of data when data is lost is realized, so that the data in the hardware risk control process and the software risk control process is not lost or duplicated during operation, solving the problem of message loss when the business processing process processes high-frequency messages. Through the management functions of the process state and the server state, the processes and the server are made to be ready to work in sequence, and the responsibilities of each stage are not confused.

[0083] And the increment identifier is of numeric type, and the comparison of numeric type is faster than that of string type, thus improving the feasibility and performance of sequential comparison of identifiers through hardware such as FPGA. And through the persistent storage of the detected messages, the second detection results, and the second increment identifier, fast recovery of historical data is realized based on this persistent data during post-disaster restart. Through the breakpoint judgment and data recovery of data transmission between the risk control server and the target system, continuous transmission of upstream data after the post-disaster system restart is realized.

[0084] Figure 5 FIG. is a schematic structural diagram of a message recovery device of a risk control server provided by an embodiment of the present disclosure. The message recovery device of the risk control server can be understood as the above-mentioned electronic device or some functional modules in the above-mentioned electronic device. The device is applied to a data management process in the risk control server. The risk control server includes a central processing unit CPU and a field programmable gate array FPGA. The CPU deploys the data management process and a software risk control process, and the FPGA deploys a hardware risk control process. The software risk control process and the hardware risk control process are mutually the primary and backup. The method includes:

[0085] A request module 501, configured to obtain a message to be detected, configure a first increment identifier for the message to be detected, and send the first increment identifier to the primary risk control process, so that if the primary risk control process determines that a message loss has occurred according to the first increment identifier, it sends a data continuous transmission request to the data management process; wherein, the primary risk control process is the software risk control process or the hardware risk control process;

[0086] A continuous transmission module 502, configured to receive the data continuous transmission request returned by the primary risk control process, determine an internal retransmission message based on the data continuous transmission request, and send the internal retransmission message to the primary risk control process.

[0087] Optionally, the data continuous transmission request includes a first continuous transmission identifier corresponding to the primary risk control process. The first continuous transmission identifier is the latest increment identifier among the consecutive increment identifiers received by the primary risk control process. The determining the internal retransmission message based on the data continuous transmission request includes:

[0088] Among multiple candidate messages, determining the candidate message whose order of candidate increment identifiers is after the first continuous transmission identifier as the internal retransmission message.

[0089] Optionally, the sending the first increment identifier to the primary risk control process includes:

[0090] Send the message to be detected and the first incrementing identifier to the main risk control process, so that if the main risk control process determines that the messages are continuous based on the first incrementing identifier, it determines the first detection result corresponding to the message to be detected according to the preset risk control logic, and sends the first detection result to the data management process;

[0091] Correspondingly, the message recovery device of the risk control server further includes:

[0092] A persistence module, configured to receive the first detection result returned by the main risk control process, and perform a persistence storage process on the first detection result and the message to be detected.

[0093] Optionally, the message to be detected is a message sent by the target system to the data management process, and the message recovery device of the risk control server further includes:

[0094] A first acquisition module, configured to, in response to a recovery operation on the software risk control process and the hardware risk control process, acquire a second resumption identifier corresponding to the detected message stored persistently; wherein, the second resumption identifier is the latest incrementing identifier corresponding to the detected message;

[0095] A first sending module, configured to determine a target external identifier corresponding to the second resumption identifier, and send the target external identifier to the target system, so that the target system determines an external resumption message according to the target external identifier;

[0096] A receiving module, configured to receive the external resumption message returned by the target system.

[0097] Optionally, acquiring the second resumption identifier corresponding to the detected message stored persistently includes:

[0098] If the server state of the risk control server is in the in - progress state, acquire the second resumption identifier corresponding to the detected message stored persistently; wherein, the in - progress state indicates that the process states of the data management process, the software risk control process, and the hardware risk control process are in the state of completed process initialization, and the data management process receives a ready message sent by the target system.

[0099] Optionally, the message recovery device of the risk control server further includes:

[0100] A second acquisition module, configured to acquire the detected message stored persistently and the second detection result corresponding to the detected message;

[0101] A second sending module, configured to send the detected message and the second detection result to the software risk control process and the hardware risk control process, so that the software risk control process and the hardware risk control process perform preprocessing of risk control calculation according to the detected message and the second detection result.

[0102] Optionally, the message recovery device of the risk control server further includes:

[0103] A determination module, configured to determine the software risk control process or the hardware risk control process as a standby risk control process in response to a recovery operation on the software risk control process or the hardware risk control process;

[0104] A third sending module, configured to send the detected message and the second detection result corresponding to the detected message to the standby risk control process, so that the standby risk control process performs preprocessing of risk control calculation according to the detected message and the second detection result.

[0105] Optionally, the server state of the risk control server includes a server initializing state, a server initialization completed state, a market state, and an end state.

[0106] Optionally, the server initialization completed state indicates that the data management process has completed the establishment of the first shared memory, the software risk control process has completed the establishment of the second shared memory and obtained the first preset risk control logic, the hardware risk control process has completed the establishment of the third shared memory and obtained the second preset risk control logic, and the data management process has established heartbeats with the software risk control process and the hardware risk control process respectively.

[0107] The device provided in this embodiment can execute the method of any of the above embodiments, and its execution manner and beneficial effects are similar, which will not be elaborated here.

[0108] The present disclosure embodiment further provides an electronic device, which includes: a memory storing a computer program; a processor configured to execute the computer program, and when the computer program is executed by the processor, the method of any of the above embodiments can be implemented.

[0109] Exemplarily, Figure 6 is a schematic structural diagram of an electronic device in the present disclosure embodiment. Specifically refer to the following Figure 6, which shows a schematic structural diagram of the electronic device 600 suitable for implementing the embodiments of the present disclosure. The electronic device 600 in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Tablet Computers), PMPs (Portable Multimedia Players), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The electronic device shown is merely an example and should not impose any limitations on the functions and usage scope of the embodiments of the present disclosure.

[0110] As Figure 6 shown, the electronic device 600 may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 601, which may perform various appropriate actions and processes according to the programs stored in the read-only memory (ROM) 602 or the programs loaded from the storage device 608 into the random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the electronic device 600 are also stored. The processing device 601, the ROM 602, and the RAM 603 are connected to each other through a bus 604. The input / output (I / O) interface 605 is also connected to the bus 604.

[0111] Generally, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device 600 to communicate with other devices wirelessly or wiredly to exchange data. Although Figure 6 the electronic device 600 with various devices is shown, it should be understood that it is not required to implement or have all the shown devices. Instead, more or fewer devices may be implemented or had.

[0112] Particularly, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, the embodiments of the present disclosure include a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program codes for performing the methods shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from the network through the communication device 609, or installed from the storage device 608, or installed from the ROM 602. When the computer program is executed by the processing device 601, the above functions defined in the methods of the embodiments of the present disclosure are executed.

[0113] It should be noted that the above-mentioned computer-readable medium in the present disclosure can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program, which can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present disclosure, the computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0114] In some embodiments, the client and the server can communicate using any currently known or future-developed network protocol such as HTTP (HyperText Transfer Protocol), and can be interconnected with digital data communication in any form or medium (e.g., a communication network). Examples of communication networks include local area networks (“LAN”), wide area networks (“WAN”), the Internet (e.g., the Internet), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0115] The above-mentioned computer-readable medium can be included in the above-mentioned electronic device; or it can exist separately and not be assembled into the electronic device.

[0116] The above computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: obtain a message to be detected, configure a first incrementing identifier for the message to be detected, and send the first incrementing identifier to the main risk control process, so that if the main risk control process determines that a message loss has occurred based on the first incrementing identifier, it sends a data retransmission request to the data management process; wherein, the main risk control process is the software risk control process or the hardware risk control process; receive the data retransmission request returned by the main risk control process, determine an internal retransmission message based on the data retransmission request, and send the internal retransmission message to the main risk control process.

[0117] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages or combinations thereof. The programming languages include, but are not limited to, object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0118] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing the specified functions or operations, or may be implemented by a combination of dedicated hardware and computer instructions.

[0119] The units described in the embodiments of the present disclosure may be implemented in software or in hardware. In some cases, the name of the unit does not constitute a limitation on the unit itself.

[0120] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. By way of example, and without limitation, the types of hardware logic components that may be used include: Field Programmable Gate Arrays (FPGA), Application Specific Integrated Circuits (ASIC), Application Specific Standard Products (ASSP), System on a Chip (SOC), Complex Programmable Logic Devices (CPLD), and the like.

[0121] In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0122] Embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program, which when executed by a processor can implement the method of any of the above embodiments. The execution manner and beneficial effects are similar and will not be elaborated here.

[0123] It should be noted that, in this document, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises", "comprising", or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or device that comprises a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or device. Without further limitation, an element defined by the phrase "comprising a..." does not exclude the existence of additional identical elements in the process, method, article, or device that comprises the element.

[0124] The above are only specific embodiments of the present disclosure, enabling those skilled in the art to understand or implement the present disclosure. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to these embodiments described herein, but rather will be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A message recovery method for a risk control server, which is applied to a data management process in the risk control server. The risk control server includes a central processing unit (CPU) and a field programmable gate array (FPGA). The CPU deploys the data management process and a software risk control process, and the FPGA deploys a hardware risk control process. The software risk control process and the hardware risk control process are mutually primary and standby. The method includes: Obtain a message to be detected, configure a first incrementing identifier for the message to be detected, and send the first incrementing identifier to the primary risk control process, so that if the primary risk control process determines that a message loss has occurred based on the first incrementing identifier, it sends a data retransmission request to the data management process; wherein, the primary risk control process is the software risk control process or the hardware risk control process; Receive the data retransmission request returned by the primary risk control process, determine an internal retransmission message based on the data retransmission request, and send the internal retransmission message to the primary risk control process.

2. The method according to claim 1, wherein The data retransmission request includes a first retransmission identifier corresponding to the primary risk control process. The first retransmission identifier is the latest incrementing identifier among the consecutive incrementing identifiers received by the primary risk control process. Determining the internal retransmission message based on the data retransmission request includes: Among multiple candidate messages, determine the candidate messages whose order of candidate incrementing identifiers is after the first retransmission identifier as the internal retransmission message.

3. The method according to claim 1, wherein The sending the first incrementing identifier to the primary risk control process includes: Send the message to be detected and the first incrementing identifier to the primary risk control process, so that if the primary risk control process determines that the messages are consecutive based on the first incrementing identifier, it determines a first detection result corresponding to the message to be detected according to a preset risk control logic, and sends the first detection result to the data management process; Correspondingly, the method further includes: Receive the first detection result returned by the primary risk control process, and perform persistent storage processing on the first detection result and the message to be detected.

4. The method according to claim 1, characterized in that The message to be detected is a message sent by a target system to the data management process. The method further includes: In response to a recovery operation on the software risk control process and the hardware risk control process, obtain a second retransmission identifier corresponding to the detected message stored persistently; wherein, the second retransmission identifier is the latest incrementing identifier corresponding to the detected message; Determine a target external identifier corresponding to the second retransmission identifier, and send the target external identifier to the target system, so that the target system determines an external retransmission message according to the target external identifier; Receive the external retransmission message returned by the target system.

5. The method according to claim 4, characterized in that, The obtaining the second retransmission identifier corresponding to the detected message stored persistently includes: If the server state of the risk control server is in the in - progress state, obtain the second retransmission identifier corresponding to the detected message stored persistently; wherein, the in - progress state indicates that the process states of the data management process, the software risk control process, and the hardware risk control process are in the state of process initialization completed, and the data management process has received a ready message sent by the target system.

6. The method according to claim 4, characterized in that The method further includes: Obtain the detected message stored persistently and the second detection result corresponding to the detected message; Send the detected message and the second detection result to the software risk control process and the hardware risk control process, so that the software risk control process and the hardware risk control process perform preprocessing of risk control calculation according to the detected message and the second detection result.

7. The method according to claim 1, characterized in that The method further includes: In response to a recovery operation on the software risk control process or the hardware risk control process, determine the software risk control process or the hardware risk control process as a standby risk control process; Send the detected message and the second detection result corresponding to the detected message to the standby risk control process, so that the standby risk control process performs preprocessing of risk control calculation according to the detected message and the second detection result.

8. The method according to claim 1, characterized in that The server state of the risk control server includes a state of server initialization in progress, a state of server initialization completed, a state during trading, and an end state.

9. The method according to claim 8, wherein The state of server initialization completed indicates that the data management process has completed the establishment of the first shared memory, the software risk control process has completed the establishment of the second shared memory and obtained the first preset risk control logic, the hardware risk control process has completed the establishment of the third shared memory and obtained the second preset risk control logic, and moreover, the data management process has established heartbeats with the software risk control process and the hardware risk control process respectively.

10. A message recovery device for a risk control server, applied to the data management process in the risk control server. The risk control server includes a central processing unit (CPU) and a field programmable gate array (FPGA). The data management process and the software risk control process are deployed on the CPU, and the hardware risk control process is deployed on the FPGA. The software risk control process and the hardware risk control process are mutually the primary and standby. The device includes: A request module, configured to obtain a message to be detected, configure a first auto-increment identifier for the message to be detected, and send the first auto-increment identifier to the primary risk control process, so that if the primary risk control process determines that a message loss has occurred according to the first auto-increment identifier, it sends a data retransmission request to the data management process; wherein, the primary risk control process is the software risk control process or the hardware risk control process; A retransmission module, configured to receive the data retransmission request returned by the primary risk control process, determine an internal retransmitted message based on the data retransmission request, and send the internal retransmitted message to the primary risk control process.

11. An electronic device, characterized in that, including: A processor and a memory, wherein a computer program is stored in the memory. When the computer program is executed by the processor, the processor executes the method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, A computer program is stored in the storage medium. When the computer program is executed by the processor, the method according to any one of claims 1-9 is implemented.

Images