Real-time risk control method and system based on double engines and gray release

Abstract

The application relates to the technical field of risk control decision, and specifically discloses a real-time risk control method and system based on double engines and gray release, wherein risk control metadata is configured and stored in a meta database, and configuration changes are synchronized to the local cache of each engine node through Redis publishing and subscribing; after receiving risk control event data, four-layer risk control pipeline processing is performed: a pretreatment layer performs lightweight mathematical expression calculation through an Aviator expression engine, an abstract processing layer performs time sequence aggregation feature calculation from an event database, a rule judgment layer executes rule scripts through a Groovy script engine and accumulates risk scores, a strategy decision layer acquires the online version identification and pre-release version identification of a target strategy and a gray proportion value, generates a random number and executes one of the two according to the comparison result, and outputs a risk level decision result and returns the result to a business system. Through the double-engine layered cooperation and strategy gray release mechanism, the application realizes the efficiency, stability and safe release of risk control decision.

Description

Technical Field

[0001] This invention relates to the field of risk control decision-making technology, and in particular to a real-time risk control method and system based on dual engines and grayscale release. Background Technology

[0002] Real-time risk control engines are the core infrastructure of anti-fraud systems for internet businesses, responsible for making millisecond-level risk decisions in key business scenarios such as user login, transaction payment, and marketing activities. As cybercriminal attack methods continue to evolve, risk control strategies need frequent updates to address new risk patterns, placing extremely high demands on the risk control engine's ability to dynamically configure rules and take effect in real time.

[0003] Currently, mainstream real-time risk control engines in the industry typically use Groovy scripts as the core technology for dynamic rule execution. Groovy, as a dynamic scripting language seamlessly compatible with Java, is widely used in building risk control rule engines due to its flexible syntax, good integration with the Java ecosystem, and support for runtime dynamic compilation. Risk control operators can edit and publish Groovy rule scripts in real time through the management backend. The engine dynamically loads, compiles, and executes these scripts at runtime, achieving rule effectiveness within seconds.

[0004] When Groovy scripts are executed, the GroovyClassLoader dynamically generates script class objects and loads them into the JVM metaspace. In risk control scenarios, rule policies change extremely frequently—the deployment of new rules, adjustments to old rules, and switching of A / B testing strategies all trigger the compilation of new Groovy scripts. Each compilation generates new Class objects in the metaspace, and these dynamically generated script class objects, referenced by the GroovyClassLoader's internal cache, cannot be properly garbage collected. As the number of rule iterations accumulates, the number of "abandoned" script class objects in the metaspace continues to grow, eventually triggering a `java.lang.OutOfMemoryError: Metaspace` exception, causing service lag or even crashes. Although there have been attempts in the industry to mitigate this by upgrading the Groovy version, adjusting JVM metaspace parameters, or periodically restarting the service, these solutions are either only temporary fixes or come at the cost of service availability. Numerous reports on this issue (such as GROOVY-9068 and GROOVY-7733) have been published in the official Apache Groovy issue tracking system, indicating that this problem is a persistent issue that the Groovy script engine has faced in long-term production environments.

[0005] The preprocessing stage of the risk control engine involves numerous simple mathematical expression calculations, such as threshold comparisons (`amount>1000`), arithmetic operations (`price * quantity`), and logical combinations (`age>= 18 && score>600`). These expressions are logically simple and computationally insignificant, but if they are all processed by the Groovy script engine, each iteration requires a complete script compilation and class loading process, with compilation overhead far exceeding the execution overhead of the expressions themselves. Furthermore, the Groovy script engine lacks a fine-grained timeout control mechanism for expression execution duration. If an expression times out due to data anomalies or logical flaws, it may occupy engine threads for an extended period, impacting overall throughput.

[0006] To address the memory leak issue in Groovy scripts, several improvements have been proposed in existing technologies. Some solutions suggest reusing compiled script classes and controlling the class loader's lifecycle to alleviate metaspace pressure, such as using a singleton GroovyClassLoader or caching compilation artifacts by script content hash values. However, these solutions primarily focus on cache reuse in general scenarios and fail to address the core challenge of "how to accurately clean up old scripts" when rules change frequently in risk control scenarios. Cache reuse alone can only slow down memory growth but cannot fundamentally reclaim the metaspace occupied by expired script classes. Another solution proposes managing compiled scripts using an LRU cache (capacity 1000), but in scenarios with frequent rule changes, the LRU eviction policy cannot guarantee that evicted scripts are no longer used. It may mistakenly evict new rule scripts still in the gray-scale verification phase, leading to a decrease in cache hit rate and redundant compilation overhead.

[0007] Furthermore, most existing risk control systems adopt a single script engine architecture, lacking a systematic design for functional division between lightweight expression engines and heavyweight rule engines according to the risk control pipeline hierarchy. Although lightweight expression engines such as Aviator already possess high-performance mathematical expression calculation capabilities, there is currently no complete technical solution for layering and collaborating with Groovy script engines in the risk control pipeline and dividing tasks according to scenarios. Summary of the Invention

[0008] In view of this, embodiments of the present invention provide a real-time risk control method and system based on dual engines and canary release, in order to solve the technical problems in the prior art, such as memory leaks and service lag caused by the dynamic scripting of business rules and the superposition of high-concurrency real-time decisions, and the inability of a single script engine to simultaneously handle the efficient calculation of lightweight mathematical expressions and complex logical judgments, resulting in poor system stability and high decision response latency.

[0009] In a first aspect, embodiments of the present invention provide a real-time risk control method based on dual engines and canary release, comprising the following steps: S1: Configure risk control metadata, which includes at least model configuration, field definition, preprocessing item, abstract processing definition, rule definition and strategy definition, and store the risk control metadata in the metadata database, and synchronize the configuration changes to the local cache of each risk control engine node through Redis publish and subscribe; S2: Receive risk control event data submitted by the business system, wherein the risk control event data includes at least an event identifier and event field information; S3: Perform four-layer risk control pipeline processing on the aforementioned risk control event data; S4: When executing the strategy decision layer processing, obtain the online version identifier and pre-release version identifier of the target strategy as well as the gray scale ratio value, generate a random number, and select one of the online version and the pre-release version to execute based on the comparison result of the random number and the gray scale ratio value, and output the risk level decision result. S5: Return the risk level decision result to the business system.

[0010] Secondly, embodiments of the present invention provide a real-time risk control system based on dual-engine and grayscale release, comprising a computer-readable storage medium and a processor, wherein a computer program is stored on the storage medium, and the computer program, when executed by the processor, implements the method described in any of the preceding claims; further comprising: The metadata management module is used to configure risk control metadata and store the risk control metadata in the metadata database; The cache synchronization module is used to synchronize the configuration changes of the risk control metadata to the local cache of each risk control engine node through Redis publish-subscribe. The event access module is used to receive risk control event data submitted by the business system; The risk control engine module is used to perform four-layer risk control pipeline processing on the risk control event data. The four-layer risk control pipeline includes a preprocessing layer, an abstract processing layer, a rule judgment layer, and a strategy decision layer. The preprocessing layer includes the Aviator expression engine for performing lightweight mathematical expression calculations; The rule judgment layer includes a Groovy script engine for executing rule scripts; The strategy version management module is used to maintain the online version identifier, pre-release version identifier, and grayscale ratio value of each strategy; The grayscale splitting module is used to generate random numbers and select one of the online version and the pre-release version to execute based on the comparison result of the random numbers and the grayscale ratio value; The decision output module is used to return the risk level decision results to the business system.

[0011] The real-time risk control method and system based on dual engines and canary release provided by this invention have the following beneficial effects: In this invention, the Aviator expression engine and Groovy script engine achieve performance decoupling between efficient computation of lightweight mathematical expressions and complex rule logic judgment through layered collaboration and functional division of labor in a four-layer risk control pipeline. By combining a Groovy script cache pool with a change-aware, proactive failure cleanup mechanism, the growth of Metaspace memory is effectively controlled in scenarios with frequent rule changes, eliminating the risk of Full GC caused by frequent hot script loading and resolving system stability issues caused by the superposition of dynamic scripting and high-concurrency decision-making in existing technologies. Simultaneously, through a dual-track policy version model and a random proportional traffic distribution mechanism, 1% precision traffic canary control and one-click rollback capability are achieved. Combined with a Redis publish-subscribe local cache hot update architecture, real-time effect of configuration changes and secure policy deployment are achieved while ensuring millisecond-level decision latency. Furthermore, the offline backscan module reuses the core logic of the real-time engine, achieving consistency and resource isolation between offline batch decision-making and real-time decision-making through breakpoint resumption, multi-node termination, and dynamic rate limiting mechanisms. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments of the present invention will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, and these are all within the protection scope of the present invention.

[0013] Figure 1 This is a flowchart of a real-time risk control method based on dual engines and canary release; Figure 2 This is a flowchart of a real-time risk control system based on dual engines and canary release. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. In the description of the present invention, it should be understood that the terms "center," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the referred device or element must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention. 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. Unless otherwise specified, the element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. Where there is no conflict, embodiments of the present invention and the various features thereof can be combined with each other, all of which are within the scope of protection of the present invention.

[0015] Example 1 Please see Figure 1 This invention provides a real-time risk control method based on dual engines and canary release, comprising the following steps: S1: Configure risk control metadata, which includes at least model configuration, field definition, preprocessing item, abstract processing definition, rule definition and strategy definition, and store the risk control metadata in the metadata database, and synchronize the configuration changes to the local cache of each risk control engine node through Redis publish and subscribe; Specifically, risk control metadata includes at least the following six types of configurations: (i) Model Configuration: Defines the basic information of the risk control model. Each model corresponds to an independent business scenario, such as the UC login risk control model, the learning event risk control model, and the outbound call anti-interference risk control model. The model configuration includes at least a globally unique identifier (GUID) for the model, the model name, the model's Chinese tag, the primary key field name of the event entity, the event time field name, and the model status (enabled / disabled). The business system calls the risk control engine through the GUID, and the engine loads the corresponding model configuration and all associated risk control elements under that model based on the GUID.

[0016] (ii) Field Definitions: Define the identifiable field information in the risk control event data. Each field definition must include at least the field name, Chinese field label, field type (e.g., string, numeric, date, boolean, etc.), and validation type. Field definitions serve as a dictionary for preprocessing, abstraction, and rule-based judgment, ensuring the engine can correctly parse and validate each field in the event data submitted by the business system.

[0017] (III) Preprocessing Items: Define how to extract basic features from the original fields after a risk control event is received. Each preprocessing item must include at least the original source field name, the target field name, the processing plugin identifier (e.g., IP address location resolution plugin, mobile phone number location resolution plugin, list matching plugin, etc.), and plugin parameters. Preprocessing items also support feature calculation via Aviator expressions, in which case the expression string and expression return value type need to be configured.

[0018] (iv) Abstract processing definition, which defines how to perform aggregate feature calculations from historical event data according to time series windows. Each abstract processing definition shall include at least the abstract processing name, aggregation type (such as COUNT, DISTINCT_COUNT, SUM, AVG, MAX, MIN, etc.), search field, search time interval type (minutes / hours / days), search time interval value, function field, and filtering script.

[0019] (v) Rule definition: Define the specific risk control judgment logic. Each rule definition shall include at least the rule name, rule script (Groovy), initial score, associated strategy version identifier, and rule status (enabled / disabled). The rule script is the core logic carrier of risk control decision-making. The engine determines whether a risk control event matches the rule by executing the rule script.

[0020] (vi) Strategy Definition: Define the combination of rules and risk thresholds. Each strategy definition shall include at least the strategy name, associated model identifier, rule execution order, low-risk threshold, medium-risk threshold, high-risk threshold, grayscale ratio, online version identifier, and pre-release version identifier.

[0021] After configuring the risk control metadata as described above, it is stored in the metadata database through the management terminal. The metadata database can be a MySQL relational database, with each configuration item stored in its corresponding table. For example, model configuration is stored in the `engine_model` table, field definitions are stored in the `engine_field` table, preprocessing items are stored in the `engine_pre_item` table, abstraction definitions are stored in the `engine_abstraction` table, rule definitions are stored in the `engine_rule` table, and strategy definitions are stored in the `engine_activation` table.

[0022] To achieve hot updates of risk control metadata configurations, this embodiment employs a Redis publish-subscribe mechanism to synchronize configuration changes to the local cache of each risk control engine node. Specifically, in response to changes in risk control metadata (including additions, modifications, and deletions), the management end first writes the changed risk control metadata to the metadata database to ensure data persistence. After writing, the management end publishes a configuration change notification to a preset configuration change channel via the Redis PUBLISH command. This notification carries at least the configuration type identifier and configuration identifier. Each risk control engine node subscribes to the preset channel at startup via the Redis SUBSCRIBE command. Upon receiving a configuration change notification, each engine node invalidates the corresponding risk control metadata in its local cache. The next time an engine node accesses the risk control metadata, it reloads the latest configuration from the metadata database and updates its local cache. Through this mechanism, any configuration change from the management end can be synchronized to all risk control engine nodes within seconds, achieving real-time configuration effectiveness without requiring a service restart.

[0023] As a preferred implementation, the local cache adopts a memory cache structure based on ConcurrentHashMap. Each risk control metadata category maintains an independent cache mapping, with the configuration identifier as the key and the configuration object as the value. When the cache expires, only the corresponding key-value pair is removed, without affecting the cache hit of other configurations.

[0024] S2: Receive risk control event data submitted by the business system, wherein the risk control event data includes at least an event identifier and event field information; In this embodiment, the business system submits risk control event data to the risk control engine via a Dubbo RPC interface or an HTTP interface. The risk control event data includes at least an event identifier and event field information. The event identifier uniquely identifies a risk control decision request and can be a Universally Unique Identifier (UUID) or a unique request ID generated by the business system. The event field information is the raw data upon which the risk control decision relies, organized in key-value pairs, with specific fields defined by the field definitions of the corresponding model.

[0025] Specifically, the business system calls the real-time risk control interface provided by the risk control engine, passing risk control event data as a request parameter in JSON format. Upon receiving the request, the risk control engine's interface entry layer first performs basic validation on the request parameters, including verifying whether the event identifier is empty and whether the event field information is in a valid JSON format. After successful validation, the interface entry layer loads the corresponding model configuration based on the model GUID in the request and performs field validation on the event field information to ensure that all required fields are provided and that the field types are consistent with the field definitions.

[0026] S3: Perform four-layer risk control pipeline processing on the aforementioned risk control event data; In this embodiment, the risk control engine sequentially executes a four-layer risk control pipeline process on the received risk control event data: preprocessing, abstraction, rule judgment, and strategy decision. Data is passed between the four layers through a unified risk control context object (Context). The processing results of each layer are sequentially stored in the context for use by subsequent layers, achieving complete decoupling between feature calculation and rule judgment. This includes: Preprocessing Layer: The risk control engine first performs basic feature extraction on the raw fields in the risk control event data. Specifically, the engine loads all enabled preprocessing items under the model configuration according to the model configuration and executes them sequentially according to the definition of the preprocessing items. The preprocessing layer supports two feature processing types: plugin processing and expression processing. For plugin processing, the engine calls the corresponding preprocessing plugin to perform feature extraction based on the plugin identifier specified in the preprocessing item. Plugins can include, but are not limited to: IP address location resolution plugin (resolving IP addresses to geographical location information such as province and city), mobile phone number location resolution plugin (resolving mobile phone numbers to information such as province, city, and operator), list matching plugin (matching field values ​​with blacklists and whitelists), string truncation plugin, date formatting plugin, etc. For expression processing, the engine performs lightweight mathematical expression calculations through the Aviator expression engine, and the expression calculation results are stored as preprocessed feature values ​​in the risk control context.

[0027] Abstract Processing Layer: After preprocessing, the risk control engine enters the abstract processing layer. Based on the processing results of the preprocessing layer, the abstract processing layer performs aggregate feature calculations from the event database according to a preset time window. Specifically, the engine loads all enabled abstract processing definitions under the model configuration. For each abstract processing definition, it first executes a filtering script (Groovy) to determine whether the current event meets the execution conditions of the abstract processing. If it does, it queries historical event data from the event database and performs aggregation calculations based on the search field, search time interval, and aggregation type in the abstract processing definition. Aggregation types include at least COUNT, DISTINCT_COUNT, SUM, AVG, MAX, MIN, SD, VARIANCE, DEVIATION, and MEDIAN. The aggregation calculation results are stored as abstract feature values ​​in the risk control context. The event database can use MongoDB, and the engine utilizes MongoDB's aggregation pipeline capabilities and composite indexes to accelerate aggregation queries.

[0028] Rule Judgment Layer Processing: After abstraction processing, the risk control engine enters the rule judgment layer. The rule judgment layer executes rule scripts through the Groovy script engine, matching the processing results from the preprocessing layer and the abstraction layer with preset rules. Specifically, the engine executes rules according to the order in the strategy definition, loading all enabled rule definitions under that strategy in sequence. For each rule, the engine passes all available data in the risk control context (including original event fields, preprocessed feature values, abstract feature values, etc.) as script variables to the Groovy script engine and executes the rule script. The rule script is a Boolean logical expression, returning true if the rule is hit, and false if it is not hit. When a rule is hit, the engine accumulates the risk score (initial score) corresponding to that rule. After all rules have been executed, the rule judgment layer outputs the accumulated total risk score and the list of hit rules.

[0029] Strategy Decision Layer Processing: After completing the rule judgment, the risk control engine enters the strategy decision layer. The strategy decision layer compares the accumulated risk score from the rule judgment layer with preset risk thresholds and outputs a risk level decision result. Specifically, the engine obtains the low-risk, medium-risk, and high-risk thresholds from the strategy definition and compares the accumulated risk score sequentially with each threshold: if the accumulated score is greater than or equal to the high-risk threshold, a high-risk decision result is output (e.g., BLOCK); if the accumulated score is greater than or equal to the medium-risk threshold but less than the high-risk threshold, a medium-risk decision result is output (e.g., SMS_VERIFICATION); if the accumulated score is greater than or equal to the low-risk threshold but less than the medium-risk threshold, a low-risk decision result is output (e.g., WARNING); if the accumulated score is less than the low-risk threshold, a pass decision result is output (e.g., PASS).

[0030] S4: When executing the strategy decision layer processing, obtain the online version identifier and pre-release version identifier of the target strategy as well as the gray scale ratio value, generate a random number, and select one of the online version and the pre-release version to execute based on the comparison result of the random number and the gray scale ratio value, and output the risk level decision result. Specifically, each strategy maintains three key fields in the metadata database: online version identifier (onlineVersionId), pre-release version identifier (preLaunchVersionId), and ratio value. The online version identifier points to the current fully effective strategy version, the pre-release version identifier points to the new strategy version to be verified in a gray-scale test, and the gray-scale ratio value is an integer from 0 to 100, representing the percentage probability that the pre-release version is hit.

[0031] When executing the strategy decision layer, the engine first loads the complete configuration information of the target strategy from the local cache, including the online version identifier, the pre-release version identifier, and the canary scale ratio value. Then, the engine determines whether a pre-release version exists with a canary scale ratio value greater than 0: if no pre-release version exists or the canary scale ratio value is 0, the online version is executed directly; if a pre-release version exists with a canary scale ratio value greater than 0, the canary scale distribution logic is entered.

[0032] The canary release traffic splitting logic is as follows: The engine generates a random integer ranging from 0 to 99. If the random integer is less than the canary release ratio, the pre-release version is selected for execution; if the random integer is greater than or equal to the canary release ratio, the online version is selected for execution. For example, when the canary release ratio is set to 10, the probability of the generated random integer being in the range of 0 to 9 is 10%, meaning approximately 10% of the traffic will be routed to the pre-release version; the probability of the random integer being in the range of 10 to 99 is 90%, meaning approximately 90% of the traffic will continue to execute the online version. Regardless of whether the online version or the pre-release version is executed, the engine executes rule judgments according to the rules defined in that version, accumulates the risk score, compares it with the risk threshold defined in that version, and finally outputs the risk level decision result.

[0033] As a preferred implementation, the engine independently generates random numbers each time it performs canary traffic distribution, ensuring the statistical randomness of traffic allocation. The canary ratio value can be adjusted at any time on the management side, and after adjustment, it is synchronized to all engine nodes through the Redis publish-subscribe mechanism described in step S1, so that the canary ratio takes effect in real time.

[0034] S5: Return the risk level decision result to the business system; In this embodiment, after the risk control engine completes the entire risk control pipeline processing, it encapsulates the risk level decision result into a response object and returns it to the business system via a Dubbo RPC interface or HTTP interface. The decision result includes at least the decision type (such as PASS, WARNING, SMS_VERIFICATION, BLOCK, FREEZE, etc.), risk level score, a list of hit rules, and the reason for the block (internal and external reasons).

[0035] After receiving the decision result, the business system executes the corresponding business processing according to the decision type: if the decision result is PASS, the business operation is allowed to continue normally; if the decision result is WARNING, the business operation is allowed to continue but an alarm is recorded; if the decision result is SMS_VERIFICATION, the user is required to complete SMS verification before continuing; if the decision result is BLOCK or FREEZE, the business operation is directly blocked and the user is notified.

[0036] Furthermore, the process of synchronizing configuration changes to the local cache of each risk control engine node via Redis publish / subscribe includes the following steps: In response to changes to risk control metadata, the management system writes the updated risk control metadata into the metadata database. In this embodiment, risk control operations personnel add, modify, or delete risk control metadata through a management backend (such as the radar-ae frontend management interface). The management backend responds to these changes by first verifying the business legality of the modified risk control metadata. Taking abstract processing definition as an example, the verification includes, but is not limited to: whether the number of search fields is within a reasonable range of 1 to 5, whether the aggregation type is one of the 10 aggregation types supported by the system, and whether the search time interval value is a positive integer. After successful verification, the management backend calls the corresponding service interface (such as AbstractionApiService.save) via Dubbo RPC to write the modified risk control metadata into the corresponding data table in the metadata database (MySQL). The write operation uses a transaction mechanism to ensure data consistency; that is, the multi-table updates of risk control metadata are completed within the same database transaction, either all are successfully committed or all are rolled back. Taking rule changes as an example, the main rule table (engine_rule) and the rule history snapshot table (rule_history) are written within the same transaction, ensuring the complete traceability of rule changes.

[0037] The management console publishes configuration change notifications to preset channels via Redis publish / subscribe. In this embodiment, after the risk control metadata is successfully written to the metadata database, the management end uses the Redis PUBLISH command to publish configuration change notifications to preset configuration change channels. Different categories of risk control metadata correspond to different preset channels. For example, model configuration changes are published to the "pc_radar:channel:model" channel, field definition changes are published to the "pc_radar:channel:field" channel, preprocessing item changes are published to the "pc_radar:channel:preitem" channel, abstract processing definition changes are published to the "pc_radar:channel:abstraction" channel, rule definition changes are published to the "pc_radar:channel:rule" channel, and policy definition changes are published to the "pc_radar:channel:activation" channel. The configuration change notification includes at least the configuration identifier of the change (such as the rule ID) and the change operation type (add / modify / delete) so that the engine node can accurately identify the local cached items that need to be invalidated.

[0038] Each risk control engine node subscribes to the preset channel, and upon receiving the configuration change notification, invalidates the corresponding risk control metadata in the local cache of the risk control engine node. In this embodiment, each risk control engine node subscribes to all configuration change channels via the Redis SUBSCRIBE command upon startup. Each engine node internally maintains a cache invalidation listener, which continuously monitors messages published by each channel. When an engine node receives a configuration change notification, it parses the configuration identifier and operation type in the notification content, and then invalidates the corresponding risk control metadata in its local cache. Specifically, the local cache uses a ConcurrentHashMap structure, storing configuration identifiers as keys and configuration objects as values. The cache invalidation operation calls the ConcurrentHashMap's remove method to remove the key-value pair corresponding to the specified configuration identifier, while leaving the cached data of other configuration items unaffected. For "delete" type change operations, the configuration object corresponding to the configuration identifier no longer exists in the local cache after cache invalidation; for "modify" type change operations, the engine node will load the latest configuration on the next access after cache invalidation, thus achieving configuration updates.

[0039] The risk control engine node reloads and updates the local cache from the metadata database the next time it accesses the risk control metadata; In this embodiment, when a risk control engine node needs to access certain risk control metadata while processing risk control event data, it first queries the local cache. If the local cache is hit, the configuration object in the cache is used directly; if the local cache is not hit (i.e., the configuration has been invalidated), the latest configuration data is retrieved from the metadata database (MySQL), loaded into the local cache, and the configuration object is returned for subsequent processing. The above cache loading mechanism is a "lazy loading" mode, which only performs reloading when the configuration is actually accessed, avoiding the performance overhead of batch reloading all configurations when the configuration changes.

[0040] Furthermore, the four-layer air control pipeline sequentially includes: Preprocessing layer processing: Perform basic feature extraction on the raw fields in the risk control event data. The basic feature extraction includes performing lightweight mathematical expression calculation through the Aviator expression engine, and / or performing at least one of IP address location resolution, mobile phone number location resolution, and list matching through a plugin. In this embodiment, the preprocessing layer is the first layer of the risk control pipeline, responsible for performing basic feature extraction on the raw fields in the risk control event data. After receiving the risk control event data submitted by the business system, the risk control engine first parses each raw field in the event data, then loads all enabled preprocessing items under the model according to the model configuration, and executes each preprocessing item sequentially. The basic feature extraction includes at least one of the following two methods: (i) Lightweight mathematical expression calculations are performed using the Aviator expression engine. For preprocessing items configured as expression processing type (feature_type=2), the engine calls the Aviator expression engine to execute a predefined expression string. Specifically, the engine passes all raw fields from the risk control event data as variable environments (env) to the Aviator expression engine. Field names can be directly referenced as variable names in the expression string; for example, the expression "price *quantity>1000" references the fields price and quantity. The Aviator expression engine compiles and executes the expression, returning a boolean or numerical value as the calculation result. The Aviator expression engine has a built-in expression compilation caching mechanism, ensuring that the same expression string is compiled only once, and subsequent executions directly reuse the compilation artifacts, significantly reducing the overhead of repeated compilation. This method is suitable for lightweight mathematical calculation scenarios such as threshold comparison, arithmetic operations, and logical combinations. The execution timeout control mechanism of the Aviator expression engine will be described in further detail in subsequent embodiments.

[0041] (II) Basic Feature Extraction via Plugins. For preprocessing items configured as plugin processing type (feature_type=1), the engine calls the corresponding preprocessing plugin to perform feature extraction based on the plugin identifier (PLUGIN field) specified in the preprocessing item. A plugin is a pre-packaged functional unit, with each plugin implementing specific feature extraction logic. Plugin types include, but are not limited to: IP address location resolution plugin (IP2LOCATION), which resolves IP addresses to geographical location information such as province, city, and country; mobile phone number location resolution plugin (MOBILE2LOCATION), which matches the first 7 digits of a mobile phone number with the location database to parse out province, city, and operator information; list matching plugin (ROSTER), which performs exact or fuzzy matching of field values ​​with blacklists and whitelists, returning whether a list is matched and the type of match; string truncation plugin (SUBSTRING), which truncates a string field; and date formatting plugin (DATEFORMAT), which converts date strings to standard formatting. Formatting plugins include: String to Number (STR_TO_LONG), which converts string-type numeric values ​​to long integers; GPS Coordinate Location Parsing (GPS2LOCATION), which parses latitude and longitude coordinates into geographic location information; Sensitive Time Period Judgment (SENSITIVE_TIME), which determines whether the current time falls within a preset sensitive time period; Message Reach Counting Plugin (MsgReachCountTool), which counts the number of times user messages have been reached; Application Version Parsing Plugin (AppVersionTool), which parses application version information; and Thesaurus Matching Plugin (THESAURUS), which matches text content against a sensitive word library. It supports over 37 preprocessing plugins to meet diverse feature extraction needs.

[0042] After the preprocessing layer completes its processing, all preprocessing results are stored as new feature fields in the risk control context for use by subsequent layers.

[0043] Abstract processing layer processing: Based on the processing results of the preprocessing layer, aggregate feature calculation is performed from the event database according to a preset time window. The aggregate feature calculation includes at least one or more of COUNT, DISTINCT_COUNT, SUM, AVG, MAX, MIN, SD, VARIANCE, DEVIATION, and MEDIAN. In this embodiment, the abstract processing layer is the second layer of the risk control pipeline. It is responsible for performing aggregate feature calculations from the event database according to a preset time window, based on the processing results of the preprocessing layer. Specifically, the risk control engine loads all enabled abstract processing definitions under the model configuration and executes the following sub-steps sequentially for each abstract processing definition: First, the engine retrieves the filter script (RULE_SCRIPT field) from the abstract processing definition. This filter script, written in Groovy, is used to determine whether the current event meets the execution conditions of the abstract processing. The engine passes all data in the risk control context (including the original event fields and preprocessed feature values) as variables to the Groovy script engine to execute the filter script. If the script returns false, the current abstract processing is skipped, and aggregation calculation is not performed; if the script returns true, aggregation calculation continues.

[0044] Secondly, the engine constructs query conditions based on the search field (SEARCH_FIELD), search time interval type (SEARCH_INTERVAL_TYPE, such as minutes, hours, days), and search time interval value (SEARCH_INTERVAL_VALUE) defined in the abstract processing. Specifically, the engine uses the occurrence time of the current event as a baseline and traces back a specified time window to construct time range query conditions. Simultaneously, the engine retrieves the feature values ​​corresponding to the search field from the risk control context as equality matching conditions. For example, if the abstract processing is defined as counting "the number of times the current user logs in within the past 10 minutes," then the search field is user_id, the time window is 10 minutes, and the engine queries the event database for all historical event records where user_id equals the current event's user ID and the event time is within 10 minutes.

[0045] Then, the engine performs the corresponding aggregation calculation based on the aggregation type (AGGREGATE_TYPE) defined in the abstract processing definition. The aggregation types include at least the following 10: COUNT (count, counts the total number of events that meet the conditions), DISTINCT_COUNT (counts the number of distinct values ​​among events that meet the conditions), SUM (sum, sums the values ​​of a specified function field), AVG (average, calculates the arithmetic mean of a specified function field), MAX (maximum, gets the maximum value of a specified function field), MIN (minimum, gets the minimum value of a specified function field), SD (standard deviation, calculates the population standard deviation of a specified function field), VARIANCE (variance, calculates the population variance of a specified function field), DEVIATION (deviation, calculates the deviation of a specified function field from the mean), and MEDIAN (median, calculates the median of a specified function field). The engine dynamically selects the corresponding aggregation command to perform the aggregation calculation based on the aggregation type.

[0046] Finally, the aggregated calculation results are obtained through the engine and stored as abstract feature values ​​in the risk control context.

[0047] Rule judgment layer processing: The rule script is executed through the Groovy script engine, and the processing results of the preprocessing layer and the processing results of the abstract processing layer are matched with the preset rules. When a rule is matched, the risk score is accumulated.

[0048] In this embodiment, the rule judgment layer is the third layer of the risk control pipeline. It is responsible for executing rule scripts through the Groovy script engine, matching the processing results of the preprocessing layer and the processing results of the abstract processing layer with preset rules, and accumulating risk scores when a rule is matched.

[0049] Specifically, the risk control engine loads all enabled rule definitions under a given policy in sequence, based on the rule sorting (RULE_ORDER field, a comma-separated sequence of rule IDs) in the policy definition. For each rule definition, the engine performs the following operations: First, the engine retrieves the rule script (SCRIPTS field) from the rule definition. This rule script, written in Groovy, is a logical expression that returns a boolean value. The engine then passes all available data from the risk control context (including raw event fields, preprocessed feature values, abstract feature values, and black / white list matching results) as variables to the Groovy script engine and executes the rule script. The execution environment of the rule script contains all fields and feature values ​​of the event data. Rule writers can directly reference any field or feature by variable name. For example, the rule script "login_count>5&&device_risk == 'high'" references two variables: login_count (abstract feature) and device_risk (preprocessed feature).

[0050] Secondly, the engine determines the execution result of the rule script: if it returns true, it means that the current risk control event has hit the rule, the engine adds the initial score of the rule (INIT_SCORE field) to the total risk score, and records the rule identifier in the hit rule list; if it returns false, it means that the rule has not been hit, and no score is added.

[0051] After all rules have been executed in sequence, the rule judgment layer outputs the accumulated total risk score and the list of hit rules, which are stored in the risk control context for use by the strategy decision layer.

[0052] As a preferred implementation, the rule scripts are executed using the Groovy script engine. The Groovy script engine maintains a cache pool of compiled scripts, ensuring that identical script content is compiled only once, and subsequent executions directly reuse the compiled artifacts, avoiding the overhead of repeated compilation. The specific management mechanism of the Groovy script cache pool will be described in further detail in subsequent embodiments.

[0053] The strategy decision layer processes the risk by comparing the accumulated risk score from the rule-based judgment layer with a preset risk threshold and outputting the risk level decision result. In this embodiment, the strategy decision layer is the fourth layer of the risk control pipeline. It is responsible for comparing the accumulated risk score of the rule judgment layer with the preset risk threshold and outputting the risk level decision result.

[0054] Specifically, the risk control engine obtains three risk thresholds from the strategy definition: a low-risk threshold (BOTTOM field), a medium-risk threshold (MEDIAN field), and a high-risk threshold (HIGH field). The engine compares the cumulative total risk score output by the rule judgment layer with these three thresholds in sequence, and the decision logic is as follows: If the accumulated risk score is greater than or equal to the high-risk threshold, a high-risk decision result will be output, and the corresponding decision type will be BLOCK, indicating that the current risk control event has a serious risk and the business system should directly block the operation. If the accumulated risk score is greater than or equal to the medium risk threshold and less than the high risk threshold, then the medium risk decision result will be output. The corresponding decision type is SMS_VERIFICATION (SMS verification), which means that the current risk control event has a medium risk. The business system should require the user to complete the SMS verification code verification before continuing the operation. If the accumulated risk score is greater than or equal to the low risk threshold and less than the medium risk threshold, a low risk decision result will be output. The corresponding decision type is WARNING, which means that the current risk control event has a low risk. The business system can allow it, but an alarm log needs to be recorded for the operations staff to pay attention to. If the accumulated risk score is less than the low-risk threshold, the decision result is output as PASS, indicating that no risk was detected in the current risk control event and the business system allows it to proceed normally.

[0055] After the strategy decision layer completes its processing, it encapsulates the risk level decision results (including decision type, risk level score, list of hit rules, etc.) into an AntiFraudProcessResult object and returns it to the main process of the risk control engine.

[0056] Furthermore, the Aviator expression engine and the Groovy script engine adopt a dual-track parallel architecture, wherein: The Aviator expression engine is used to perform mathematical expression calculations in the preprocessing layer and detect the execution time after the expression is executed. When the execution time exceeds a preset timeout threshold, an alarm log is recorded without interrupting the engine execution. The Groovy script engine is used to execute the rule scripts in the rule judgment layer and the filter scripts in the abstract processing layer. In this embodiment, the risk control engine positions the Aviator expression engine and the Groovy script engine as two independent and complementary execution units in its architecture design. The two perform their respective duties and work together at different levels of the risk control pipeline to form a complete dual-track parallel architecture.

[0057] The Aviator expression engine is used to perform mathematical expression calculations in the preprocessing layer. Specifically, when a preprocessing item is configured as an expression processing type (feature_type=2), the risk control engine calls the Aviator expression engine to execute the expression string defined in that preprocessing item. Aviator is a lightweight Java expression engine with a syntax design close to the natural writing style of mathematical expressions. It supports arithmetic operations (+, -, *, / , %), logical operations (&&, ||, !), relational operations (>, >=, <, <=, ==, !=), ternary operators (?:), and built-in mathematical functions (such as max, min, abs, sqrt, etc.). Expression strings can directly reference field names in the risk control event data as variable names without additional variable declarations. For example, the preprocessing expression "amount * rate>100 ? 1 : 0" directly references the two fields "amount" and "rate". The Aviator engine automatically obtains the current values ​​of these two fields from the passed-in variable environment during execution.

[0058] The Aviator expression engine incorporates a built-in expression compilation caching mechanism. When the engine executes an expression string for the first time, it calls the `AviatorEvaluator.compile` method to parse and compile the expression, generating a compiled artifact (an `Expression` object) which is then cached in the AviatorEvaluator's internal cache. When the engine executes the same expression string again, it directly retrieves the compiled artifact from the cache and calls its `execute` method, avoiding the overhead of repeated compilation.

[0059] In this embodiment, the Aviator expression engine also introduces a soft control mechanism for execution timeout. Specifically, after an Aviator expression is executed, the engine detects the execution time (executionTime) and compares it with a preset timeout threshold (timeoutMs). The default value for the preset timeout threshold is 100 milliseconds. If the execution time is less than or equal to the timeout threshold, the execution result is returned normally; if the execution time is greater than the timeout threshold, a warning log is recorded. The log content includes at least the expression string, the actual execution time, and the timeout threshold, allowing maintenance personnel to troubleshoot slow expressions. However, the engine does not interrupt the execution result of the current expression, nor does it throw an exception that would affect the normal operation of subsequent risk control pipelines.

[0060] Unlike the conventional "hard timeout" mechanism (which immediately interrupts thread execution upon reaching the timeout threshold), this embodiment adopts a "soft timeout" mechanism because: in risk control scenarios, the execution time of the vast majority of Aviator expressions is far less than 1 millisecond, and a very small number of expressions may experience occasional delays due to abnormal data volume or complex regular expression matching. If a hard timeout mechanism is used, normal expressions may be mistakenly interrupted at the threshold, leading to failed risk control decisions and impacting business availability. The soft timeout strategy of "post-execution detection + alert only" can promptly detect expressions with performance anomalies while avoiding the impact of accidental interruptions on business operations, ensuring the availability of the engine.

[0061] The Groovy script engine is used to execute the rule scripts in the rule judgment layer and the filter scripts in the abstract processing layer. Specifically, in the abstract processing layer, the Groovy script engine executes the filter script (RULE_SCRIPT field) in the abstract processing definition to determine whether the current event meets the execution conditions of the abstract processing; in the rule judgment layer, the Groovy script engine executes the rule script (SCRIPTS field) in the rule definition to determine whether the current event matches the rule.

[0062] Groovy is a dynamic scripting language that runs on the JVM platform. Its syntax is highly compatible with Java, and it supports advanced features such as closures, dynamic typing, and metaprogramming, making it suitable for writing complex business logic. In risk control scenarios, rule scripts may involve complex operations such as multiple condition combinations, nested logic, collection traversal, and external method calls. The Groovy script engine can well support these requirements. For example, a complex rule script may include combined judgments of multiple abstract features, secondary processing of list matching results, and comprehensive evaluation of user historical behavior. Writing this logic in Groovy is more flexible and concise.

[0063] When executing a script, the Groovy script engine manages a cache pool of compiled scripts using the GroovyScriptUtil utility class. Specifically, GroovyScriptUtil internally maintains a ConcurrentHashMap as the compilation cache pool, using the script source code string as the key and the compiled Class object as the value. When the engine executes a script for the first time, it calls the GroovyShell's parse method to parse and compile the script source code, generating a Class object and storing it in the cache pool. Subsequent executions of the same script retrieve the compiled Class object directly from the cache pool and execute the script method via reflection, avoiding the overhead of repeated compilation and significantly improving script execution performance.

[0064] It should be noted that the "dual-track parallelism" of the Aviator expression engine and the Groovy script engine in this embodiment is not only reflected in the fact that each engine executes its respective computational task, but also in their complementary division of labor: Aviator, with its lightweight and efficient characteristics, is responsible for the mathematical expression calculations in the preprocessing layer, while Groovy, with its flexible and powerful characteristics, is responsible for the complex logical judgments in the rule judgment layer and the abstract processing layer. Working collaboratively within a unified risk control pipeline, they ensure both the expressiveness of complex rule judgments and the efficiency of lightweight mathematical calculations, achieving an optimal match between capability and performance.

[0065] Furthermore, the Groovy script engine maintains a cache pool of compiled scripts; Specifically, when the rule definition or abstract processing definition changes, the script content before and after the change is compared. If the script content changes, the compilation artifact corresponding to the script before the change is removed from the compiled script cache pool; When executing a script, the Groovy script engine first retrieves the compiled script from the compiled script cache pool. If the cache is not found, the script is compiled and stored in the compiled script cache pool.

[0066] In this embodiment, the Groovy script engine maintains a compiled script cache pool. This cache pool is implemented in the GroovyScriptUtil utility class, specifically using a ConcurrentHashMap data structure with the script source code string as the key and the compiled Class object as the value, supporting thread-safe access in high-concurrency environments. The lifecycle of the cache pool is consistent with the service lifecycle of the risk control engine; that is, the cache pool is initialized when the engine starts, continuously maintained during engine operation, and all caches are released when the engine shuts down.

[0067] The risk control engine detects script changes and clears the cache through the following process: When risk control operations personnel modify a rule definition or abstract processing definition on the management side and submit it for saving, the management side calls the corresponding service interface (such as RuleServiceImpl.save or AbstractionServiceImpl.save) to perform the save operation. Before performing the save, the service interface first loads the existing record of the rule or abstract processing definition from the database to obtain the currently stored script content (i.e., the script source code before the change). Then, it compares the new script content submitted by the management side with the existing script content.

[0068] Specifically, the comparison operation is implemented by comparing the hash values ​​(hashCode) of two script strings or by directly comparing string equality. If the new script content is completely identical to the existing script content, cache clearing is not triggered, and other fields in the database (such as status, remarks, etc.) are updated directly. If the new script content is inconsistent with the existing script content, it indicates that the script has undergone substantial changes, and the engine enters the cache clearing process.

[0069] The cache cleanup process is as follows: First, the service interface calls the `GroovyScriptUtil.removeInactiveScript` method, using the old script source code string as the parameter, to remove the key-value pair corresponding to the source code from the compiled script cache pool, thus releasing the reference to the old script's compilation artifacts. Then, the service interface updates the new script content to the database and saves a rule history snapshot (the `rule_history` table), recording information such as the script content before and after the change, the modifier, and the modification time, facilitating subsequent auditing and rollback. Since the cache key is the script source code string itself, as long as the old script source code is no longer referenced anywhere, its corresponding compilation artifact Class object is no longer held by the cache pool, allowing it to be properly reclaimed by the JVM garbage collector, releasing Metaspace memory. If only non-script fields such as the name, status, and score of the rule or abstract processing definition are updated, and the script content remains unchanged, cache cleanup will not be triggered, and the existing cached compilation artifacts will be retained for subsequent execution.

[0070] In this embodiment, the core advantages of the cache cleanup mechanism are its precision and proactivity: precision means that only the cache corresponding to the scripts that have actually changed is cleaned up, without affecting the cache hit rate of other unchanged scripts; proactivity means that the cleanup operation is triggered by script change events, rather than relying on passive strategies such as scheduled tasks or LRU eviction, ensuring that invalid scripts can be removed from the cache in a timely manner, thereby minimizing the Metaspace memory usage.

[0071] When executing a script, the Groovy script engine prioritizes retrieving compiled scripts from the compiled script cache pool. Specifically, when the risk control engine executes the abstract processing layer filtering script or the rule judgment layer rule script, it calls the GroovyScriptUtil.invokeMethod method, which accepts three parameters: the script source code string, the method name, and the parameter array.

[0072] The execution flow of the `invokeMethod` method is as follows: Using the script source code string as the key, it queries the compiled script cache pool (ConcurrentHashMap) to see if a corresponding compilation artifact exists. If the cache is hit, the compiled Class object is directly retrieved from the cache. Then, through Java reflection, the specified method (such as the `run` method) is obtained from the Class object, the method is executed with the parameter array passed in, and the execution result is returned. If the cache is not hit, it means that the script has not been compiled yet (possibly for the first execution), and the engine enters the compilation process: calling the `parse` method of GroovyShell to perform syntax parsing and compilation of the script source code, generating a compiled Class object. After compilation, the script source code string and the compiled artifact Class object are stored in the compiled script cache pool as key-value pairs. Subsequently, the script method is executed via reflection, and the execution result is returned.

[0073] In this embodiment, the cache cleanup mechanism and the script execution mechanism form a complete closed loop: on the one hand, proactive invalidation driven by change awareness ensures that the compiled artifacts of the old scripts that have changed are removed from the cache in a timely manner, releasing Metaspace memory and solving the memory leak problem caused by the dynamic compilation of Groovy scripts; on the other hand, the execution strategy of caching first and then compiling ensures that frequently executed scripts can reuse their compiled artifacts, avoiding repeated compilation overhead and guaranteeing the high throughput performance of the engine. Meanwhile, since both cache cleanup and cache storage use the script source code string as a unique identifier, when a script changes, the new script content is stored in the database. During subsequent executions, since the old script source code has been removed from the cache, the engine will automatically compile the new script and re-store it in the cache, achieving seamless switching of script updates. The entire process is completely transparent to business requests.

[0074] Furthermore, the step of performing aggregate feature calculation from the event database according to a preset time window includes the following steps: Based on the search fields and search time ranges in the abstract processing definition, construct a MongoDB aggregate query pipeline; In this embodiment, when the risk control engine executes the abstract processing layer, it first obtains the various configuration parameters in the abstract processing definition, including the search field (SEARCH_FIELD), the search time interval type (SEARCH_INTERVAL_TYPE), the search time interval value (SEARCH_INTERVAL_VALUE), and the function field (FUNCTION_FIELD). Based on these parameters, the engine dynamically constructs a MongoDB aggregation query pipeline.

[0075] The aggregation query pipeline is constructed as follows: The engine uses the occurrence time of the current risk control event (i.e., the datetime field in the event data) as a benchmark, and calculates the query time range based on the search time interval type and the search time interval value. For example, if the search time interval type is "minutes" and the search time interval value is 10, then the time range is 10 minutes prior to the current event occurrence time. Then, the engine obtains the specific value corresponding to the search field from the risk control context (such as the user ID, device ID, etc. of the current event) as the condition value for equality matching.

[0076] Based on the above conditions, the engine constructs the first stage of the aggregation pipeline, the "match stage". The match stage is used to filter historical event records in the event database and select events that meet the following two conditions: (1) the event time is within the calculated time window; (2) the value of the search field is equal to the corresponding value in the current event. For example, if the abstract processing is defined as counting "the number of times the current user logs in within the past 10 minutes", then the event records filtered by the $match stage are: all login events whose event time is within the past 10 minutes and whose user ID is equal to the current event user ID.

[0077] If a filter script (RULE_SCRIPT field) is configured in the abstract processing definition, the engine will first execute the filter script through the Groovy script engine before executing the aggregation query to determine whether the current event meets the execution conditions of the abstract processing. The engine will only execute the MongoDB aggregation query if the filter script returns true; otherwise, it will skip the abstract processing and directly return an empty result. This design avoids unnecessary database query operations and effectively reduces the query load on MongoDB.

[0078] As a preferred implementation, to ensure the performance of aggregate queries, the engine automatically creates a composite index on the corresponding event collection in MongoDB when the abstract processing definition is saved. The field combination of the composite index includes at least the search field and the time field, for example, db.entity_collection.createIndex({“user_id”: 1, “event_time”: -1}).

[0079] Based on the aggregation type in the abstract processing definition, dynamically select the corresponding aggregation command to perform aggregation calculation; In this embodiment, after the document filtering in the match phase is completed, the engine dynamically selects the corresponding aggregation command based on the aggregation type (AGGREGATETYPE) in the abstract processing definition, and adds the corresponding group phase and $project phase to the MongoDB aggregation pipeline.

[0080] A total of 10 aggregation types are supported. The MongoDB aggregation operators and calculation logic for each aggregation type are as follows: For the COUNT aggregation type, the engine uses the SUM operator in the GROUP phase to count all matched documents, that is, to calculate the total number of historical events that meet the time window and search field conditions. The corresponding MongoDB aggregation pipeline is: {sum: 1}}}.

[0081] For the DISTINCT_COUNT (deduplication count) aggregation type, the engine groups the data by the function field as the grouping key in the $group stage, and then counts the number of different groups, that is, counts the number of different values ​​of the function field in historical events that meet the conditions. The corresponding aggregation pipeline is: group: {_id: “function_field”}} followed by a {count:“value”} stage, or it can be implemented using {addToSet} in conjunction with {size}.

[0082] For the SUM (summation) aggregation type, the engine uses the SUM operator in the group phase to sum the values ​​of the function field (FUNCTION_FIELD), that is, to calculate the sum of the function field values ​​of historical events that meet the conditions. The corresponding MongoDB aggregation pipeline is: {sum: “$function_field”}}}.

[0083] For AVG (Average) aggregation types, the engine uses the avg operator in the group phase to calculate the arithmetic mean of the function field values. The corresponding MongoDB aggregation pipeline is: {avg: “$function_field”}}}.

[0084] For the MAX (maximum value) aggregation type, the engine uses the MAX operator in the group phase to obtain the maximum value of the function field. The corresponding MongoDB aggregation pipeline is: {max: “$function_field”}}}.

[0085] For the MIN (minimum value) aggregation type, the engine uses the min operator in the group phase to obtain the minimum value of the function field. The corresponding MongoDB aggregation pipeline is: {min: “$function_field”}}}.

[0086] For SD (Standard Deviation) aggregation types, the engine uses the stdDevPop operator in the group phase to calculate the overall standard deviation of the function field values. The corresponding MongoDB aggregation pipeline is: {stdDevPop: “$function_field”}}}.

[0087] For the VARIANCE aggregation type, the engine uses MongoDB's stdDevPop operator to calculate the standard deviation during the group phase, and then squares the standard deviation through the phase to obtain the population variance. Alternatively, it can directly use the expression: group: {_id: null, variance: {stdDevPop:“stdDevPop:“function_field”}}}, and then square it through $project.

[0088] For the DEVIATION aggregation type, the engine first calculates the average of the function field values ​​(using avg), and then calculates the difference between the average and the actual average for each document in the project phase (i.e., the deviation value). The formula for calculating the deviation value is: deviation = field_value - average_value. Since the project phase in the MongoDB aggregation pipeline cannot directly reference the aggregation results from the group phase, the engine uses the $facet method to calculate the average and deviation separately, or employs two aggregation queries.

[0089] For the MEDIAN aggregation type, the engine calculates the median as follows: First, the function field values ​​are sorted in ascending order using the sort phase; then, all values ​​are collected into an array using the group phase (using push); finally, the array length is calculated using the project phase, and the median value is taken. Alternatively, the median operator (if available) provided by MongoDB 5.0 and above can be used for direct calculation. For MongoDB versions that do not support the median operator (if available), the engine uses a percentile approximation algorithm, obtaining the median value from the sorted array by position index. After the aggregation calculation is complete, the MongoDB aggregation pipeline returns a document containing the aggregation result values.

[0090] The aggregated calculation result is returned as an abstract feature value and stored in the risk control context; In this embodiment, after the MongoDB aggregation pipeline is completed, the engine extracts the aggregated calculated value from the aggregation result document. If the aggregation query does not match any historical event records (i.e., there is no historical data that meets the conditions within the time window), the aggregation result is null or a default value (such as 0). The engine decides whether to use null or the default value based on the configuration defined in the abstract processing definition.

[0091] The engine uses the aggregated calculation results as abstract feature values, storing them in the risk control context using the abstract processing name (NAME field) as the key. Once stored in the context, this abstract feature value can be directly referenced by the rule script in subsequent rule judgment layers. For example, if the abstract processing name is "login_count", the rule script can directly use the variable name "login_count" to retrieve this abstract feature value and participate in rule logic judgment.

[0092] It is important to note that since the abstract processing definition may contain a filtering script (Groovy), this filtering script is executed by the Groovy script engine before the aggregate query is executed. If the execution of the filtering script involves accessing other features in the risk control context, these features must have been calculated before the current abstract processing in the execution order of the preprocessing layer and the abstract processing layer. Therefore, as a preferred implementation, when executing the abstract processing layer, the risk control engine performs topological sorting according to the dependencies between abstract processing definitions, ensuring that the dependent abstract processing is executed first, and the dependents are executed later, avoiding access to uncalculated features.

[0093] Further, the step of selecting one of the online version and the pre-release version to execute based on the comparison result of the random number and the grayscale ratio value includes the following steps: Generate random integers ranging from 0 to 99; In this embodiment, when the risk control engine executes the strategy decision-making layer processing, if it detects that a pre-release version of the current strategy exists and the grayscale ratio value is greater than 0, it enters the grayscale distribution logic. The engine first generates a random integer using the random number generator in the Java standard library. Specifically, the engine uses the `java.util.concurrent.ThreadLocalRandom` class to generate random numbers. This class is a high-performance random number generation tool designed for high-concurrency Java scenarios. It avoids the overhead of synchronization competition in a multi-threaded environment through a thread-local storage mechanism, effectively supporting the frequent random number generation needs of the risk control engine in high-concurrency throughput scenarios. The engine calls the `ThreadLocalRandom.current().nextInt(100)` method to generate a uniformly distributed random integer with a value range of 0 to 99 (inclusive), meaning that the probability of each integer being generated is 1%.

[0094] If the random integer is less than the grayscale ratio value, the pre-release version is selected for execution. In this embodiment, the random integer generated by the engine is compared with the grayscale ratio value of the strategy. If the value of the random integer is less than the grayscale ratio value, the current risk control request is routed to the pre-release version. Specifically, the engine loads the complete configuration of the strategy version corresponding to the pre-release version identifier (preLaunchVersionId) from the local cache, including the rule definition list, rule execution order, risk threshold (low / medium / high risk threshold), and other information. Then, it executes rule judgment and strategy decision according to the configuration of the version, and finally outputs the risk level decision result based on the pre-release version.

[0095] If the random integer is greater than or equal to the grayscale ratio value, then the online version is selected for execution.

[0096] In this embodiment, if the generated random integer is greater than or equal to the grayscale ratio value, the current risk control request is routed to the online version. Specifically, the engine loads the complete configuration of the policy version corresponding to the online version identifier (onlineVersionId) from the local cache, performs rule judgment and policy decision according to the rule definition list, rule execution order and risk threshold of that version, and finally outputs the risk level decision result based on the online version.

[0097] In this embodiment, through the grayscale traffic splitting logic, when the grayscale ratio is set to 10, the probability of a random integer falling within the range of 0 to 9 is 10%, meaning approximately 10% of the traffic is routed to the pre-release version; the probability of a random integer falling within the range of 10 to 99 is 90%, meaning approximately 90% of the traffic continues to execute the online version. When the grayscale ratio is set to 1, approximately 1% of the traffic is routed to the pre-release version, achieving traffic grayscale control with a minimum precision of 1%. When the grayscale ratio is set to 0, all traffic executes the online version (equivalent to not enabling grayscale release); when the grayscale ratio is set to 100, all traffic executes the pre-release version (equivalent to a full release of the new version).

[0098] As a preferred implementation, the risk control engine generates random integers independently each time it executes strategy decision-making processing. The generation of random numbers between requests is independent of each other, ensuring statistical independence of traffic allocation. Statistically, under a large number of requests, the proportion of traffic received by the pre-release version approaches the set value for the gray-scale distribution. This random traffic distribution method does not require maintaining any state information (such as a mapping table between user IDs and version numbers), requires no additional storage overhead, and adjustments to the gray-scale distribution can take effect in real time, making it ideal for operational needs in risk control scenarios that require frequent adjustments to the gray-scale distribution.

[0099] As an optional implementation, for scenarios where the same user consistently receives the same version across multiple requests (i.e., scenarios with high requirements for user experience consistency), the canary traffic splitting mechanism of this invention also supports routing based on user ID hash values. Specifically, the engine pre-configures a list of user ID field names (such as userid, userId, user_id, uid), sequentially retrieves the first non-empty user ID value from the risk control context, calculates the absolute value of its hash value, modulo 100, and compares it with the canary ratio value. This method ensures that the same user ID is always routed to the same version, suitable for business scenarios requiring consistent user experience, but at the cost of requiring the business side to provide a stable user ID field in the event data. Under the default configuration, the engine adopts a random traffic splitting method to achieve minimal implementation complexity and maximum operational flexibility.

[0100] As a preferred implementation, the execution logic for both the pre-release and online versions reuses the same rule execution engine (i.e., the rule judgment layer and strategy decision layer described in the aforementioned embodiments), with only the input strategy version configuration differing. By marking the currently executed version identifier (whether it is the pre-release or online version) in the risk control context, all logs and hit records during rule execution carry this version identifier. This facilitates the differentiation between gray-scale traffic and online traffic during subsequent hit analysis using Elasticsearch, enabling the evaluation of the rule hit performance and risk distribution of the pre-release version, and providing data support for adjusting the gray-scale ratio and the final release of the version.

[0101] In this embodiment, an offline data backscan step is also included: In response to the scanback task start request, historical event data is read from the offline data source by day partitioning and cursor pagination; In this embodiment, risk control operations personnel create backscan tasks through the management backend, specifying parameters such as the backscan model, execution strategy, strategy version, backscan time range (start and end dates), and hit score interval. The management backend persists the backscan task information to the `pc_scan_task` table in the MySQL database, with the task initially set to PENDING. Subsequently, the scheduler (such as a `ScanTaskScheduleTask` periodic task implemented based on xxl-job) triggers task execution according to the task's scheduling configuration (single execution or Cron periodic execution).

[0102] In response to the backscan task start request, the backscan executor (ScanTaskExecutorApiService) starts execution asynchronously via @Async("scanTaskPool"). The executor first loads the complete configuration information of the backscan task from MySQL, including the backscan model ID, policy ID, policy version ID, backscan start date, backscan end date, and upper and lower limits of the hit score. Then, the executor updates the task status to RUNNING and initializes the task execution progress information.

[0103] The executor reads historical event data from the offline data source (Doris) by day partition. Specifically, the executor traverses each day in order from the start date to the end date of the scan. For each day's data partition, the executor uses a cursor pagination method to read the data. Cursor pagination uses the primary key `sort_id` (or auto-incrementing ID) of the Doris data table as the cursor field. Each query carries the `sort_id` of the last record in the previous batch as the query condition (WHERE sort_id>lastSortId), and reads data sequentially in fixed batch sizes (e.g., 1000 records per batch) until all data in that day's partition has been read. Cursor pagination has significant advantages over traditional OFFSET pagination: In deep pagination scenarios (e.g., when the offset reaches millions), OFFSET pagination requires the database to scan and skip a large number of data rows, resulting in a sharp performance drop; while cursor pagination directly locates the data using the primary key index, scanning only the number of data rows the size of the batch in each query, resulting in stable performance and making it suitable for batch reading of massive amounts of data.

[0104] For each batch of historical event data read, the risk control processing logic is reused to execute risk control decisions, and the real-time data writing and message queue notification steps are skipped; For each batch of historical event data read, the executor calls the realScanTimeRadarV3 interface of the real-time risk control engine, reusing the four-layer risk control pipeline processing logic (i.e., preprocessing layer, abstract processing layer, rule judgment layer, and strategy decision layer) from steps S3 and S4 above to execute risk control decisions. The difference from the real-time risk control mode is that in offline scanback mode, the engine skips the following two steps: (1) Skip real-time data writing: In real-time risk control mode, the engine writes event data to the MongoDB event database after completing preprocessing (for subsequent abstract processing, aggregation queries, and event tracing). In offline backscan mode, historical event data already exists in the Doris data source and does not need to be written to MongoDB. Therefore, the engine skips the MongoDB write operation to avoid additional write pressure on the real-time event storage.

[0105] (2) Skipping the message queue notification process: In real-time risk control mode, the engine will asynchronously push the decision results to the Kafka message queue after outputting the decision results (for downstream risk control alarms, data analysis, and visualization dashboards to consume). In offline backscanning mode, the backscanning results are statistically recorded by the backscanning task itself, and there is no need to notify the downstream system through Kafka. Therefore, the engine skips the Kafka message sending process.

[0106] For each historical event data in the batch, the engine executes the complete four-layer risk control pipeline and outputs the risk level decision result. The executor determines whether the event is hit based on the hit score range (block_score_min and block_score_max) configured in the backscan task: if the risk score output by the engine is within the hit score range (closed range, i.e., block_score_min ≤ score ≤ block_score_max), it is determined to be a hit event, the executor increments the hit count, and triggers subsequent penalty distribution operations (such as writing the event to the penalty record table, adding it to the Redis blacklist, sending an alarm notification, etc.); if the risk score is not within the hit score range, it is determined to be a miss event, and only the processing completion count is incremented.

[0107] After each batch of processing is completed, the current processing progress is persisted to the task state storage. The current processing progress includes at least the current processing date and the current cursor position. After each batch is completed, the executor persists the current processing progress to the task state store (MySQL's pc_scan_task table). The current processing progress includes at least the following two key fields: (1) Current processing date (current_day): This indicates the date of the data partition currently being processed. Once all data in a partition on a given day has been processed, current_day is updated to the date of the next day.

[0108] (2) Current cursor position (current_idx): Represents the sort_id value of the last processed data in the current date partition. After the batch processing is completed, current_idx is updated to the sort_id of the last record in the batch.

[0109] In addition, the executor updates the finish_count (total data processed) and hit_count (total data hits) statistical fields in real time. All progress fields are updated via database transactions after each batch is completed, ensuring the persistence and consistency of progress data.

[0110] The core value of the breakpoint resume mechanism lies in the recovery scenario after task interruption. When a backscan task is interrupted due to system restart, manual pause, network jitter, or insufficient resources, operators can restart the task. When the task restarts, the executor first reads current_day and current_idx from the MySQL task state store and continues execution from that position, without having to rescan all historical data from the beginning. This is extremely important in large-scale backscan scenarios—for example, if a backscan task has processed 20 days of data (out of 30 days), and it is interrupted and then resumed, the breakpoint resume mechanism only needs to continue execution from day 21, avoiding the duplication of processing the first 20 days of data and saving a significant amount of time and computing resources.

[0111] When a task termination signal is detected, the current processing progress is saved and the task is terminated; when the task is restarted, the current processing progress is read from the task state storage and execution is resumed. The task termination signal is stored in Redis, and each risk control engine node detects the task termination signal between each batch processing interval. In this embodiment, the termination signal of the backscan task is stored in Redis, and each risk control engine node detects the signal between each batch processing interval, thereby realizing the ability of any node to initiate task termination in a distributed environment.

[0112] Specifically, when an operations staff member initiates a task termination operation through the management backend, the management system writes a termination signal marker with a predefined key name (e.g., pc_radar:scan:abort_task:{taskId}) to Redis and sets a reasonable expiration time (e.g., 10 minutes). After each batch is processed and before the next batch begins reading, the backscan executor actively checks Redis for the existence of this termination signal. If the termination signal is detected, the executor immediately stops reading and processing data in subsequent batches, persists the current processing progress to MySQL (saving the current date and cursor position), updates the task status to ABORTED, and then releases thread resources and exits execution.

[0113] The advantage of Redis's termination signal mechanism lies in its multi-node visibility: Since Redis is an independent distributed storage middleware, all risk control engine nodes can access the same Redis instance. Regardless of which node initiates the termination operation (e.g., the node where the management backend resides), once the termination signal is written to Redis, all worker nodes executing the scanback task can detect the signal during batch intervals and stop execution, avoiding the problem of termination instructions being lost in a multi-node environment. Simultaneously, the Redis key's expiration time ensures that even if the executor fails to clean up the termination signal in time, the signal will automatically expire after the timeout, preventing interference with subsequent task execution.

[0114] In the offline data backscanning step, the rate of batch processing is controlled by a rate limiter, and the rate parameter of the rate limiter can be dynamically adjusted.

[0115] In this embodiment, the offline data backscanning step controls the batch processing rate through a rate limiter to prevent the backscanning task from consuming too many engine resources and affecting the normal service of real-time risk control. Specifically, the backscanning executor uses GuavaRateLimiter as the rate limiter. Before each batch processing begins, the executor calls the RateLimiter.acquire() method to obtain processing permission. This method blocks the current thread until permission is obtained, thereby controlling the batch processing rate. After the batch processing is completed, the executor records the processing time of this batch, calculates the actual throughput, and adjusts the scheduling interval of subsequent batches so that the processing rate smoothly converges to the configured target rate.

[0116] Specifically, the rate parameter is managed through the Apollo configuration center, and the ScanPoolApolloRefreshListener in the backscan executor listens for configuration change events in the Apollo configuration center. When operators adjust the backscan rate limit through the Apollo console, the configuration change is pushed to all risk control engine nodes in real time. After receiving the change notification, the ScanPoolApolloRefreshListener dynamically updates the rate parameter of RateLimiter (via the RateLimiter.setRate() method), which takes effect without restarting the service. This design allows operators to flexibly adjust the execution speed of backscan tasks according to the current load of the real-time risk control system, reducing the backscan rate during peak business periods to prioritize the service quality of real-time risk control, and increasing the backscan rate during off-peak business periods to accelerate the completion of backscan tasks.

[0117] In this embodiment, a strategy version release timed step is also included: In response to a scheduled release request, the target policy version and its scheduled release time are written to a Redis delayed queue; When the Redis delay queue detects that the scheduled release time has arrived, it triggers a release event and sets the target policy version to the pre-release version or the online version.

[0118] In actual risk control operations, strategy deployments typically need to be coordinated with off-peak business hours to minimize the potential impact of strategy changes on online operations. For example, operations staff might want to schedule a new strategy to be automatically deployed at 2 AM during off-peak hours; or to coordinate with the start time of a marketing campaign, activating the corresponding risk control strategy simultaneously with the campaign's launch. Traditionally, operations staff need to manually perform the deployment at the target time, which not only increases manpower but also risks missing the optimal deployment opportunity due to delays or oversights.

[0119] In this embodiment, the strategy version timed release step is specifically implemented as follows: When an operations staff member initiates a scheduled release operation for a policy version through the management backend, the management console responds to the scheduled release request by first performing necessary business checks, including: verifying that the target policy version exists and its status is either draft or pending release; verifying that the scheduled release time is later than the current time (if the scheduled release time has expired, the user is prompted to select a new time); and verifying that there are other ongoing release tasks for this policy. After the checks pass, the management console writes the scheduled release task information to the Redis delayed queue.

[0120] Specifically, this embodiment uses Redis's Sorted Set (ZSet) data structure to implement the delayed queue. Each element in the ZSet is a scheduled publishing task. The element's score is the Unix timestamp (millisecond precision) of the scheduled publishing time, and the element's value is the detailed content of the scheduled publishing task. To ensure the integrity and parsability of the task content, the scheduled publishing task content is serialized into a JSON format and stored as a string. This JSON object includes at least the following fields: activationId: Policy identifier, used to locate the target policy for which the publishing operation needs to be performed; versionId: Policy version identifier, used to locate the specific version to be published; publishType: Publishing type, used to indicate whether this publishing sets the target version to a pre-release version or an online version; createTime: Task creation time, used for recording and auditing.

[0121] The management console uses the Redis ZADD command to write the serialized scheduled release task into a ZSet, setting the score value to the millisecond-level timestamp of the scheduled release time. For example, if operations personnel set a certain version to be released at 12:00:00 on July 1, 2026, the score value would be the millisecond-level timestamp corresponding to that time. After writing, the management console updates the status of the target policy version to "PUBLISHING" and records detailed information about the scheduled release task in the database (including the scheduled release time, operator, target version, etc.) for subsequent traceability and auditing.

[0122] In this embodiment, a monitoring mechanism is required to continuously detect whether tasks in the Redis delay queue have reached their scheduled release time, and automatically trigger a release event upon arrival. As a preferred implementation, this embodiment uses Redis's Keyspace Notifications mechanism combined with ZSet's score range query function to achieve expiration detection. Specifically, a separate delay queue consumer thread (or scheduled task) is deployed in the risk control engine. This consumer scans the ZSet at a fixed frequency (e.g., every 1 second). During each scan, the consumer uses the Redis ZRANGEBYSCORE command to query all task elements with a score value less than or equal to the current timestamp, i.e., to query all scheduled release tasks whose scheduled release time has arrived but has not yet been triggered. If the query result is not empty, the consumer retrieves each task element sequentially and executes the corresponding release operation.

[0123] Specifically, for each expiring task, the consumer performs the following publishing operation: First, based on the activationId and versionId in the task element, it loads the complete configuration information of the target policy and target version from the metadata database (MySQL); then, based on the publishType field in the task element, it sets the target version identifier to the online version identifier (onlineVersionId) or the pre-release version identifier (preLaunchVersionId) of the policy; finally, through the Redis publish-subscribe mechanism described in Embodiment 1 above, it broadcasts the policy version change notification to all risk control engine nodes, enabling each node to update the policy configuration in its local cache. After the publishing operation is completed, the consumer removes the task element from the Redis ZSet (via the ZREM command), updates the task status to "published" (PUBLISHED), and writes a publishing record (activation_publish_record table) for auditing.

[0124] It should be noted that Redis's keyspace notification mechanism is a best-effort mechanism, and notifications may be lost under certain abnormal circumstances (such as network jitter, Redis server restart, etc.). Therefore, this embodiment does not rely solely on real-time push of keyspace notifications, but instead actively pulls expired tasks by scanning ZSets at regular intervals as described above. This method, with a sufficiently high scanning frequency, can ensure that the scheduled deployment tasks are triggered and executed within 1 second after the scheduled time arrives, and the accuracy meets the actual needs of risk control scenarios.

[0125] To further ensure the reliability of scheduled release tasks, this embodiment also incorporates a fallback scanning mechanism for periodic tasks. Specifically, the risk control engine deploys a periodic task (ActivationVersionTask) based on xxl-job. This task scans the metadata database (MySQL) at a high frequency (e.g., every 10 minutes) for version records that are in the "Release in Progress" state but whose scheduled release time has expired and have not yet been completed. If a timed-out unreleased task is detected, the periodic task automatically re-triggers the release operation, ensuring that even in the event of anomalies in the Redis latency queue (such as data loss, Redis service unavailability, or other extreme cases), the scheduled release task can still be executed through a fallback database scan. The specific implementation of this fallback scanning mechanism will be described in further detail in subsequent embodiments.

[0126] In this embodiment, a fallback step is also included, which is to release information at regular intervals. The Redis delay queue is scanned periodically for release tasks whose scheduled release time has expired but have not yet been triggered. Perform a re-release operation on the timed-out release task.

[0127] The fallback mechanism described in this embodiment works in conjunction with the Redis delayed queue-based timed release mechanism to form a double-insurance architecture of the main path and the fallback path, ensuring that the timed release task can still be reliably executed under abnormal circumstances.

[0128] In this embodiment, the scheduled release function of the policy version is implemented as a delayed queue using a Redis sorted set (ZSet). A consumer thread periodically scans for expired tasks and triggers the release operation. However, in a real production environment, the following abnormal situations may occur, causing the scheduled release task to fail to be triggered normally: First, a temporary failure occurs in the Redis service (such as network partitioning, master-slave switching, memory eviction, etc.), resulting in the loss or temporary inaccessibility of task elements stored in the ZSet; Second, the delayed queue consumer thread exits abnormally or experiences a prolonged GC pause, failing to perform the scan when the scheduled release time arrives; Third, an abnormality occurs during the release operation (such as database connection timeout, version configuration loading failure, etc.), causing the release operation to be incomplete while the task has been removed from the ZSet. Any of the above situations may lead to the omission of scheduled release tasks, affecting the timely deployment of the policy.

[0129] To address the above issues, this embodiment provides a timed release fallback step: I. Periodic task scans that have timed out and not been triggered - Release task In this embodiment, a periodic task (ActivationVersionTask) based on xxl-job is deployed in the risk control engine. This periodic task starts on a schedule according to a preset frequency (e.g., once every 10 minutes). Each time it starts, the periodic task queries the engine_activation_version table in the metadata database (MySQL) for all version records that meet the following conditions: the publish_status field value is PUBLISHING, indicating that there is currently an ongoing release task for this version; the push_start_time field value (scheduled release time) is less than the current timestamp, indicating that the scheduled release time has arrived or timed out; the push_end_time field value is empty or the default value (0), indicating that the release task has not yet been completed (i.e., the release operation has not been actually performed).

[0130] In this embodiment, the query condition actually locates version records whose scheduled release time has arrived but have not yet been released. Under normal circumstances, when a scheduled release task is successfully triggered and executed through the Redis delayed queue, the system immediately updates the publish_status of the version record to PUBLISHED and writes the push_end_time to the current timestamp. Therefore, this version record will not be detected by subsequent periodic tasks. Only in abnormal situations (Redis delayed queue failure or consumer malfunction) will the version record remain in the PUBLISHING state and the push_end_time be empty, thus being identified by the periodic task as a timed-out unreleased task.

[0131] 2. Perform a re-release operation on tasks that have timed out. After the periodic task scans for expired and unreleased version records, it performs a re-release operation on each record. Specifically, the periodic task performs the following sub-steps for each expired task: The periodic task loads the complete configuration information for the policy version from the database, including the policy identifier (activation_id) associated with the version, the version number, and the list of rule definitions. Simultaneously, the periodic task loads the current configuration of the corresponding policy (Activation), confirming the current status of the online version identifier and the pre-release version identifier of the policy to avoid version conflicts—for example, if operations personnel have manually released the version or rolled back to another version during the scheduled task's timeout period, the periodic task skips this re-release operation to avoid overwriting the results of manual operations.

[0132] If the version status is confirmed to be still publishable, the periodic task executes the same publishing operation logic as in Example 9: the identifier of the policy version is set to the online version identifier (onlineVersionId) or pre-release version identifier (preLaunchVersionId), depending on the publishing type (publishType) specified when the scheduled publishing task is created. If the publishing type is "publish as pre-release version", the preLaunchVersionId field of the policy is updated; if the publishing type is "publish as online version", the onlineVersionId field of the policy is updated.

[0133] The periodic task broadcasts policy version change notifications to all risk control engine nodes through the Redis publish-subscribe mechanism (as described in Example 1), enabling each node to update the policy configuration in its local cache and ensuring that the version change takes effect in real time.

[0134] The periodic task updates the version record in the metadata database with the publish_status set to PUBLISHED (published), writes the push_end_time to the current timestamp, and writes a fallback publish record in the publish record table (activation_publish_record) to mark this publish as a "fallback publish" (i.e., an automatic publish triggered by the periodic task). The reason for the fallback trigger is recorded (e.g., "scheduled publish timed out, and the periodic task is used as a fallback") for subsequent auditing and troubleshooting.

[0135] In this embodiment, a policy version rollback step is also included: In response to a policy version rollback request, obtain the identifier of the previous version of the target policy; Update the online version identifier of the target strategy to the previous version identifier, and set the original online version identifier to the pre-release version identifier.

[0136] The rollback mechanism described in this embodiment works in conjunction with the canary release mechanism and scheduled release mechanism described in the previous embodiments to jointly constitute the full lifecycle management capability of policy versions. When a newly released policy version encounters an anomaly (such as a surge in false blocking rate, rule logic errors, etc.), operations personnel can quickly restore to the previous stable version with a one-click rollback, minimizing the impact of policy misconfiguration on business.

[0137] In actual risk control operations, even after gray-scale testing, new policy versions may still exhibit unexpected behavior due to unaddressed long-tail scenarios after deployment. For example, new rules might generate a large number of false blockers because they don't consider the behavioral patterns of certain specific user groups, leading to a surge in complaints from legitimate users. In such cases, operations personnel need to be able to quickly revert the policy to a previous known stable version to restore the business's normal risk control level, while retaining the configuration of the problematic version for subsequent troubleshooting.

[0138] In this embodiment, the policy version rollback step is specifically implemented as follows: 1. In response to a policy version rollback request, obtain the identifier of the previous version of the target policy. When an operations staff member initiates a version rollback operation for a policy through the management backend, the management system responds to the rollback request by first performing necessary business validations. These validations include, but are not limited to: whether a version of the target policy currently exists online (if no version exists, the rollback operation is meaningless, and the user will be notified); whether the online version of the target policy is allowed to be rolled back (for example, if the online version is the initial version of the policy and there is no previous version to trace, the rollback operation cannot be executed); and whether other deployment tasks are currently in progress. After successful validation, the management system loads the complete configuration information of the target policy from the `engine_activation` table in the metadata database (MySQL).

[0139] Specifically, each policy maintains a `previous_version_id` field (identifier of the previous online version) in the metadata database. This field is updated synchronously with each policy version release: when a version is set as the online version, the original online version identifier is recorded as `previous_version_id`, which is the "previous version" of the current online version. For example, if the current online version of the policy is V1.2, then `previous_version_id` points to V1.1. Through this field, each policy always retains its most recent version evolution history, providing a clear target for rollback operations.

[0140] The management system extracts the `previous_version_id` field value from the loaded policy configuration information, using it as the target version identifier for rollback. If `previous_version_id` is empty or 0, it indicates that the current online version is the first version of this policy, and there is no previous version to roll back to. The management system returns an error message, informing the operations staff that there is no historical version to roll back to for this policy.

[0141] 2. Update the online version identifier of the target strategy to the previous version identifier, and set the original online version identifier to the pre-release version identifier. After obtaining the previous version identifier, the management system performs a rollback operation. The core logic of the rollback operation involves updating the dual-version field of the policy, specifically including the following sub-steps: The management system loads the complete configuration information of the version corresponding to the previous version identifier from the metadata database, confirming that the version's status is "published" and has not been logically deleted. If the current status of the previous version is abnormal (e.g., it has been disabled or deleted), the rollback operation is terminated, and the operations personnel are notified that the target rollback version is unavailable.

[0142] The management console performs the following field update operations within a database transaction: (1) Update the online_version_id field of the policy to the value of previous_version_id, that is, make the previous version become the online version again; (2) Update the pre_launch_version_id field of the policy to the original online version identifier before the rollback (i.e., the currently effective online version), so that the rolled-back version becomes a pre-release version instead of being discarded directly. The core consideration of this design is that after the rollback, the original online version (i.e. the version with the problem) is still retained in the system as a pre-release version. Operations personnel can continue to debug and fix the version after the rollback. After the fix is ​​completed, the version can be re-released or gray-scale verification can be performed again without creating the version from scratch.

[0143] (3) Update the previous_version_id field of the policy to the previous version identifier of the original online version before the rollback (i.e. the predecessor version of the original previous_version_id) to maintain the continuity of the policy version chain.

[0144] The management console broadcasts the policy version change notification to all risk control engine nodes via the Redis publish-subscribe mechanism (as described in Example 1), causing each node to update the policy configuration in its local cache. Upon receiving the notification, each engine node invalidates the configuration data for that policy in its local cache and reloads the latest dual-version configuration from the metadata database on the next access. At this point, the rollback operation is complete, and all subsequent risk control requests will automatically execute the rolled-back online version.

[0145] As a preferred implementation, after the rollback operation is completed, the management system writes a rollback record to the activation_publish_record table, recording the execution time of the rollback operation, the operator, the version before rollback, the version after rollback, and the reason for rollback (filled in by the operations personnel when initiating the rollback). This record is used for subsequent auditing and issue tracing, helping the operations team analyze the root causes of policy issues and prevent similar issues from recurring.

[0146] Example 2 Please see Figure 1 and Figure 2 This invention provides a real-time risk control system based on dual engines and grayscale release, including a computer-readable storage medium and a processor. The storage medium stores a computer program, which, when executed by the processor, implements the method as described in any one of Embodiment 1.

[0147] In this embodiment, the system further includes: The metadata management module is used to configure risk control metadata and store it in the metadata database. This module serves as the configuration management center for the risk control system, responsible for maintaining all metadata configuration information required for the risk control engine to operate. Specifically, the metadata management module provides a visual management interface (such as the radar-ae front-end management platform) for risk control operations personnel to add, modify, delete, and query model configurations, field definitions, preprocessing items, abstract processing definitions, rule definitions, and strategy definitions. This module provides CRUD (Create, Read, Update, Delete) capabilities for metadata through Dubbo RPC interfaces (such as FieldApiService, PreItemApiService, AbstractionApiService, RuleApiService, ActivationApiService, etc.). When operations personnel submit metadata changes, the metadata management module first performs business validity verification (such as whether the number of search fields in abstract processing is within the range of 1 to 5, whether the rule script syntax is valid, and whether the rule sorting of the strategy references an existing rule ID, etc.). After successful verification, the changed risk control metadata is persistently stored in the metadata database (MySQL). The metadata management module also maintains a complete metadata version history (such as the rule_history table), supporting audit tracking and retrospection of configuration changes.

[0148] The cache synchronization module is used to synchronize configuration changes of the risk control metadata to the local cache of each risk control engine node via Redis publish-subscribe. This module is the core hub for hot configuration updates in the risk control system, ensuring that configuration changes from any management end can be synchronized to all risk control engine nodes within seconds without requiring a service restart. Specifically, the cache synchronization module consists of two parts: a publisher and a subscriber. The publisher is deployed in the management service. After the metadata management module completes the database write of the configuration changes, the publisher uses the Redis PUBLISH command to publish change notifications to preset configuration change channels (such as pc_radar:channel:rule, pc_radar:channel:activation, etc.). The subscriber is deployed in each risk control engine node. Each engine node subscribes to all configuration change channels at startup using the Redis SUBSCRIBE command and continuously listens for channel messages through a local cache expiration listener. When an engine node receives a configuration change notification, it parses the configuration identifier and operation type in the notification content, invalidating the corresponding risk control metadata in its local cache (an in-memory cache implemented based on ConcurrentHashMap). The next time the engine node accesses this risk control metadata, it reloads the latest configuration from the metadata database and updates its local cache.

[0149] The event access module receives risk control event data submitted by the business system. This module serves as the entry point for the risk control system, providing a unified real-time risk control interface. Specifically, the event access module exposes a real-time risk control service interface (such as realTimeRadarV3) via the Dubbo RPC protocol. The business system submits risk control event data by calling this interface through a Dubbo client. Risk control event data includes at least an event identifier (such as requestId) and event field information (key-value pairs organized in JSON format). Upon receiving a request, the event access module first performs basic parameter validation (including request parameter non-empty validation, JSON format validation, and required field validation). After successful validation, the event access module loads the corresponding model configuration based on the model GUID in the request and performs field type validation and data normalization processing on the event field information (such as device ID normalization and filling missing fields with default values). After completing the above preprocessing, the event access module encapsulates the risk control event data into a unified risk control context object and passes it to the risk control engine module for subsequent processing.

[0150] The risk control engine module performs a four-layer risk control pipeline processing on the risk control event data. This four-layer pipeline includes a preprocessing layer, an abstract processing layer, a rule-based judgment layer, and a strategy decision layer. This module is the core decision-making unit of the risk control system, responsible for connecting the complete risk decision-making chain.

[0151] The preprocessing layer includes the Aviator expression engine for performing lightweight mathematical expression calculations. Specifically, driven by preprocessing item configurations, the preprocessing layer extracts basic features from the raw fields of the risk control event data. For preprocessing items configured as expression processing types, the preprocessing layer calls the Aviator expression engine to perform mathematical expression calculations (such as arithmetic operations, logical comparisons, ternary operations, etc.), and the calculation results are stored as preprocessed feature values ​​in the risk control context. For preprocessing items configured as plugin processing types, the preprocessing layer calls the corresponding preprocessing plugins (such as IP address location resolution plugins, mobile phone number location resolution plugins, list matching plugins, etc.) to perform feature extraction. The preprocessing layer also supports concurrent execution of multiple plugins via a thread pool to improve preprocessing efficiency.

[0152] The abstract processing layer is responsible for performing aggregate feature calculations from the event database (MongoDB) according to a preset time window, based on the processing results of the preprocessing layer. Specifically, the abstract processing layer dynamically constructs a MongoDB aggregate query pipeline and performs aggregate calculations based on the search fields, search time intervals, and aggregation types (including 10 types: COUNT, DISTINCT_COUNT, SUM, AVG, MAX, MIN, SD, VARIANCE, DEVIATION, and MEDIAN) defined in the abstract processing definition. The aggregation results are stored as abstract feature values ​​in the risk control context.

[0153] The rule-determination layer includes a Groovy script engine for executing rule scripts. Specifically, the rule-determination layer executes the rule scripts (Boolean logic expressions written in Groovy) defined in the rule definition through the Groovy script engine, matching the processing results of the preprocessing layer and the abstract processing layer with preset rules. When a rule is matched, the corresponding risk score is accumulated. The Groovy script engine maintains a cache pool of compiled scripts; the same script content is compiled only once, and subsequent executions reuse the compiled artifacts.

[0154] The strategy decision layer is responsible for comparing the accumulated risk score from the rule judgment layer with a preset risk threshold and outputting a risk level decision result. During execution, the strategy decision layer supports a canary release mechanism—randomly selecting between the online version and the pre-release version based on the canary release ratio of the strategy, specifically implemented by the canary release module. Data is passed between the four layers through a unified risk control context object, achieving complete decoupling between feature calculation and rule judgment.

[0155] The preprocessing layer includes the Aviator expression engine for performing lightweight mathematical expression calculations. The cache synchronization module synchronizes configuration changes of the risk control metadata to the local cache of each risk control engine node via Redis publish-subscribe. This module is the core hub for the risk control system to achieve hot configuration updates, ensuring that configuration changes from any management end can be synchronized to all risk control engine nodes within seconds without restarting the service. Specifically, the cache synchronization module consists of two parts: a publisher and a subscriber. The publisher is deployed in the management service. After the metadata management module completes the database write of the configuration changes, the publisher uses the Redis PUBLISH command to publish change notifications to preset configuration change channels (such as pc_radar:channel:rule, pc_radar:channel:activation, etc.). The subscriber is deployed in each risk control engine node. Each engine node subscribes to all configuration change channels at startup using the Redis SUBSCRIBE command and continuously listens for channel messages through a local cache expiration listener. When an engine node receives a configuration change notification, it parses the configuration identifier and operation type in the notification content, invalidating the corresponding risk control metadata in its local cache (an in-memory cache implemented based on ConcurrentHashMap). The next time the engine node accesses this risk control metadata, it reloads the latest configuration from the metadata database and updates its local cache. Through this publish-subscribe-invalidate-reload closed-loop mechanism, the cache synchronization module achieves accurate, efficient, and real-time synchronization of configuration changes.

[0156] The rule judgment layer includes a Groovy script engine for executing rule scripts; The strategy version management module is used to maintain the online version identifier, pre-release version identifier, and grayscale ratio value of each strategy; The strategy version management module maintains the online version identifier, pre-release version identifier, and canary scale ratio value for each strategy. This module is the core of the risk control system for implementing full lifecycle management of strategy versions. Specifically, the strategy version management module provides complete operational capabilities for creating, copying, deleting, querying, enabling, disabling, publishing (including immediate and scheduled publishing), and rolling back strategy versions. This module maintains the following key fields for each strategy in the metadata database: online_version_id (current online version identifier), pre_launch_version_id (pre-release version identifier), previous_version_id (previous online version identifier), and ratio (canary scale ratio value, an integer from 0 to 100). When operations personnel perform a version publishing operation, the strategy version management module updates the above fields and synchronizes the changes to all engine nodes through the cache synchronization module. The strategy version management module also supports scheduled version publishing: operations personnel can set a scheduled publishing time, and the strategy version management module writes the scheduled publishing task to a Redis delayed queue (ZSet), which is automatically triggered by the consumer thread when the scheduled time arrives. Meanwhile, the strategy version management module also includes a fallback scanning mechanism, which uses xxl-job periodic tasks to scan for unreleased version records that have timed out and then performs a re-release.

[0157] The grayscale splitting module is used to generate random numbers and select one of the online version and the pre-release version to execute based on the comparison result of the random numbers and the grayscale ratio value; The canary-scale routing module generates random numbers and selects one of the online version or the pre-release version to execute based on a comparison between the random numbers and the canary-scale ratio value. This module is a key execution unit for the risk control system to achieve secure policy release. Specifically, when the risk control engine module executes policy decision-making processing, the canary-scale routing module first obtains the canary-scale ratio value (ratio field) of the current policy. If the canary-scale ratio value is 0 or there is no pre-release version, the canary-scale routing module directly selects to execute the online version without routing. If the canary-scale ratio value is greater than 0 and a pre-release version exists, the canary-scale routing module generates a random integer in the range of 0 to 99 using ThreadLocalRandom and compares this random integer with the canary-scale ratio value: if the random integer is less than the canary-scale ratio value, the pre-release version is selected to execute; if the random integer is greater than or equal to the canary-scale ratio value, the online version is selected to execute. The canary-scale routing module supports optional routing based on user ID hash values ​​to ensure consistent user experience for the same user, ensuring that the same version is always hit in multiple requests. The canary-scale ratio value can be adjusted at any time on the management side and takes effect in real time through the cache synchronization module.

[0158] The decision output module is used to return the risk level decision results to the business system.

[0159] The decision output module is the exit layer of the risk control system. It is responsible for encapsulating the decision results produced by the risk control engine module into a standard response format and returning them to the business system caller via the Dubbo RPC interface. The decision results include at least the decision type (such as PASS, WARNING, SMS_VERIFICATION, BLOCK, FREEZE, etc.), risk level score, a list of hit rules, and the reason for the block (internal and external reasons). In addition, the decision output module asynchronously performs the following auxiliary operations: pushing the decision results to a message queue (Kafka) for downstream risk control alerts, data analysis, and visualization dashboards; writing the decision results to Elasticsearch for subsequent hit analysis and rule performance evaluation; and for decision results that hit rules, the decision output module also triggers corresponding penalty actions (such as adding the user to a Redis blacklist or sending an alert notification).

[0160] In this embodiment, an offline backscan module is also included. The offline backscan module is used to read historical event data from offline data sources, reuse the risk control engine module to execute risk control decisions, and support breakpoint resume and task termination.

[0161] The offline backscan module is used to read historical event data from offline data sources, reuse the risk control engine module to execute risk control decisions, and supports breakpoint resume and task termination. The offline backscan module described in this embodiment enables the same risk control engine core to simultaneously support both real-time streaming processing and offline batch processing modes, ensuring consistency between offline backscan results and real-time decision results. Furthermore, mechanisms such as breakpoint resume, multi-node termination, and rate limiting protection ensure the stable execution of long-cycle batch tasks.

[0162] In this embodiment, the offline scanback module is an independent functional unit within the risk control system, sharing the same core decision-making logic as the real-time risk control engine module. For example... Figure 2 As shown, the offline backscan module includes the following sub-components: a task management sub-module (responsible for the creation, configuration, status management, and lifecycle control of backscan tasks), a task scheduling sub-module (based on xxl-job to implement periodic scheduling and triggering of tasks), a data reading sub-module (responsible for reading historical event data from offline data sources by day partitioning and cursor paging), a decision execution sub-module (reusing the four-layer risk control pipeline of the risk control engine module to execute risk control decisions), a progress management sub-module (responsible for persistent storage of task progress and breakpoint recovery), and a rate limiting control sub-module (controlling the batch processing rate through RateLimiter). These sub-components work together to form a complete offline backscan capability.

[0163] The offline backscan module provides full lifecycle management capabilities for tasks through the backscan task management submodule. Risk control operations personnel create backscan tasks through the management backend, requiring configuration of the following key parameters: backscan model (the mapping relationship between the Doris data source table and the risk control model fields), execution strategy and strategy version (specifying which risk control rules to use during backscan), backscan time range (start and end dates), hit score interval (block_score_min and block_score_max, used to determine hit status), execution frequency (single execution or Cron cycle execution), and result processing method (e.g., whether to write to a blacklist, whether to send alarm notifications, etc.). After task creation, the task management submodule persists the task information to the pc_scan_task table in the MySQL database, with the initial task status being PENDING (pending execution).

[0164] The task scheduling submodule implements periodic task scheduling based on xxl-job. The scheduling submodule scans the database for tasks to be executed at a fixed frequency. For tasks that meet the execution conditions (including single tasks with a PENDING status, periodic tasks whose Cron expressions match the current time, etc.), the scheduling submodule triggers task execution through an asynchronous thread pool using @Async("scanTaskPool").

[0165] After the task starts, the data reading submodule reads historical event data from the offline data source, partitioned by day and paginated using cursors. Specifically, the data reading submodule iterates through the data day by day in order from the start date to the end date of the backscan. For each day's data partition, cursor pagination is used to read the data—using the primary key `sort_id` of the Doris data table as the cursor field, each query carries the `sort_id` of the last record in the previous batch (WHERE sort_id > lastSortId), and reads sequentially in fixed batch sizes (e.g., 1000 records per batch) until all data for that day's partition has been read. Cursor pagination avoids the performance degradation problem of traditional OFFSET pagination in deep pagination scenarios, ensuring the stability of reading massive amounts of data.

[0166] For each batch of historical event data read, the decision execution submodule reuses the risk control engine module to execute risk control decisions. Specifically, the decision execution submodule calls the realScanTimeRadarV3 interface of the risk control engine module. This interface shares the exact same four-layer risk control pipeline processing logic (i.e., preprocessing layer, abstract processing layer, rule judgment layer, and strategy decision layer) as the real-time risk control interface realTimeRadarV3. The only difference between the two is that the following two steps are skipped in offline backscan mode: skipping the real-time writing of MongoDB event data (historical data already exists in Doris and does not need to be stored repeatedly), and skipping the result notification of the Kafka message queue (backscan results are statistically recorded by the task itself). Through the above reuse mechanism, the logical consistency between offline backscan results and real-time decision results is ensured.

[0167] For each historical event data in the batch, the decision execution submodule determines whether the event has been hit based on the hit score range (block_score_min and block_score_max) configured in the task: if the risk score is within the range, it is determined to be a hit event, the hit count is incremented, and the corresponding penalty distribution operation is triggered (such as writing to the penalty record table, adding to the Redis blacklist, sending DingTalk alarm notification, etc.); if it is not within the range, only the processing completion count is incremented.

[0168] The offline scanback module enables breakpoint resume capability through the progress management submodule. After each batch is completed, the progress management submodule persists the current processing progress to the task state storage (MySQL's pc_scan_task table). The persisted progress information includes at least: the current processing date (current_day), the current cursor position (current_idx), the total amount of data processed (finish_count), and the total amount of data hit (hit_count). These progress fields are atomically updated through database transactions after each batch is completed, ensuring the consistency and durability of the progress data.

[0169] When a backscan task is interrupted due to a system restart, manual pause, or other abnormal reasons, operations personnel can restart the task. Upon restart, the progress management submodule first reads `current_day` and `current_idx` from the MySQL task state store. The data reading submodule then resumes execution from this point, eliminating the need to rescan all historical data from the beginning. For example, if a backscan task needs to process 30 days of historical data and is interrupted due to a system restart after processing day 20, the task resumption mechanism allows the executor to continue execution from day 21, avoiding repeated scanning of the first 20 days of data and significantly saving computing resources and time costs.

[0170] The offline scan module enables controlled task termination in a multi-node environment through Redis distributed signals. When an operator initiates a task termination operation through the management backend, the management end writes a termination signal flag with a predefined key name (e.g., pc_radar:scan:abort_task:{taskId}) to Redis and sets a reasonable expiration time (e.g., 10 minutes). After each batch is processed and before the next batch begins reading, the data reading submodule proactively checks Redis for the existence of this termination signal. If the termination signal is detected, the decision execution submodule immediately stops processing subsequent batches of data, the progress management submodule persists the current processing progress to MySQL, the task management submodule updates the task status to ABORTED (cancelled), and then releases thread resources and exits execution.

[0171] The key advantage of Redis's termination signal mechanism lies in its multi-node visibility. Because Redis is an independent distributed storage middleware, all risk control engine nodes can access the same Redis instance. Regardless of which node initiates the termination operation, once the termination signal is written to Redis, all worker nodes executing the scanback task can detect the signal during batch intervals and stop execution, completely solving the problem of lost termination instructions in multi-node environments. Simultaneously, the Redis key's expiration time ensures that even if the executor fails to clean up the termination signal in time, the signal will automatically expire after the timeout, avoiding interference with subsequent task execution.

[0172] The offline backscan module controls the batch processing rate through a rate limiting submodule to prevent backscan tasks from consuming excessive engine resources and affecting the normal operation of real-time risk control. The rate limiting submodule uses Guava RateLimiter as the rate limiter. Before each batch processing begins, the RateLimiter.acquire() method is called to obtain a processing permit. This method blocks the current thread until a permit is obtained, thus controlling the batch processing rate.

[0173] The rate limiter's rate parameters support dynamic adjustment. Specifically, the rate parameters are managed through the Apollo configuration center, and the configuration listener in the rate limiting control submodule listens for configuration change events in the Apollo configuration center. When operators adjust the backscan rate limit through the Apollo console, the configuration change is pushed to all risk control engine nodes in real time. After receiving the change notification, the listener dynamically updates the rate parameter of RateLimiter (using the RateLimiter.setRate() method), and the changes take effect without restarting the service. This design allows operators to flexibly adjust the execution speed of backscan tasks based on the current load of the real-time risk control system, reducing the backscan rate during peak business periods to prioritize the service quality of real-time risk control, and increasing the backscan rate during off-peak business periods to accelerate the completion of backscan tasks.

[0174] After the backscan task is completed, the task management submodule updates the task status to COMPLETED and summarizes the execution statistics for this backscan, including the total amount of data processed, the total amount of hit data, and the hit distribution over each day. The task notification submodule notifies the task creator of the execution results via DingTalk robot, internal messaging, etc. For periodically executed backscan tasks, the task management submodule automatically calculates the next execution time and waits for the next trigger from the scheduling submodule, thus realizing periodic backscan capability.

[0175] 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 or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A real-time risk control method based on dual engines and canary release, characterized in that, Includes the following steps: S1: Configure risk control metadata, which includes at least model configuration, field definition, preprocessing item, abstract processing definition, rule definition and strategy definition, and store the risk control metadata in the metadata database, and synchronize the configuration changes to the local cache of each risk control engine node through Redis publish and subscribe; S2: Receive risk control event data submitted by the business system, wherein the risk control event data includes at least an event identifier and event field information; S3: Perform four-layer risk control pipeline processing on the aforementioned risk control event data; S4: When executing the strategy decision layer processing, obtain the online version identifier and pre-release version identifier of the target strategy as well as the gray scale ratio value, generate a random number, and select one of the online version and the pre-release version to execute based on the comparison result of the random number and the gray scale ratio value, and output the risk level decision result. S5: Return the risk level decision result to the business system.

2. The real-time risk control method based on dual-engine and canary release according to claim 1, characterized in that, The process of synchronizing configuration changes to the local cache of each risk control engine node via Redis publish-subscribe includes the following steps: In response to changes to risk control metadata, the management system writes the updated risk control metadata into the metadata database. The management console publishes configuration change notifications to preset channels via Redis publish / subscribe. Each risk control engine node subscribes to the preset channel, and upon receiving the configuration change notification, invalidates the corresponding risk control metadata in the local cache of the risk control engine node. The risk control engine node reloads and updates the local cache from the metadata database the next time it accesses the risk control metadata.

3. The real-time risk control method based on dual engines and grayscale release according to claim 1, characterized in that, The four-layer risk control pipeline includes, in sequence: Preprocessing layer processing: Perform basic feature extraction on the raw fields in the risk control event data. The basic feature extraction includes performing lightweight mathematical expression calculation through the Aviator expression engine, and / or performing at least one of IP address location resolution, mobile phone number location resolution, and list matching through a plugin. Abstract processing layer processing: Based on the processing results of the preprocessing layer, aggregate feature calculation is performed from the event database according to a preset time window. The aggregate feature calculation includes at least one or more of COUNT, DISTINCT_COUNT, SUM, AVG, MAX, MIN, SD, VARIANCE, DEVIATION, and MEDIAN. Rule judgment layer processing: The rule script is executed through the Groovy script engine, and the processing results of the preprocessing layer and the processing results of the abstract processing layer are matched with the preset rules. When a rule is matched, the risk score is accumulated. The strategy decision layer processes the risk by comparing the accumulated risk score from the rule-based judgment layer with a preset risk threshold and outputting the risk level decision result.

4. The real-time risk control method based on dual engines and grayscale release according to claim 3, characterized in that, The Aviator expression engine and the Groovy script engine adopt a dual-track parallel architecture, wherein: The Aviator expression engine is used to perform mathematical expression calculations in the preprocessing layer and detect the execution time after the expression is executed. When the execution time exceeds a preset timeout threshold, an alarm log is recorded without interrupting the engine execution. The Groovy script engine is used to execute the rule scripts in the rule judgment layer and the filter scripts in the abstract processing layer.

5. The real-time risk control method based on dual engines and grayscale release according to claim 4, characterized in that, The Groovy script engine maintains a cache pool of compiled scripts. Specifically, when the rule definition or abstract processing definition changes, the script content before and after the change is compared. If the script content changes, the compilation artifact corresponding to the script before the change is removed from the compiled script cache pool; When executing a script, the Groovy script engine first retrieves the compiled script from the compiled script cache pool. If the cache is not found, the script is compiled and stored in the compiled script cache pool.

6. The real-time risk control method based on dual engines and grayscale release according to claim 2, characterized in that, The process of performing aggregate feature calculations from the event database according to a preset time window includes the following steps: Based on the search fields and search time ranges in the abstract processing definition, construct a MongoDB aggregate query pipeline; Based on the aggregation type in the abstract processing definition, dynamically select the corresponding aggregation command to perform aggregation calculation; The aggregated calculation result is returned as an abstract feature value and stored in the risk control context.

7. The real-time risk control method based on dual engines and grayscale release according to claim 6, characterized in that, The step of selecting one of the online version and the pre-release version to execute based on the comparison result of the random number and the grayscale ratio value includes the following steps: Generate random integers ranging from 0 to 99; If the random integer is less than the grayscale ratio value, then the pre-release version is selected for execution; If the random integer is greater than or equal to the grayscale ratio value, then the online version is selected for execution.

8. The real-time risk control method based on dual-engine and canary release according to claim 1, characterized in that, It also includes an offline data rescanning step: In response to the scanback task start request, historical event data is read from the offline data source by day partitioning and cursor pagination; For each batch of historical event data read, the risk control processing logic of steps S3 and S4 is reused to execute risk control decisions, and the real-time data writing and message queue notification steps are skipped. After each batch of processing is completed, the current processing progress is persisted to the task state storage. The current processing progress includes at least the current processing date and the current cursor position. When a task termination signal is detected, the current processing progress is saved and the task is terminated; when the task is restarted, the current processing progress is read from the task state storage and execution is resumed. The task termination signal is stored in Redis, and each risk control engine node detects the task termination signal between each batch processing interval. In the offline data backscanning step, the rate of batch processing is controlled by a rate limiter, and the rate parameter of the rate limiter can be dynamically adjusted.

9. A real-time risk control system based on dual-engine and grayscale release, comprising a computer-readable storage medium and a processor, wherein a computer program is stored on the storage medium, and the computer program, when executed by the processor, implements the method as described in any one of claims 1 to 8; characterized in that, Also includes: The metadata management module is used to configure risk control metadata and store the risk control metadata in the metadata database; The cache synchronization module is used to synchronize the configuration changes of the risk control metadata to the local cache of each risk control engine node through Redis publish-subscribe. The event access module is used to receive risk control event data submitted by the business system; The risk control engine module is used to perform four-layer risk control pipeline processing on the risk control event data. The four-layer risk control pipeline includes a preprocessing layer, an abstract processing layer, a rule judgment layer, and a strategy decision layer. The preprocessing layer includes the Aviator expression engine for performing lightweight mathematical expression calculations; The rule judgment layer includes a Groovy script engine for executing rule scripts; The strategy version management module is used to maintain the online version identifier, pre-release version identifier, and grayscale ratio value of each strategy; The grayscale splitting module is used to generate random numbers and select one of the online version and the pre-release version to execute based on the comparison result of the random numbers and the grayscale ratio value; The decision output module is used to return the risk level decision results to the business system.

10. The real-time risk control system based on dual engines and grayscale release according to claim 9, characterized in that, It also includes an offline backscan module, which is used to read historical event data from offline data sources, reuse the risk control engine module to execute risk control decisions, and support breakpoint resume and task termination.

Images