Distributed system risk monitoring method and device, electronic equipment and storage medium

Abstract

The invention provides a distributed system risk monitoring method and device, electronic equipment and a storage medium, and the method comprises the steps: receiving a risk rule of a target service sent by a client, storing the risk rule in a database and a message queue, synchronizing the risk rule to each distributed node for risk management and control through the message queue, and then carrying out risk management and control through the distributed nodes; the method comprises the steps of receiving a risk assessment request of a target service, allocating distributed nodes to perform risk assessment on the risk assessment request based on a risk rule, determining a decision result of the risk assessment request, and updating the risk rule on any distributed node under the condition that the decision result of any distributed node is abnormal. Therefore, distributed risk monitoring is realized, the flexibility of the system is improved, and the accuracy and efficiency of risk monitoring are further improved.

Description

Technical Field

[0001] The present application relates to the field of risk monitoring technology, and in particular to a distributed system risk monitoring method, device, electronic device and storage medium. Background Art

[0002] As Internet technologies advance at a rapid pace, distributed systems are becoming increasingly critical due to their outstanding performance in processing massive amounts of data and ensuring high availability of services. However, current risk rule engines are still mainly deployed on single machines or in centralized environments, and are still insufficient in adapting to distributed architectures.

[0003] In order to cope with the growing demand for data processing and service stability requirements, a distributed system risk monitoring method is urgently needed to improve the performance of risk monitoring. Summary of the invention

[0004] The present application aims to solve one of the technical problems in the related art at least to some extent.

[0005] To this end, the first purpose of the present application is to propose a distributed system risk monitoring method to achieve distributed system risk monitoring, thereby improving risk monitoring performance.

[0006] The second objective of the present application is to provide a distributed system risk monitoring device.

[0007] The third objective of the present application is to provide an electronic device.

[0008] A fourth objective of the present application is to provide a computer-readable storage medium.

[0009] A fifth object of the present application is to provide a computer program product.

[0010] To achieve the above-mentioned purpose, the first embodiment of the present application proposes a distributed system risk monitoring method, including:

[0011] Receive the risk rules of the target business sent by the client, and save the risk rules in the database and message queue, so as to synchronize the risk rules to each distributed node of risk management through the message queue;

[0012] Receive a risk assessment request for a target business, and assign distributed nodes to perform risk assessment on the risk assessment request based on risk rules, and determine a decision result of the risk assessment request;

[0013] In the event that the decision result of any distributed node is abnormal, the risk rules are updated on any distributed node.

[0014] To achieve the above-mentioned purpose, the second embodiment of the present application proposes a distributed system risk monitoring device, including:

[0015] The synchronization module is used to receive the risk rules of the target business sent by the client, and save the risk rules in the database and message queue, so as to synchronize the risk rules to each distributed node of risk management and control through the message queue;

[0016] A risk monitoring module is used to receive a risk assessment request of a target business, and allocate distributed nodes to perform risk assessment on the risk assessment request based on risk rules, and determine a decision result of the risk assessment request;

[0017] The node monitoring module is used to update the risk rules on any distributed node when the decision result of any distributed node is abnormal.

[0018] To achieve the above-mentioned purpose, the third aspect of the present application provides an electronic device, including:

[0019] at least one processor; and

[0020] a memory communicatively connected to at least one processor; wherein,

[0021] The memory stores instructions that can be executed by at least one processor. The instructions are executed by the at least one processor so that the at least one processor can execute the method of the above embodiment.

[0022] To achieve the above objectives, the fourth aspect of the present application proposes a computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the method according to the above embodiment.

[0023] To achieve the above objectives, the fifth aspect of the present application proposes a computer program product, including a computer program, which implements the method of the above embodiment when executed by a processor.

[0024] The distributed system risk monitoring method, device, electronic device and storage medium provided by the present application receive the risk rules of the target business sent by the client, and save the risk rules in the database and message queue, so as to synchronize the risk rules to each distributed node of risk management through the message queue, and then receive the risk assessment request of the target business, and allocate distributed nodes to perform risk assessment on the risk assessment request based on the risk rules, determine the decision result of the risk assessment request, and update the risk rules on any distributed node when the decision result of any distributed node is abnormal. In this way, distributed risk monitoring is realized. In addition, it supports users to set risk rules, and synchronizes the risk rules to each distributed node for processing risk assessment requests. It overcomes the problem that the hard-coded method is adopted, and the rule changes need to modify the system code, resulting in poor flexibility of the system and the inability to quickly adapt to changes in business needs. The flexibility of the system is improved, thereby improving the accuracy and efficiency of risk monitoring.

[0025] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0027] Figure 1 A schematic diagram of a distributed system risk monitoring method provided in an embodiment of the present application;

[0028] Figure 2 A flow chart of another distributed system risk monitoring method provided in an embodiment of the present application;

[0029] Figure 3 A schematic diagram of the structure of a distributed system risk monitoring device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0031] Traditional risk rule engines often use hard coding, and rule changes require modifying system code, resulting in poor system flexibility and inability to quickly adapt to business changes. This application designs a flexible risk rule configuration and management synchronization mechanism to enable users to quickly adjust rule strategies according to business needs without modifying system code.

[0032] The following describes the distributed system risk monitoring method and device according to the embodiments of the present application with reference to the accompanying drawings.

[0033] The distributed system risk monitoring method of the embodiment of the present application is executed by the distributed system risk monitoring device (hereinafter referred to as the monitoring device) provided in the embodiment of the present application. The device can be configured in a computer device or a terminal device to realize distributed system risk monitoring.

[0034] Figure 1 A flow chart of a distributed system risk monitoring method provided in an embodiment of the present application.

[0035] like Figure 1 As shown, the distributed system risk monitoring method includes the following steps:

[0036] Step 101, receiving the risk rules of the target business sent by the client, and saving the risk rules in the database and the message queue, so as to synchronize the risk rules to each distributed node of risk management and control through the message queue.

[0037] In the present application, a rule template can be pre-set in the client system to support users to select a rule template to formulate risk rules for the target business based on the rule template. After the risk rules are formulated, they can be submitted to the monitoring device through the client. Thus, the monitoring device can receive the risk rules of the target business. Afterwards, the monitoring device can store the risk rules in association with the target business in the database to ensure the persistence of the risk rules and facilitate version control. In addition, the monitoring device can create a message queue in advance. Afterwards, when the risk rules of the target business are received, the risk rules can be synchronized and saved in the message queue, and the risk rules can be synchronized to each distributed node of risk management through the message queue. Thus, each distributed node can serve as the initiating node for synchronizing risk rules, and the risk rules can be pushed using the message queue. Other distributed nodes will obtain the risk rules as consumers, thereby ensuring the consistency of the risk rules of each distributed node and ensuring the reliability of risk monitoring. At the same time, using the message queue to synchronize the data of distributed nodes can reduce the use of distributed coordination components, simplify the system architecture, and make it easier to deploy.

[0038] Optionally, you can also pre-set functional components in the client. Users can drag and drop the required functional components to the workspace in the client interface and connect and configure them in a graphical way. The client analyzes the functional components in the workspace and their connection relationships, configurations, etc., generates risk rules and sends them to the monitoring device. This visual design makes rule making more intuitive and efficient.

[0039] Functional components refer to various preset modules or elements used to define risk rules. These components include but are not limited to the following types:

[0040] Conditional selection: allows users to specify specific conditional judgment criteria, such as numerical comparison (greater than, less than, equal to), text matching (contains, does not contain), date range, etc.

[0041] Logical operators: used to connect multiple conditions, such as "AND", "OR" and other logical operators, which can help users create compound conditional judgments.

[0042] Field Selector: Allows users to select the fields to be monitored or analyzed from the existing data fields.

[0043] Action triggers: define actions to be taken when certain conditions are met, such as sending an alert, blocking a transaction, recording a log, etc.

[0044] Rule template: A predefined set of rule combinations that have been set up for common scenarios and can be used directly or modified by users.

[0045] Parameter input box: allows users to set specific values ​​or other parameters for the rule.

[0046] Rule priority setting: allows users to specify the priority order of different rules to control the order in which the rules are executed.

[0047] Rule group management tool: helps users organize and manage rule sets, such as creating, deleting rule groups, or switching between different rule groups.

[0048] Therefore, the dynamic configuration mechanism can not only enable risk rules to respond quickly and adapt to changes in business needs, but also effectively reduce system downtime caused by risk rule adjustments, thereby reducing the maintenance cost of the risk monitoring system and improving operational efficiency.

[0049] Step 102: receiving a risk assessment request of a target business, and allocating distributed nodes to perform risk assessment on the risk assessment request based on risk rules, and determining a decision result of the risk assessment request.

[0050] In this application, when an external application generates a business request for a target business, a risk assessment request for the target business can be sent to the monitoring device. After receiving the risk assessment request, the monitoring device can dynamically allocate tasks according to the processing capacity and load of each distributed node to ensure efficient use of system resources. At the same time, the distributed architecture improves the scalability and fault tolerance of the system, and can cope with high concurrency scenarios and large data processing requirements.

[0051] In addition, the process of allocating distributed nodes to perform risk assessment on risk assessment requests based on risk rules can be as follows: the distributed nodes obtain risk rules from the multi-level cache, and at the same time, use concurrent technology and use any risk assessment method to perform risk assessment on risk assessment requests based on risk rules. Multi-core CPU resources are fully utilized to improve processing speed.

[0052] Distributed nodes can store risk rules that have been used in a preset period in a multi-level cache. Alternatively, by counting the historical records of risk rule calls in each cycle, the risk rules that are frequently used in each cycle are determined, and then the corresponding high-frequency risk rules are stored in the multi-level cache in each cycle. This can reduce repeated analysis and improve risk monitoring efficiency.

[0053] Among them, the multi-level cache includes the memory, redis, and database of the distributed node. It is understandable that the speed of obtaining data from the memory is the fastest. Obtaining data from redis consumes some IO, and the speed of obtaining data is slower than that from the memory. The speed of obtaining data from the database is the slowest.

[0054] Therefore, the process of a distributed node obtaining risk rules from a multi-level cache can be as follows: determine the risk rules associated with the target business through query. Then, query the cache in the memory to obtain detailed information of the risk rules. In the case of failure to obtain the risk rules from the cache, query redis to obtain detailed information of the risk rules. In the case of failure to obtain the risk rules in redis, query the database to obtain detailed information of the risk rules.

[0055] Step 103: when the decision result of any distributed node is abnormal, update the risk rules on any distributed node.

[0056] In this application, when a distributed node fails to obtain the risk rules associated with the control object, the risk rules on the distributed node may not be synchronized, and the decision result of the distributed node is determined to be abnormal. At this time, the risk rules can be re-updated on the distributed node to synchronize the risk rules on the distributed node.

[0057] Optionally, the client user performs query, modification, deletion and other operation settings on the risk rules. After the operation settings for the risk rules are completed, the client can generate an operation request for the risk rules and send it to the monitoring device. Thus, the monitoring device can receive the operation request for the risk rules. Among them, the operation request may include the operation type (the operation type includes query, modification, deletion, etc.), the risk rule identifier, etc. In the case where the operation type is a modification type, the operation request may also include the modified risk rules set by the user. After that, the monitoring device can perform the operation corresponding to the operation type on the risk rules in the database and / or message queue. For example, in the case where the operation type is a modification type, the monitoring device updates the corresponding risk rules in the database and / or message queue using the modified risk rules. In the case where the operation type is a deletion type, the monitoring device deletes the risk rules from the database and / or message queue. In the case where the operation type is a query type, the monitoring device obtains the risk rules from the database and feeds them back to the client for display. This facilitates the maintenance of risk rules.

[0058] In this application, the risk rules of the target business sent by the client are received, and the risk rules are saved in the database and the message queue, so that the risk rules are synchronized to each distributed node of risk management through the message queue. After that, the risk assessment request of the target business is received, and the distributed nodes are allocated to perform risk assessment on the risk assessment request based on the risk rules, and the decision result of the risk assessment request is determined. When the decision result of any distributed node is abnormal, the risk rules are updated on any distributed node. In this way, distributed risk monitoring is realized. In addition, it supports users to set risk rules, and synchronizes the risk rules to each distributed node for processing risk assessment requests. It overcomes the problem that the hard-coded method is adopted, and the rule changes need to modify the system code, resulting in poor flexibility of the system and the inability to quickly adapt to changes in business needs. The flexibility of the system is improved, thereby improving the accuracy and efficiency of risk monitoring.

[0059] Figure 2 A flow chart of a distributed system risk monitoring method provided in an embodiment of the present application.

[0060] like Figure 2 As shown, the distributed system risk monitoring method includes the following steps:

[0061] Step 201, receiving the risk rules of the target business sent by the client, and saving the risk rules in the database and the message queue, so as to synchronize the risk rules to each distributed node of risk management and control through the message queue.

[0062] Step 202: Receive a risk assessment request for a target business, and assign distributed nodes to perform risk assessment on the risk assessment request based on risk rules to determine a decision result of the risk assessment request.

[0063] Step 203: when the decision result of any distributed node is abnormal, update the risk rules on any distributed node.

[0064] In the present application, the specific implementation process of step 201-step 202 can be found in the detailed description of any embodiment of the present application, and will not be repeated here.

[0065] Step 204: Obtain the update log of each risk rule on each distributed node at a preset time interval.

[0066] In this application, when a distributed node updates a risk rule, it can generate an update log. The update log contains the identification and version information of the currently saved risk rule, etc., wherein the identification of the risk rule can be any information used to uniquely identify the risk rule, such as the name of the risk rule, and this application does not limit this.

[0067] Step 205 , matching the update logs of each risk rule on each distributed node, determining the unsynchronized distributed nodes among the distributed nodes, and updating the risk rules on the unsynchronized distributed nodes.

[0068] Therefore, by monitoring the risk rules on each distributed node, it is possible to promptly discover unsynchronized distributed nodes and potential risks, thereby ensuring the consistency of risk rules on each distributed node and improving the efficiency and accuracy of risk monitoring.

[0069] In this application, the risk rules of the target business sent by the client are received, and the risk rules are saved in the database and the message queue, so that the risk rules are synchronized to each distributed node of risk management through the message queue. After that, the risk assessment request of the target business is received, and the distributed nodes are assigned to perform risk assessment on the risk assessment request based on the risk rules, and the decision result of the risk assessment request is determined. In the case that the decision result of any distributed node is abnormal, the risk rules are updated on any distributed node. At the same time, the update log of each risk rule on each distributed node is obtained at a preset time interval, and the update log of each risk rule on each distributed node is matched to determine the unsynchronized distributed nodes in the distributed nodes, and the risk rules are updated on the unsynchronized distributed nodes. Therefore, by monitoring the risk rules on each distributed node, it is possible to timely discover unsynchronized distributed nodes and potential risks, thereby ensuring the consistency of risk rules on each distributed node and improving the efficiency and accuracy of risk monitoring.

[0070] In order to implement the above embodiments, the present application also proposes a distributed system risk monitoring device.

[0071] Figure 3 A schematic diagram of the structure of a distributed system risk monitoring device provided in an embodiment of the present application.

[0072] like Figure 3 As shown, the distributed system risk monitoring device includes a synchronization module 310 , a risk monitoring module 320 , and a node monitoring module 330 .

[0073] The synchronization module 310 is used to receive the risk rules of the target business sent by the client, and save the risk rules in the database and the message queue, so as to synchronize the risk rules to each distributed node of risk management and control through the message queue;

[0074] The risk monitoring module 320 is used to receive a risk assessment request of a target business, and allocate distributed nodes to perform risk assessment on the risk assessment request based on risk rules, and determine a decision result of the risk assessment request;

[0075] The node monitoring module 330 is used to update the risk rules on any distributed node when the decision result of any distributed node is abnormal.

[0076] Furthermore, in a possible implementation of the embodiment of the present application, the risk monitoring module 320 is used to:

[0077] Distributed nodes obtain risk rules from multi-level caches;

[0078] Using concurrent technology, risk assessment requests are risk assessed based on risk rules.

[0079] Furthermore, in a possible implementation of the embodiment of the present application, the node monitoring module 330 is further configured to:

[0080] Obtain the update log of each risk rule on each distributed node at a preset time interval;

[0081] The update logs of each risk rule on each distributed node are matched, unsynchronized distributed nodes are determined, and the risk rules are updated on the unsynchronized distributed nodes.

[0082] Furthermore, in a possible implementation of the embodiment of the present application, the node monitoring module 330 is further configured to:

[0083] In the event that any distributed node fails to obtain the risk rules associated with the control object, it is determined that the decision result of any distributed node is abnormal.

[0084] Furthermore, in a possible implementation of the embodiment of the present application, an update module is also included, which is used to:

[0085] Receiving an operation request for a risk rule sent by a client, wherein the operation request includes an operation type, wherein the operation type includes query, modify, and delete;

[0086] Execute the operation corresponding to the operation type on the risk rule in the database and / or message queue.

[0087] It should be noted that the aforementioned explanation of the embodiment of the distributed system risk monitoring method is also applicable to the distributed system risk monitoring device of this embodiment, and will not be repeated here.

[0088] In this application, the risk rules of the target business sent by the client are received, and the risk rules are saved in the database and the message queue, so that the risk rules are synchronized to each distributed node of risk management through the message queue. After that, the risk assessment request of the target business is received, and the distributed nodes are allocated to perform risk assessment on the risk assessment request based on the risk rules, and the decision result of the risk assessment request is determined. When the decision result of any distributed node is abnormal, the risk rules are updated on any distributed node. In this way, distributed risk monitoring is realized. In addition, it supports users to set risk rules, and synchronizes the risk rules to each distributed node for processing risk assessment requests. It overcomes the problem that the hard-coded method is adopted, and the rule changes need to modify the system code, resulting in poor flexibility of the system and the inability to quickly adapt to changes in business needs. The flexibility of the system is improved, thereby improving the accuracy and efficiency of risk monitoring.

[0089] In order to implement the above embodiments, the present application also proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided by the above embodiments.

[0090] In order to implement the above embodiments, the present application also proposes a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the methods provided by the above embodiments.

[0091] In order to implement the above embodiments, the present application also proposes a computer program product, including a computer program, which implements the methods provided by the above embodiments when executed by a processor.

[0092] The collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in this application are in compliance with relevant laws and regulations and do not violate public order and good morals.

[0093] It should be noted that personal information from users should be collected for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. In addition, such collection / sharing should be carried out after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign the agreement / authorization including authorization of relevant user information before the user uses the function. In addition, any necessary steps should be taken to protect and safeguard access to such personal information data and ensure that others who have access to personal information data comply with its privacy policy and procedures.

[0094] This application is expected to provide an implementation scheme for users to selectively block the use or access of personal information data. That is, this application is expected to provide hardware and / or software to prevent or block access to such personal information data. Once the personal information data is no longer needed, risks can be minimized by limiting data collection and deleting data. In addition, when applicable, personal identifiers are removed from such personal information to protect the privacy of users.

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

[0096] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0097] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0098] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute the instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purpose of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0099] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0100] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0101] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0102] The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A distributed system risk monitoring method, characterized in that: The method comprises: Receive the risk rules of the target business sent by the client, and save the risk rules in the database and the message queue, so as to synchronize the risk rules to each distributed node of risk management and control through the message queue; receiving a risk assessment request for the target business, and assigning the distributed node to perform a risk assessment on the risk assessment request based on the risk rule, and determining a decision result of the risk assessment request; In the event that a decision result of any distributed node is abnormal, the risk rule is updated on the any distributed node.

2. The method according to claim 1, characterized in that The allocating the distributed node to perform risk assessment on the risk assessment request based on the risk rule includes: The distributed node obtains the risk rule from a multi-level cache; The risk assessment request is subjected to risk assessment based on the risk rule by using concurrent technology.

3. The method according to claim 1, characterized in that Also includes: Obtaining an update log of each risk rule on each of the distributed nodes at a preset time interval; The update logs of the risk rules on each of the distributed nodes are matched, unsynchronized distributed nodes among the distributed nodes are determined, and the risk rules are updated on the unsynchronized distributed nodes.

4. The method according to claim 1, characterized in that Also includes: In the event that any distributed node fails to obtain the risk rule associated with the control object, it is determined that the decision result of any distributed node is abnormal.

5. The method according to claim 1, characterized in that Also includes: Receiving an operation request for the risk rule sent by a client, wherein the operation request includes an operation type, wherein the operation type includes query, modify, and delete; An operation corresponding to the operation type is performed on the risk rules in the database and / or the message queue.

6. A distributed system risk monitoring device, characterized in that: The device comprises: A synchronization module, used to receive the risk rules of the target business sent by the client, and save the risk rules in the database and the message queue, so as to synchronize the risk rules to each distributed node of risk management and control through the message queue; A risk monitoring module, configured to receive a risk assessment request of the target business, and allocate the distributed nodes to perform risk assessment on the risk assessment request based on the risk rules, and determine a decision result of the risk assessment request; The node monitoring module is used to update the risk rules on any distributed node when the decision result of any distributed node is abnormal.

7. The device according to claim 6, characterized in that The risk monitoring module is used to: The distributed node obtains the risk rule from a multi-level cache; The risk assessment request is subjected to risk assessment based on the risk rule by using concurrent technology.

8. The device according to claim 6, characterized in that The node monitoring module is also used for: Obtaining an update log of each risk rule on each of the distributed nodes at a preset time interval; The update logs of the risk rules on each of the distributed nodes are matched, unsynchronized distributed nodes among the distributed nodes are determined, and the risk rules are updated on the unsynchronized distributed nodes.

9. The device according to claim 6, characterized in that The node monitoring module is also used for: In the event that any distributed node fails to obtain the risk rule associated with the control object, it is determined that the decision result of any distributed node is abnormal.

10. The device according to claim 6, characterized in that Also includes update modules for: Receiving an operation request for the risk rule sent by a client, wherein the operation request includes an operation type, wherein the operation type includes query, modify, and delete; An operation corresponding to the operation type is performed on the risk rules in the database and / or the message queue.

11. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 5.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 5 when executed by a processor.

13. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 5 when being executed by a processor.

Images