Method and system for version switching of risk control rules, and electronic device

Abstract

This invention relates to the field of distributed systems, providing a method, system, and electronic device for version switching of risk control rules. The method includes: obtaining rule parameters of a first risk control rule in the distributed system; merging the rule parameters of the first risk control rule with the rule parameters of a second risk control rule to obtain a full set of rules; loading the full set of rules onto each node of the distributed system; and having each node asynchronously destroy a pre-stored second risk control rule and then reload the rule parameters of the first risk control rule to complete the version switching. This invention addresses the shortcomings of related technologies, such as asynchronous dual-engine mapping, unstable intermediate services, and low efficiency of centralized switching. The solution provided in this application can adapt to distributed architectures, support asynchronous node evolution, and ensure intermediate compatibility.

Description

Technical Field

[0001] This invention relates to the field of distributed systems technology, and in particular to a method, system, and electronic device for switching versions of risk control rules. Background Technology

[0002] In certain uninterrupted business scenarios, risk control systems need to possess extremely high availability and real-time response capabilities. Current mainstream architectures adopt a three-layer separation design: "business system + risk control engine + decision flow engine." The risk control engine is responsible for business semantic parsing and parameter extraction; the decision flow engine is responsible for executing general rule logic; the two are bound together through "scenario interfaces" and "decision flow IDs," achieving decoupling between business logic and risk control logic.

[0003] However, in actual operation and maintenance, frequent iterations of risk control strategies (such as responding to new types of fraudulent behavior and adjusting regional risk control thresholds) require the system to support seamless, uninterrupted, and high-frequency rule version switching. Existing solutions face the following core challenges: Asynchronous mapping between the two engines: After the risk control engine updates the parameter extraction rules, if the decision flow node has not yet loaded the new instance, a mismatch of "new parameters + old instance" or "old parameters + new instance" may occur, resulting in execution abnormalities.

[0004] Intermediate state service instability: Due to the independent deployment and varying loading speeds of decision flow nodes, an intermediate state exists during the switchover process, where "some nodes are new and some are old." If all variables are not passed through, old nodes may lack new parameters, and new nodes may lack old parameters, causing service interruption.

[0005] Centralized switching is inefficient: Traditional solutions require all nodes to be loaded before the mapping is switched uniformly, which not only prolongs the switching window, but also allows a single point of failure to block the global switching, affecting the switching success rate.

[0006] Therefore, there is an urgent need for a smooth switching mechanism for risk control rules that is compatible with distributed architecture, supports asynchronous node evolution, and ensures compatibility of intermediate states. Summary of the Invention

[0007] This invention provides a method, system, and electronic device for switching versions of risk control rules, in order to solve the defects of asynchronous dual-engine mapping, unstable intermediate services, and low efficiency of centralized switching in related technologies. The solution of this application can adapt to distributed architecture, support asynchronous node evolution, and ensure intermediate compatibility.

[0008] This invention provides a method for switching versions of risk control rules, including: Obtain the rule parameters of the first risk control rule in the distributed system; The rule parameters of the first risk control rule and the rule parameters of the second risk control rule are merged to obtain the full set of rules; The full set of rules is loaded into each node of the distributed system; After the nodes of the distributed system asynchronously destroy the pre-stored second risk control rule, they reload the rule parameters of the first risk control rule to complete the version switch.

[0009] According to the method for version switching of risk control rules provided by the present invention, the step of loading the full set of rules to each node of the distributed system includes: Using the scenario interface of the distributed system as the key, the full set of rules is written to Redis; The application risk control engine extracts the variables from the full set of rules and encapsulates them into a hash map; Based on the hash map, the full set of rules is loaded into each node of the distributed system.

[0010] According to the method for version switching of risk control rules provided by the present invention, after loading the full set of rules to each node of the distributed system, the method further includes: Receive business processing requests; Based on the routing node corresponding to the business processing request, the first risk control rule or the second risk control rule in the full set of rules is used for processing.

[0011] According to the method for switching versions of risk control rules provided by the present invention, the Redis expires after a set time.

[0012] According to the method for switching versions of risk control rules provided by the present invention, the step of reloading the rule parameters of the first risk control rule to complete the version switching includes: After the Redis expires, the application risk control engine retrieves the rule parameters of the first risk control rule again; After rewriting the Redis data, the version switch is completed.

[0013] According to the method for switching versions of risk control rules provided by the present invention, the distributed system is a distributed system of sports lottery.

[0014] This invention also provides a system for switching versions of risk control rules, applied to the above-mentioned method for switching versions of risk control rules, including: The rule acquisition module is used to acquire the rule parameters of the first risk control rule in the distributed system. The rule merging module is used to merge the rule parameters of the first risk control rule with the rule parameters of the second risk control rule to obtain the full set of rules; The rule loading module is used to load the full set of rules into each node of the distributed system; The version switching module involves the nodes of the distributed system asynchronously destroying the pre-stored second risk control rule and then reloading the rule parameters of the first risk control rule to complete the version switching.

[0015] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement any of the methods described above for switching versions of risk control rules.

[0016] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the methods described above for switching versions of risk control rules.

[0017] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements any of the methods described above for switching versions of risk control rules.

[0018] The method for switching versions of risk control rules provided by this invention can load the new version of the first risk control rule and the old version of the second risk control rule together onto the nodes of the distributed system. During the version switching process, an intermediate state can be generated in which the new version of the risk control rule and the old version of the risk control rule coexist. In this way, when there is a business processing request, the appropriate risk control rule can be selected according to the business processing request, avoiding the inability to process the business processing request due to the version switching of the risk control rule. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the method for switching versions of risk control rules provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the system for switching versions of risk control rules provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the physical structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0022] Several methods exist for updating risk control versions, such as the dual-engine centralized version management method. In this method, the risk control engine and the decision flow engine each maintain their own version information, variable names are manually defined, and the decision flow engine needs to wait for all nodes to load the new instance before adjusting the mapping relationship. However, this method has several drawbacks that prevent it from meeting specific needs, such as: Mapping adjustment is inefficient: it relies on global synchronization, has a long switching cycle, and the failure of a single node will block the entire switching process.

[0023] High implementation complexity: It requires real-time tracking of the loading status, health status and version consistency of each node, which significantly increases maintenance costs.

[0024] Based on this, this application provides a new method for switching versions of risk control rules, as shown below.

[0025] Figure 1 This is a flowchart illustrating the method for switching versions of risk control rules provided in an embodiment of the present invention.

[0026] like Figure 1 As shown in the figure, this embodiment provides a method for switching versions of risk control rules, including: Step 101: Obtain the rule parameters of the first risk control rule of the distributed system; Risk control rules refer to the risk control logic carriers that are bound to specific scenario interfaces, and have the following characteristics: One risk control rule can correspond to multiple versions, with only one designated as the "currently in use risk control rule version." Risk control rule versions represent different iterations of the same rule, and each version corresponds to a unique set of parameter extraction rules. When switching versions, the core change lies in the parameter extraction rules. Furthermore, the "currently in use risk control rule version" is the currently effective risk control rule version, and its corresponding parameter extraction rules are used for processing business requests in the production environment. Each risk control rule is uniquely bound to a single decision flow, enabling the decoupling and reuse of "customized business logic" and "general decision logic".

[0027] The scenario interface serves as the logical entry point between business scenarios and risk control rules (such as the "instant lottery QR code redemption interface" and the "lottery QR code verification interface"), and acts as the core index key for the mapping relationship.

[0028] The first risk control rule is the new version of the risk control rule. Obtaining the first risk control rule means loading the updated version of the risk control rule from the outside into the database.

[0029] Step 102: Merge the rule parameters of the first risk control rule with the rule parameters of the second risk control rule to obtain the full set of rules; The second risk control rule is an older version of the risk control rule, which is also the version of the risk control rule being used, meaning it has already been stored in the database, so it does not need to be retrieved again.

[0030] Step 103: Load the full set of rules into each node of the distributed system; In practical applications, the full set of rules can be written to Redis using the scenario interface of the distributed system as the key. This Redis can expire after a set time, for example, it can be set to expire after one minute. The application risk control engine extracts the variables from the full set of rules and encapsulates them into a hash map; Based on the hash map, the full set of rules is loaded into each node of the distributed system.

[0031] Redis refers to Redis caching, a distributed temporary storage system that uses "scenario interface" as the key to store a merged set of "scenario interface - parameter extraction rules" (during the transition period) or a new rule (after the transition is complete), with a 1-minute expiration time. The risk control engine prioritizes retrieving rules from Redis; if no rules are found, it retrieves rules from the source database and writes them back to the cache.

[0032] The Risk Control Engine is a distributed, business-specific module that maintains two key mapping relationships: "Scenario Interface → Decision Flow ID" "Scene Interface → Parameter Extraction Rules" The risk control engine retrieves the above mapping data from Redis or the database, extracts variables from the business request and assembles them into a hash map, calls the decision flow engine and receives the decision results returned by it.

[0033] A hashmap (Hashmap Variable Set) is a variable storage format extracted by the risk control engine. The key is a globally unique variable name, and the value is the corresponding business data. It supports the simultaneous transmission of variables from both new and old versions. Step 104: After the nodes of the distributed system asynchronously destroy the pre-stored second risk control rule, they reload the rule parameters of the first risk control rule to complete the version switch.

[0034] In practice, after the Redis expires, the risk control engine can be used to retrieve the rule parameters of the first risk control rule again. After rewriting the Redis data, the version switch is completed.

[0035] In an exemplary embodiment, after loading the full set of rules onto each node of the distributed system, the method further includes: Receive business processing requests; Based on the routing node corresponding to the business processing request, the first risk control rule or the second risk control rule in the full set of rules is used for processing.

[0036] This embodiment describes how to handle business processing requests when a distributed system is in an intermediate state. During the decision flow version switch, each node may be in an inconsistent state, either "new instance loaded" or "still running the old instance". At this stage, a mechanism of "full variable pass-through + globally unique variable naming" ensures that all nodes can execute normally without forced synchronization.

[0037] In this intermediate state, for example, when a business request arrives, if it is routed to a new node, the new risk control rules can be executed; if it is routed to an old node, the old risk control rules can be executed.

[0038] The following specific embodiment illustrates the method for switching versions of risk control rules provided by this application. The application scenario of this embodiment is the instant lottery QR code redemption scenario.

[0039] In this scenario, the scenario interface can be JK_DJ_001, the risk control rule R1 is switched from v1.0 to v2.0, the associated decision flow F1 is switched from v1.0 to v2.0, the v1.0 parameters are: v1.0_1=device ID, v1.0_2=reward amount, and the v2.0 parameters are: v2.0_1=reward amount, v2.0_2=cross-region identifier.

[0040] Updating a version may include the following steps: 1. Database update: Write the parameter extraction rules for v2.0; Update the "Version in Use" label for R1 and F1 to v2.0; Record the switch log (including version, variables, and operator).

[0041] 2. Redis refresh (merge set transition) Read the parameter rules of v1.0 and v2.0 from the DB and merge them into a full rule set (containing 4 variables). Write to Redis with key JK_DJ_001 and set an **1-minute expiration time**. After that, the risk control engine extracts all variables (v1.0_1, v1.0_2, v2.0_1, v2.0_2) and encapsulates them into a hash map.

[0042] 3. Independent loading and mapping adjustment of decision flow nodes Each node independently reads the new, currently used version v2.0 of F1 from the database; Load the component (including the placeholder {v2.0_2}) and generate a new instance F1_v2.0; Once loading is complete, the local mapping (F1→F1_v2.0) is adjusted immediately without waiting for other nodes; At this point, the system enters an intermediate state: some nodes are running the new instance, while others are still running the old instance.

[0043] 4. Adaptive processing of intermediate states After a business request arrives, the risk control engine transmits the full variable hash map. If the route is to a new node: the instance retrieves v2.0_1, and v2.0_2 executes the new logic; If the routing is to the old node: the instance retrieves v1.0_1, and v1.0_2 executes the old logic; The dependent variable is fully transmitted and its name is unique. There are no missing parameters in either type of node, and the service is unaffected.

[0044] 5. Asynchronous destruction of old instances Each node asynchronously destroys the F1_v1.0 instance in the background without blocking the processing of the current request; Avoid having new and old instances process the same request in parallel to prevent logical confusion.

[0045] 6. Redis expired, switchover complete. The Redis expires in 1 minute, and the risk control engine retrieves the new v2.0 rules from the source database (only v2.0_1 and v2.0_2 are included). Write the Redis variable backwards, and subsequent requests will only pass the new variable. All nodes have completed the mapping switch, and the system is fully running v2.0 logic.

[0046] The above methods for switching versions of risk control rules have the following beneficial effects: 1. Independent collaboration mechanism for decision flow nodes: Each node independently loads instances, adjusts mappings, and asynchronously destroys old instances, eliminating the need for centralized synchronization and avoiding single-point failures that block global switching.

[0047] 2. A globally unique variable naming mechanism is used, which uses "risk control rule version number + auto-incrementing natural number" to concatenate variable names (e.g., v2.0_1) to solve the problem of cross-version variable name conflicts.

[0048] 3. The intermediate state adaptive compatibility design, through "full transparent transmission of hash map + independent node mapping", enables both new and old instances to execute normally in the intermediate state, breaking through the limitations of traditional centralized synchronization.

[0049] 4. The dual-engine lightweight collaborative process strictly follows the five-step process of "DB update → Redis merging transition → independent node loading → asynchronous destruction → Redis expiration", without the need for complex protocols, and the switching is efficient and reliable.

[0050] 5. Redis's precise time-of-expiration matching mechanism accurately matches node loading time with a 1-minute expiration time, balancing intermediate state compatibility and resource efficiency, and avoiding premature switching or redundant occupation.

[0051] The system for switching versions of risk control rules provided by this invention is described below. The system for switching versions of risk control rules described below and the method for switching versions of risk control rules described above can be referred to in correspondence.

[0052] Figure 2 This is a schematic diagram of the system for switching versions of risk control rules provided in an embodiment of the present invention.

[0053] like Figure 2 As shown, the system for switching versions of risk control rules provided in this embodiment of the invention includes: The rule acquisition module 201 is used to acquire the rule parameters of the first risk control rule of the distributed system; The rule merging module 202 is used to merge the rule parameters of the first risk control rule with the rule parameters of the second risk control rule to obtain a complete set of rules; Rule loading module 203 is used to load the full set of rules into each node of the distributed system; Version switching module 204: After the nodes of the distributed system asynchronously destroy the pre-stored second risk control rule, they reload the rule parameters of the first risk control rule to complete the version switching.

[0054] Figure 3 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 3 As shown, the electronic device may include: a processor 310, a communication interface 320, a memory 330, and a communication bus 340, wherein the processor 310, the communication interface 320, and the memory 330 communicate with each other via the communication bus 340. The processor 310 can call logical instructions in the memory 330 to execute a method for switching the version of risk control rules, the method including: Obtain the rule parameters of the first risk control rule in the distributed system; The rule parameters of the first risk control rule and the rule parameters of the second risk control rule are merged to obtain the full set of rules; The full set of rules is loaded into each node of the distributed system; After the nodes of the distributed system asynchronously destroy the pre-stored second risk control rule, they reload the rule parameters of the first risk control rule to complete the version switch.

[0055] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0056] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the method for version switching of risk control rules provided by the above methods, the method including: Obtain the rule parameters of the first risk control rule in the distributed system; The rule parameters of the first risk control rule and the rule parameters of the second risk control rule are merged to obtain the full set of rules; The full set of rules is loaded into each node of the distributed system; After the nodes of the distributed system asynchronously destroy the pre-stored second risk control rule, they reload the rule parameters of the first risk control rule to complete the version switch.

[0057] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for version switching of risk control rules provided by the methods described above, the method comprising: Obtain the rule parameters of the first risk control rule in the distributed system; The rule parameters of the first risk control rule and the rule parameters of the second risk control rule are merged to obtain the full set of rules; The full set of rules is loaded into each node of the distributed system; After the nodes of the distributed system asynchronously destroy the pre-stored second risk control rule, they reload the rule parameters of the first risk control rule to complete the version switch.

[0058] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0059] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0060] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for version switching of wind control rules, characterized in that, include: Obtain the rule parameters of the first risk control rule in the distributed system; The rule parameters of the first risk control rule and the rule parameters of the second risk control rule are merged to obtain the full set of rules; The full set of rules is loaded into each node of the distributed system; After the nodes of the distributed system asynchronously destroy the pre-stored second risk control rule, they reload the rule parameters of the first risk control rule to complete the version switch. The step of loading the full set of rules into each node of the distributed system includes: Using the scenario interface of the distributed system as the key, the full set of rules is written to Redis; The application risk control engine extracts the variables from the full set of rules and encapsulates them into a hash map; Based on the hash map, the full set of rules is loaded into each node of the distributed system. 2.The method for version switching of a risk control rule according to claim 1, characterized in that, After loading the full set of rules into each node of the distributed system, the process further includes: Receive business processing requests; Based on the routing node corresponding to the business processing request, the first risk control rule or the second risk control rule in the full set of rules is used for processing. 3.The method for version switching of wind control rules according to claim 1, characterized in that, The Redis instance expires after a set time.

4. The method for version switching of wind control rules according to claim 1 or 3, characterized in that, The step of reloading the rule parameters of the first risk control rule to complete the version switch includes: After the Redis expires, the application risk control engine retrieves the rule parameters of the first risk control rule again; After rewriting the Redis data, the version switch is completed.

5. The method for version switching of risk control rules according to claim 1, characterized in that, The distributed system mentioned is the distributed system of the sports lottery.

6. A system for version switching of risk control rules, applied to the method for version switching of risk control rules according to any one of claims 1-5, characterized in that, include: The rule acquisition module is used to acquire the rule parameters of the first risk control rule in the distributed system. The rule merging module is used to merge the rule parameters of the first risk control rule with the rule parameters of the second risk control rule to obtain the full set of rules; The rule loading module is used to load the full set of rules into each node of the distributed system; The version switching module involves the nodes of the distributed system asynchronously destroying the pre-stored second risk control rule and then reloading the rule parameters of the first risk control rule to complete the version switching.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method for switching versions of risk control rules as described in any one of claims 1-5.

8. A non-transitory computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the method for switching versions of risk control rules as described in any one of claims 1-5.

9. A computer program product comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method for switching versions of risk control rules as described in any one of claims 1-5.

Images