Message recovery method, device and equipment of risk control server and storage medium

Abstract

Embodiments of the present disclosure relate to a message recovery method and device of a risk control server, an apparatus and a storage medium. The method comprises: obtaining a to-be-detected message, configuring a first self-incrementing identifier for the to-be-detected message, and sending the first self-incrementing identifier to a main risk control process, so that the main risk control process sends a data resumption request to a data management process if it is determined that message loss occurs according to the first self-incrementing identifier; wherein the main risk control process is a software risk control process or a hardware risk control process; receiving the data resumption request returned by the main risk control process, determining an internal resending message based on the data resumption request, and sending the internal resending message to the main risk control process. According to the embodiments of the present disclosure, the possibility of external service exception of the risk control server is reduced through the internal master-slave process setting and data resumption recovery of the risk control server, high stability and high availability of the risk control processing are realized on the basis of meeting low latency, and the user demand is better met.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a message recovery method, apparatus, device, and storage medium for a risk control server. Background Technology

[0002] For risk control systems such as financial software systems, risk control servers can perform relevant calculations and provide risk control results. The upstream data systems of risk control servers typically handle high-frequency data, characterized by low latency and strict adherence to time sequences. Therefore, in this scenario, the risk control system needs to possess 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 to achieve data recovery and enable the risk control server to meet the requirements of the scenario. However, how to achieve efficient data recovery while processing high-frequency data on the risk control server itself without setting up an additional data center has become an urgent problem to be solved. Summary of the Invention

[0004] To solve the above-mentioned technical problems, or at least partially solve them, this disclosure provides a message recovery method, apparatus, device, and storage medium for a risk control server.

[0005] A first aspect of this disclosure provides a message recovery method for a risk control server, applied to a data management process within 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, while the FPGA deploys a hardware risk control process. The software risk control process and the hardware risk control process are mutually redundant. The method includes:

[0006] Obtain the message to be detected, configure a first auto-incrementing identifier (Identity, ID) for the message to be detected, and send the first auto-incrementing identifier to the main risk control process, so that if the main risk control process determines that a message has been lost based on the first auto-incrementing identifier, it will send a data continuation request to the data management process; wherein, the main risk control process is the software risk control process or the hardware risk control process;

[0007] The system receives the data continuation request returned by the main risk control process, determines an internal continuation message based on the data continuation request, and sends the internal continuation message to the main risk control process.

[0008] A second aspect of this disclosure provides a message recovery device for a risk control server, applied to a data management process in a 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 redundant. The device includes:

[0009] The request module is used to obtain the message to be detected, configure a first auto-incrementing identifier for the message to be detected, and send the first auto-incrementing identifier to the main risk control process, so that if the main risk control process determines that a message has been lost based on the first auto-incrementing identifier, it sends a data continuation request to the data management process; wherein, the main risk control process is the software risk control process or the hardware risk control process.

[0010] The data continuation module is used to receive the data continuation request returned by the main risk control process, determine an internal continuation message based on the data continuation request, and send the internal continuation message to the main risk control process.

[0011] A third aspect of this disclosure provides an electronic device, the server comprising: a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the method of the first aspect described above.

[0012] A fourth aspect of this disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the method of the first aspect described above.

[0013] The technical solution provided in this disclosure has the following advantages compared with the prior art:

[0014] In this embodiment of the disclosure, the message recovery method for 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 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: acquiring a message to be detected; configuring a first auto-incrementing identifier for the message to be detected; sending the first auto-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 auto-incrementing identifier, it sends a data continuation request to the data management process; wherein, the primary risk control process is either a software risk control process or a hardware risk control process; receiving the data continuation request returned by the primary risk control process; determining an internal continuation message based on the data continuation request; and sending the internal continuation message to the primary risk control process. By adopting the above technical solution, hardware-based risk control processing is achieved through a hardware risk control process deployed on an FPGA. This results in rapid response and low latency. The hardware risk control process and the software risk control process deployed on the CPU serve as primary and backup processes, reducing the probability of simultaneous failure of both risk control processes. Furthermore, the main risk control process detects the continuity of received messages based on an auto-incrementing identifier used internally by the risk control server. In the event of message loss, data is resumed and restored within the risk control server. Through the primary and backup process settings and data resumption and restoration within the risk control server, the possibility of service anomalies is reduced. This achieves high stability and high availability of risk control processing while maintaining low latency, effectively meeting user needs. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0016] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a message recovery method for a risk control server provided in an embodiment of this disclosure;

[0018] Figure 2 This is a schematic diagram of the server status provided in an embodiment of this disclosure;

[0019] Figure 3 This is a schematic diagram of the process state provided in the embodiments of this disclosure;

[0020] Figure 4This is a flowchart illustrating another message recovery method for a risk control server provided in this embodiment of the disclosure;

[0021] Figure 5 This is a schematic diagram of the structure of a message recovery device for a risk control server provided in an embodiment of this disclosure;

[0022] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0023] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0024] For risk control systems such as financial software systems, risk control servers can perform relevant calculations and provide risk control results. The upstream systems of risk control servers are typically high-frequency data systems, characterized by low latency and strict time-series requirements. Therefore, in this scenario, risk control servers need to be low-latency, highly stable, and highly available. High availability can be achieved through primary / backup redundancy, failover, and disaster recovery. The purpose of disaster recovery is to quickly and automatically resume operation when processes or the entire risk control server malfunction. Since risk control servers have a data state, the business progress must also be restored to the data state before the anomaly occurred, ensuring that from an external perspective, the message output of the entire risk control server is non-repetitive, complete, and accurate.

[0025] In related technologies, an additional data center needs to be set up for the risk control server to store message copies and to recover data in the event of server malfunction by comparing message content. However, how to achieve efficient data recovery while processing high-frequency data on the risk control server itself without setting up an additional data center remains a pressing problem.

[0026] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0027] To address at least one of the aforementioned technical problems, the message recovery method for a risk control server provided in this disclosure is described below. This method can be executed by an electronic device. This electronic device can be exemplarily understood as a device such as a mobile phone, tablet computer, laptop computer, desktop computer, or smart TV.

[0028] In some embodiments of this 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 redundant.

[0029] The risk control server is a server that performs risk control on target systems such as financial software systems. This server can run a risk control system, which is the software that implements risk control. The risk control server is also equipped with a central processing unit (CPU) and a field-programmable gate array (FPGA). The data management process acts as a relay process for data interaction between the risk control process and the target system. This data management process can run on the CPU of the risk control server. Through this data management process, one or more functions can be implemented, including server status management, data persistence, retransmission of lost data within the risk control server, breakpoint detection for transmission interruptions between the risk control server and the target system, and disaster recovery of the risk control server.

[0030] Software-based risk control processes can be those that implement risk control logic through software code, running on the CPU of the risk control server. Hardware-based risk control processes, on the other hand, can implement risk control logic through hardware circuit programming, typically based on the FPGA of the risk control server. It's important to note that these hardware-based processes are not software processes but rather a type of operation implemented through hardware circuits; they can be understood as "software-like processes." Within the risk control server, the software and hardware risk control processes act as primary and backup processes, respectively. Specifically, the software process is the primary risk control process, and the hardware process is the backup; alternatively, the hardware process is the primary risk control process, and the software process is the backup. The primary risk control process is the one currently performing risk control; the backup process is the one currently in standby mode for risk control.

[0031] In this embodiment, 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. Furthermore, the software risk control process and the hardware risk control process act as primary and backup processes to each other; that is, if the primary risk control process fails, the original backup risk control process automatically becomes the primary risk control process, and the failed primary risk control process becomes the backup risk control process after restarting and restoring the service.

[0032] In some embodiments of this disclosure, there can be two risk control servers, and these two risk control servers can serve as primary and backup servers for each other. If the current risk control server is a backup server, neither the software risk control process nor the hardware risk control process on that server performs risk control calculations. When the current risk control server is the primary server and its status is "on disk," if the software risk control process deployed on that server is the primary risk control process and the hardware risk control process is the backup risk control process, then the software risk control process performs risk control calculations to determine the detection result, while 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 backup risk control process, then the hardware risk control process performs risk control calculations to determine the detection result, while the software risk control process does not perform risk control calculations.

[0033] Figure 1 This is a flowchart illustrating a message recovery method for a risk control server provided in an embodiment of this disclosure, as shown below. Figure 1 As shown, the method provided in this embodiment includes the following steps:

[0034] Step 101: Obtain the message to be detected, configure a first auto-incrementing identifier for the message to be detected, and send the first auto-incrementing identifier to the main risk control process so that if the main risk control process determines that a message has been lost based on the first auto-incrementing identifier, it will send a data continuation request to the data management process; wherein, the main risk control process is a software risk control process or a hardware risk control process.

[0035] The message to be detected can be a message for which risk assessment is to be performed. Taking a financial software system as an example, the message to be detected can include transaction messages such as transaction messages and order placement messages. In some embodiments of this disclosure, the message to be detected is a message sent by the target system to the data management process. The target system can be a software system with risk control detection requirements, a software system that implements specific business functions, and a request interface for all messages. This embodiment does not limit the type of the target system. The first auto-incrementing identifier can be an auto-incrementing identifier corresponding to the message to be detected generated by the data management process. The auto-incrementing identifier can be an identifier that corresponds one-to-one with the message and is used internally by the risk control server. The auto-incrementing identifier is unique and ordered, and the sequentially generated auto-incrementing identifiers can be sequentially increasing serial numbers.

[0036] A data continuation request can be used to instruct the data management process to continue data transmission based on the message risk control processing status in the main risk control process. For example, it can resume message transmission after the latest message among multiple consecutive messages received by the main risk control process. This data continuation may include retransmission of already sent messages or transmission of missed messages. In some embodiments of this disclosure, the data continuation request includes a first continuation identifier corresponding to the main risk control process, which is the latest auto-incrementing identifier among consecutive auto-incrementing identifiers received by the main risk control process. It is understood that since the main risk control process verifies the continuity of identifiers for all messages sent by the data management process, this first continuation identifier can be the auto-incrementing identifier of the previous message from which the main risk control process received the message to be detected.

[0037] In this embodiment, 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, it can send subsequent messages without waiting for the server to process the message. The target system can continuously send messages to the risk control server. Since the FPGA resources in the risk control server are limited, and the messages to be detected received in risk control scenarios are often high-frequency messages, to avoid the loss of messages due to FPGA storage space limitations, the data management process can generate a unique first auto-incrementing identifier for each message after receiving it, using an auto-incrementing sequence number.

[0038] Furthermore, the data management process can send the first auto-incrementing identifier and the message to be detected to the main risk control process. The main risk control process can identify the message received before the message to be detected as the previous message and the auto-incrementing identifier corresponding to that previous message as the previous auto-incrementing identifier. The main risk control process can determine whether the first auto-incrementing identifier is the next identifier after the previous auto-incrementing identifier according to the auto-incrementing order of the identifiers. 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 continuation request based on the first continuation identifier determined by the auto-incrementing identifier of the previous message, and send the data continuation request to the data management process through the data retransmission request interface.

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

[0040] Internal follow-up messages can be messages determined based on the sequential sequence of messages already received by the main risk control process. These internal follow-up messages are sent by the data management process to the main risk control process in the event of message loss within the risk control server. These internal follow-up messages can be understood as representing a breakpoint in the message transmission process within the risk control server.

[0041] In this embodiment of the disclosure, the data management process can receive a data continuation request sent by the main risk control process, analyze the message status received by the main risk control process based on the data continuation request, determine the internal continuation message, and send the internal continuation message to the main risk control process.

[0042] In some embodiments of this disclosure, determining an internal continuation message based on a data continuation request includes: among multiple candidate messages, determining the candidate message whose candidate auto-incrementing identifier is in the order of the first continuation identifier as the internal continuation message.

[0043] Among them, the candidate message can be a message received by the data management process from the target system. The candidate auto-incrementing identifier can be the identifier corresponding to the candidate message.

[0044] In this embodiment, the data management process can parse the data continuation request and determine the first continuation identifier in the request. The candidate auto-incrementing identifiers of the candidate messages are compared with the first continuation identifier. Candidate messages with auto-incrementing identifiers following the first continuation identifier are identified as internal continuation messages. These internal continuation messages are then sent to the main risk control process sequentially according to the order of their auto-incrementing identifiers. Thus, based on the breakpoint where the data transmission anomaly occurred, determined by the first continuation 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. Upon receiving each message, the data management process generates a first auto-incrementing identifier for each message, used internally by the risk control server, and sends the message and its corresponding first auto-incrementing identifier to the main risk control process. Upon receiving the message, the main risk control process determines whether message loss has occurred based on the continuity of the first auto-incrementing identifiers of the sequentially received messages. Reasons for message loss include a full FPGA queue, abnormal message transmission between the main risk control process and the data management process, etc. If the main risk control process determines that the first auto-incrementing identifiers are not continuous, it determines that message loss has occurred. The main risk control process can delete messages whose identifier order follows the first auto-incrementing identifier and determine the auto-incrementing identifier corresponding to the latest message among the received consecutive messages as the first continuation identifier. Based on this first continuation identifier, it generates a data continuation request and sends it to the data management process through the retransmission interface. The data management process obtains the data continuation request through the retransmission interface, parses the request to obtain the first continuation identifier, and sequentially sends the messages whose auto-incrementing identifier follows the first continuation identifier to the main risk control process. The main risk control process can receive this internal follow-up message.

[0046] In this embodiment of the disclosure, the message recovery method for 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 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: acquiring a message to be detected; configuring a first auto-incrementing identifier for the message to be detected; sending the first auto-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 auto-incrementing identifier, it sends a data continuation request to the data management process; wherein, the primary risk control process is either a software risk control process or a hardware risk control process; receiving the data continuation request returned by the primary risk control process; determining an internal continuation message based on the data continuation request; and sending the internal continuation message to the primary risk control process. By adopting the above technical solution, hardware-based risk control processing is achieved through a hardware risk control process deployed on an FPGA. This results in rapid response and low latency. The hardware risk control process and the software risk control process deployed on the CPU serve as primary and backup processes for each other, reducing the probability of simultaneous failure of both risk control processes. Furthermore, the main risk control process detects the continuity of received messages based on an auto-incrementing identifier used internally by the risk control server. In the event of message loss, data is resumed and restored within the risk control server. Through the primary and backup process settings and data recovery within the risk control server, the possibility of service anomalies is reduced. This approach achieves high stability and high availability of risk control processing while maintaining low latency, effectively meeting user needs.

[0047] Furthermore, the risk control server's internal CPU and FPGA are heterogeneous, and the message transmission between the risk control server and the target system is asynchronous. Unlike the message processing method of pure software-based risk control, this risk control server contains a hardware risk control process. This data recovery method improves the accuracy and completeness of messages received by the main risk control process under this hardware foundation.

[0048] In this embodiment of the disclosure, the risk control server can be divided into multiple server states according to the operation stage. In some embodiments of the disclosure, the server states of the risk control server include server initialization state, server initialization completed state, in-market state, and terminated state.

[0049] The server status represents different stages in the lifecycle of the risk control server. The "Server Initialization" state indicates that the risk control server has started but its processes and computing resources are not yet ready. In this state, the risk control server can load necessary resources and complete self-checks. The "Server Initialization Completed" state indicates that the risk control server's processes and resources are ready but it has not yet entered the risk control processing stage. The "In-Process" state indicates that the risk control server is in the risk control processing stage. The "Terminated" state indicates that the risk control server has stopped its risk control services and released the resources it occupied.

[0050] Figure 2 A schematic diagram of the server status provided in the embodiments of this disclosure, such as... Figure 2 As shown, in response to a user's trigger operation, the risk control server starts and enters the server initialization state. During 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 has finished starting, the data management process notifies the target system and changes the server state to the server initialization complete state. After receiving the notification of the server initialization complete state, the target system waits for the user to trigger the start of risk control to generate a ready message. In response to this ready message, the target system notifies the data management process to change the server state to the in-disk state and performs in-disk risk control processing through the risk control server. After the user triggers the end of risk control to the target system, the target system responds to this trigger operation and notifies the data management process to change the server state to the end state, stopping the risk control service. Thus, the state management of the risk control server is realized, providing a basis for judging the server state for subsequent disaster recovery.

[0051] In some embodiments of this disclosure, the server initialization completion status 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 establishes heartbeats with the software risk control process and the hardware risk control process respectively.

[0052] The first shared memory can be the shared memory corresponding to the data management process. This shared memory can be used for data interaction between processes, and the data recorded in this first shared memory may 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 and third shared memories may include detection results, etc.

[0053] In this embodiment, a risk control server runs two types of risk control processes: a hardware risk control process and a software risk control process that serve as both primary and backup processes. These risk control processes can receive messages to be detected, perform risk control calculations and respond with detection results, and manage the process status.

[0054] A process's state can include the process initialization state and the process initialization completed state. Since each process may restart independently, it's difficult to accurately describe the state of each process based solely on the server state. Process states can represent the stage a single process is in. A newly started process is in the process initialization state, performing necessary initializations. Once ready, the process state transitions to the process initialization completed state. Figure 3 A schematic diagram of the process state provided in the embodiments of this disclosure, such as Figure 3 As shown, in this embodiment, after the data management process starts, it is in the process initialization state and establishes a corresponding first shared memory. After the software risk control process starts, it is in the process initialization state and establishes a corresponding second shared memory, obtains a first preset risk control logic based on software risk control, and initiates a heartbeat connection with the data management process. After the hardware risk control process starts, it is in the process initialization state and establishes a corresponding third shared memory, obtains a second preset risk control logic based on hardware risk control, and initiates a heartbeat connection with the data management process. The first and second preset risk control logics can be sent from 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 both the software and hardware risk control processes. After the heartbeat connection is established, the process states of both the software and hardware management processes are determined to be in the process initialization completed state, and they return their own states to the data management process. After the data management process determines that both the software and hardware risk control processes are in the process initialization completed state, it adjusts its own state to the process initialization completed state.

[0055] In the above scheme, the process-based state adjustment ensures that all relevant processes are initialized and ready before risk control calculations are performed, thus achieving orderly process operation and reducing the possibility of anomalies during risk control calculations.

[0056] In some embodiments of this disclosure, sending the first auto-incrementing identifier to the main risk control process includes: sending the message to be detected and the first auto-incrementing identifier to the main risk control process, so that if the main risk control process determines that the messages are continuous according to the first auto-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.

[0057] The preset risk control logic can be pre-set rules for risk control. 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. This preset risk control logic can be adjusted according to user needs, etc., and this embodiment does not impose any restrictions. 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, which can include prohibition, approval, or warning.

[0058] In this embodiment, the data management process can send a first auto-incrementing identifier and the message to be detected to the main risk control process. The main risk control process can identify the previous message received before the message to be detected as the previous message and the auto-incrementing identifier corresponding to the previous message as the previous auto-incrementing identifier. The main risk control process can determine whether the first auto-incrementing identifier is the next identifier after the previous auto-incrementing identifier according to the auto-incrementing order of the identifiers. If so, it means that no message loss 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 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 this 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 persistently storing 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 after detecting the message to be detected, and store the message to be detected and its corresponding first detection result in a preset storage unit.

[0061] In related technologies, only the messages transmitted from the target system to the risk control server are backed up, but 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 used later, which is more suitable for scenarios of risk control of high-frequency data.

[0062] Figure 4 This is a flowchart illustrating another message recovery method for a risk control server provided in this disclosure embodiment, as shown below. Figure 4 As shown in some embodiments of this disclosure, the method further includes:

[0063] Step 401: In response to the recovery operation of the software risk control process and the hardware risk control process, obtain the second resume identifier corresponding to the detected message in persistent storage; wherein, the second resume identifier is the latest auto-incrementing identifier corresponding to the detected message.

[0064] The recovery operation can be the process restarting operation after a process exception; this recovery operation can be understood as a post-disaster restart operation. The detected message can be a message indicating that the risk control server has completed risk control detection. If a message to be detected has already completed risk control detection, then that message can be understood as a detected message. The second detection result can be the detection result corresponding to the detected message. The second resume identifier is the latest one among the second auto-incrementing identifiers corresponding to the detected message. The second auto-incrementing identifier can be the auto-incrementing identifier corresponding to the detected message.

[0065] In this embodiment, in the event of a disaster affecting the entire risk control server, or a simultaneous disaster affecting both the software and hardware risk control processes, recovery operations need to be performed on both processes. In response to this recovery operation, the data management process retrieves multiple detected messages stored in a preset storage unit and determines the latest second auto-incrementing identifier from among the multiple second auto-incrementing identifiers corresponding to these detected messages as the second resume identifier.

[0066] In some embodiments of this disclosure, obtaining the second resume identifier corresponding to the detected message in persistent storage includes: if the server status of the risk control server is in the disk state, then obtaining the second resume identifier corresponding to the detected message in persistent storage; wherein, the disk state indicates that the process status of the data management process, the software risk control process, and the hardware risk control process is in the process initialization completed state, and the data management process has received the ready message sent by the target system.

[0067] In this embodiment, in response to the recovery operation of the software risk control process and the hardware risk control process, the data management process first determines whether the risk control server is in a "disk in progress" state. If so, it means that the anomaly occurred during the risk control process, and subsequent message retransmission is performed. If not, it means that the anomaly did not occur during the risk control process, and subsequent message transmission proceeds normally without message retransmission. This avoids invalid message retransmission.

[0068] Step 402: Determine the target external identifier corresponding to the second resume identifier, and send the target external identifier to the target system so that the target system can determine the external resume message based on the target external identifier.

[0069] The target external identifier can be the external identifier corresponding to the second continuation identifier outside the risk control server. Understandably, the auto-incrementing identifier is a unique and time-sequential identifier used internally by the risk control server, while the external identifier can be a unique identifier used by the risk control server and its external systems. This external identifier can be a sequence number without time sequence, and the external identifier and the auto-incrementing identifier can be in one-to-one correspondence. In this embodiment, the message simultaneously possesses both an auto-incrementing identifier and an external identifier, thus adding an auto-incrementing identifier representing the message order to the existing external identifiers that distinguish messages, creating a foundation for sequential detection of the messages to be detected. Optionally, the auto-incrementing identifier can be a numeric type, and the external identifier can be a string type. The external continuation message can be a message that requires further risk control processing based on messages that have already undergone risk control processing by the risk control server. This external continuation message can be understood as a breakpoint in the message transmission process between the risk control server and the target system.

[0070] In this embodiment, the messages sent by the target system have corresponding external identifiers used both inside and outside the risk control server. The data management process configures an auto-incrementing identifier for each message used internally within the risk control server. Each message also has a corresponding external identifier and an auto-incrementing identifier. In this embodiment, after the data management process determines the second continuation identifier, since this second continuation identifier is used internally by the risk control server, it needs to determine the target external identifier corresponding to this second continuation identifier based on the identifier relationship, and then send the target external identifier to the target system. The identifier relationship can record the mapping relationship between the auto-incrementing identifier and the external identifier.

[0071] In some embodiments of this disclosure, the message recovery method of the risk control server further includes: obtaining persistently stored detected messages and corresponding second detection results; sending the detected messages and 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 risk control calculation preprocessing based on the detected messages and the second detection results.

[0072] The second detection result can be the detection result corresponding to the already detected message.

[0073] In this embodiment, when the risk control server restarts after a disaster or when both risk control processes need to restart after a disaster, the data management process obtains persistent data. This persistent data may include server status, detected messages, second detection results, and a second auto-incrementing identifier. The data management process can determine whether the server status is in a "disk recovery" state. If so, it indicates that post-disaster data recovery is required. The data management process can 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. This preprocessing result enables subsequent risk control calculations, bringing the calculation process forward, reducing the computational load required for subsequent risk control calculations, and improving risk control efficiency.

[0074] Furthermore, after data recovery is completed in both the software and hardware risk control processes, the data management process can determine a second resume identifier based on the second auto-incrementing identifier in the persistent data and send this identifier to the target system. The target system then uses this identifier to determine the external resume message and continues message transmission from the target system to the risk control server. This achieves data recovery within the post-disaster risk control process and message resumption between the target system and the risk control server, restoring post-disaster risk control processing both internally and externally. This ensures the normal operation of risk control processing and improves the stability of the risk control server.

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

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

[0077] In the above scheme, when both the software risk control process and the hardware risk control process need to be restored after a disaster, the message transmission between the target system and the risk control server continues based on the second resume identifier corresponding to the message in persistent storage. This achieves accurate determination of the message transmission endpoint after a disaster and improves message integrity after a failure.

[0078] In some embodiments of this disclosure, the message recovery method of the risk control server further includes: in response to the recovery operation of the software risk control process or the hardware risk control process, determining the software risk control process or the hardware risk control process as a backup risk control process; sending the detected message and the second detection result corresponding to the detected message to the backup risk control process, so that the backup risk control process performs risk control calculation preprocessing based on the detected message and the second detection result.

[0079] In this embodiment, if the software risk control process requires a post-disaster restart while the hardware risk control process remains normal, a recovery operation is performed on the software risk control process. In this case, the software risk control process restarts as a backup, while the hardware risk control process acts as the primary process. The data management process responds to this recovery operation by retrieving detected messages and their corresponding second detection results from persistent data, and sends both the detected messages and the second detection results to the software risk control process. The software risk control process then performs preprocessing for subsequent risk control calculations based on the received detected messages and second detection results.

[0080] If the hardware risk control process requires a post-disaster restart, but the software risk control process is functioning normally, a recovery operation is performed on the hardware risk control process. In this scenario, the hardware risk control process restarts as a backup, while the software risk control process acts as the primary process. The data management process responds to this recovery operation by retrieving detected messages and their corresponding second detection results from persistent data, and then sending both to the hardware risk control process. The hardware risk control process then performs preprocessing for subsequent risk control calculations based on the received detected messages and second detection results.

[0081] In the above solution, if one risk control process needs to be restarted after a disaster, and the other risk control process is running normally, the restarted risk control process will be started as a backup risk control process. At this point, data recovery for the backup risk control process needs to be considered. The data management process sends the detected messages and their corresponding second detection results to the backup risk control process for data recovery. This achieves data recovery in the backup risk control process, providing data support for the subsequent switch from the backup risk control process to the primary risk control process.

[0082] The message recovery method for a risk control server provided in this disclosure introduces an auto-incrementing numerical identifier, improving the performance of FPGA in comparing message identifiers. Based on this auto-incrementing identifier, it enables the determination of message continuity. Furthermore, the auto-incrementing identifier is mapped and bound to an external identifier of string type, allowing for querying identifier relationships and identifying the corresponding external identifier, thus laying the foundation for post-disaster recovery. The auto-incrementing identifier used internally by this risk control server supports hardware-based functions such as message loss detection, lost message location, and breakpoint resumption, improving data security and ensuring messages are not duplicated, missing, or lost, and are in the correct order. It enables data retransmission in case of data loss, ensuring that data is not lost or duplicated during the operation of both hardware and software risk control processes, solving the message loss problem when processing high-frequency messages in business processing processes. Through process and server status management functions, processes and servers are made ready to work in sequence, without confusion of responsibilities at each stage.

[0083] Furthermore, the auto-incrementing identifier is a numerical type, which allows for faster reading compared to string comparisons, thus improving the feasibility and performance of sequential identification comparison using hardware such as FPGAs. Moreover, by persistently storing the detected messages, the second detection result, and the second auto-incrementing identifier, rapid recovery of historical data is achieved during post-disaster restarts. Through breakpoint detection and data recovery in data transmission between the risk control server and the target system, the continuation of upstream data transmission after a post-disaster system restart is realized.

[0084] Figure 5 This is a schematic diagram of a message recovery device for a risk control server provided in this embodiment. The message recovery device for the risk control server can be understood as the aforementioned electronic device or a functional module within the aforementioned electronic device. The device is applied to the data management process in a 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, while 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:

[0085] The request module 501 is used to obtain the message to be detected, configure a first auto-incrementing identifier for the message to be detected, and send the first auto-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 auto-incrementing identifier, it sends a data continuation request to the data management process; wherein, the main risk control process is the software risk control process or the hardware risk control process.

[0086] The data continuation module 502 is used to receive the data continuation request returned by the main risk control process, determine an internal continuation message based on the data continuation request, and send the internal continuation message to the main risk control process.

[0087] Optionally, the data continuation request includes a first continuation identifier corresponding to the main risk control process, wherein the first continuation identifier is the latest auto-increment identifier among the consecutive auto-increment identifiers received by the main risk control process, and the step of determining the internal continuation message based on the data continuation request includes:

[0088] Among multiple candidate messages, the candidate message whose candidate auto-incrementing identifier is in the order of the first resume identifier is determined as the internal resume message.

[0089] Optionally, sending the first auto-incrementing identifier to the main risk control process includes:

[0090] The message to be detected and the first auto-incrementing identifier are sent to the main risk control process, so that if the main risk control process determines that the messages are continuous according to the first auto-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 also includes:

[0092] The persistence module is used to receive the first detection result returned by the main risk control process and to persistently store 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] The first acquisition module is used to acquire a second resume identifier corresponding to the detected message that is persistently stored in response to the recovery operation of the software risk control process and the hardware risk control process; wherein, the second resume identifier is the latest auto-incrementing identifier corresponding to the detected message;

[0095] The first sending module is used to determine the target external identifier corresponding to the second resume identifier, and send the target external identifier to the target system so that the target system can determine the external resume message based on the target external identifier;

[0096] The receiving module is used to receive the external resume message returned by the target system.

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

[0098] If the server status of the risk control server is in the disk state, then the second resume identifier corresponding to the detected message in persistent storage is obtained; wherein, the disk state indicates that the process status of the data management process, the software risk control process, and the hardware risk control process is in the process initialization completed state, and the data management process receives the ready message sent by the target system.

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

[0100] The second acquisition module is used to acquire the persistently stored detected message and the second detection result corresponding to the detected message;

[0101] The second sending module is used 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 can perform risk control calculation preprocessing based on the detected message and the second detection result.

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

[0103] The determination module is used to determine the software risk control process or the hardware risk control process as a backup risk control process in response to the recovery operation of the software risk control process or the hardware risk control process.

[0104] The third sending module is used to send the detected message and the second detection result corresponding to the detected message to the backup risk control process, so that the backup risk control process can perform risk control calculation preprocessing based on the detected message and the second detection result.

[0105] Optionally, the server status of the risk control server includes server initialization status, server initialization completed status, in-system status, and terminated status.

[0106] Optionally, the server initialization completion status 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 establishes heartbeats with the software risk control process and the hardware risk control process respectively.

[0107] The apparatus provided in this embodiment can execute the methods of any of the above embodiments, and its execution method and beneficial effects are similar, so they will not be described again here.

[0108] This disclosure also provides an electronic device, which includes: a memory storing a computer program; and a processor for executing the computer program, wherein when the computer program is executed by the processor, it can implement the methods of any of the above embodiments.

[0109] Example, Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. See below for details. Figure 6The diagram illustrates a structural schematic suitable for implementing the electronic device 600 in the embodiments of this disclosure. The electronic device 600 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0110] like Figure 6 As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. Processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0111] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0112] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0113] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A 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 thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0114] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0115] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0116] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the following: it acquires a message to be detected, configures a first auto-incrementing identifier for the message to be detected, and sends the first auto-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 auto-incrementing identifier, it sends a data continuation request to the data management process; wherein the main risk control process is the software risk control process or the hardware risk control process; it receives the data continuation request returned by the main risk control process, determines an internal continuation message based on the data continuation request, and sends the internal continuation message to the main risk control process.

[0117] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0119] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0120] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0121] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, 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 machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0122] This disclosure also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the methods of any of the above embodiments. The execution method and beneficial effects are similar, and will not be described again here.

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

[0124] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A message recovery method of a risk control server, applied to a data management process in the risk control server, the risk control server comprising a central processing unit (CPU) and a field programmable gate array (FPGA), the CPU being deployed with the data management process and a software risk control process, the FPGA being deployed with a hardware risk control process, the software risk control process and the hardware risk control process being primary and backup to each other, the method comprising: obtaining a to-be-detected message, configuring a first self-incrementing identifier for the to-be-detected message, and sending the first self-incrementing identifier to a primary risk control process, so that the primary risk control process determines whether message loss occurs according to the first self-incrementing identifier, and sends a data retransmission request to the data management process if message loss occurs; wherein the primary risk control process is the software risk control process or the hardware risk control process, the data retransmission request comprises a first retransmission identifier corresponding to the primary risk control process, and the first retransmission identifier is the latest self-incrementing identifier among the self-incrementing identifiers received by the primary 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; wherein the step of determining the internal retransmission message based on the data retransmission request comprises: in a plurality of candidate messages, determining a candidate message whose candidate self-incrementing identifier is in sequence after the first retransmission identifier as the internal retransmission message.

2. The method of claim 1, wherein, The step of sending the first self-incrementing identifier to the primary risk control process comprises: sending the to-be-detected message and the first self-incrementing identifier to the primary risk control process, so that the primary risk control process determines a first detection result corresponding to the to-be-detected message according to a preset risk control logic if it is determined that the messages are continuous according to the first self-incrementing identifier, and sends the first detection result to the data management process. Correspondingly, the method further comprises: receiving the first detection result returned by the primary risk control process, and performing persistent storage processing on the first detection result and the to-be-detected message.

3. The method of claim 1, wherein, The to-be-detected message is a message sent by a target system to the data management process, and the method further comprises: in response to a recovery operation on the software risk control process and the hardware risk control process, obtaining a second retransmission identifier corresponding to a detected message stored persistently; wherein the second retransmission identifier is the latest self-incrementing identifier corresponding to the detected message; determining a target external identifier corresponding to the second retransmission identifier, and sending the target external identifier to the target system, so that the target system determines an external retransmission message according to the target external identifier; receiving the external retransmission message returned by the target system.

4. The method of claim 3, wherein, The step of obtaining the second retransmission identifier corresponding to the detected message stored persistently comprises: if a server state of the risk control server is an in-disk state, obtaining the second retransmission identifier corresponding to the detected message stored persistently; wherein the in-disk state represents that process states of the data management process, the software risk control process, and the hardware risk control process are process initialization completion states, and the data management process receives a ready message sent by the target system.

5. The method of claim 3, wherein, The method further comprises: acquiring the detected message and the second detection result corresponding to the detected message stored persistently; sending 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 risk control calculation preprocessing according to the detected message and the second detection result.

6. The method of claim 1, wherein, The method further comprises: 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 a backup risk control process; sending the detected message and the second detection result corresponding to the detected message to the backup risk control process, so that the backup risk control process performs risk control calculation preprocessing according to the detected message and the second detection result.

7. The method of claim 1, wherein, The server state of the risk control server includes a server initialization state, a server initialization completion state, a disk state, and an end state.

8. The method of claim 7, wherein, The server initialization completion state indicates 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 acquires the first preset risk control logic, the hardware risk control process completes the establishment of the third shared memory and acquires the second preset risk control logic, and the data management process establishes a heartbeat with the software risk control process and the hardware risk control process, respectively.

9. A message recovery device of a risk control server, applied to a data management process in a risk control server, the risk control server comprising a central processing unit (CPU) and a field programmable gate array (FPGA), the CPU being deployed with the data management process and a software risk control process, the FPGA being deployed with a hardware risk control process, the software risk control process and the hardware risk control process being primary and backup to each other, and the device comprising: a request module configured to acquire a to-be-detected message, configure a first self-incrementing identifier for the to-be-detected message, and send the first self-incrementing identifier to a primary risk control process, so that the primary risk control process determines whether message loss occurs according to the first self-incrementing identifier, and sends a data resumption request to the data management process if message loss occurs; wherein the primary risk control process is the software risk control process or the hardware risk control process, the data resumption request comprises a first resumption identifier corresponding to the primary risk control process, and the first resumption identifier is the latest self-incrementing identifier among continuous self-incrementing identifiers received by the primary risk control process; a resumption module configured to receive the data resumption request returned by the primary risk control process, determine an internal resumption message based on the data resumption request, and send the internal resumption message to the primary risk control process; wherein the determination of the internal resumption message based on the data resumption request comprises: in a plurality of candidate messages, determining a candidate message whose candidate self-incrementing identifier is in sequence after the first resumption identifier as the internal resumption message.

10. An electronic device, comprising: comprising: a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the method of any one of claims 1-8.

11. A computer readable storage medium, characterized in that, The storage medium has stored therein a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1-8 is implemented.

Images