Multi-round incremental rule matching method, apparatus and medium for master-slave object data

Abstract

This invention proposes a method, apparatus, and medium for multi-round incremental rule matching of master-slave object data, relating to the field of database data processing technology. The method includes: monitoring master-slave object data in the database; when one of the master-slave object data changes, generating a structured change message, wherein the structured change message includes an identifier and a scope indicating the change in the master-slave object data; determining processing rules for matching the changed data from a rule base in the database based on the structured change message, and locating the row containing the changed data; using the processing rules to perform incremental recalculation of the master-slave object data based on the identifier, scope, and row containing the changed data; and providing core state memory functionality for multi-round incremental rule matching through the data structure of the last matched data and persistent storage in Redis, avoiding full recalculation and significantly improving computational efficiency.

Description

Technical Field

[0001] This invention relates to the field of database data processing technology, specifically to a method, apparatus, and medium for multi-round incremental rule matching of master-slave object data. Background Technology

[0002] In enterprise-level CRM / ERP systems, functions such as pricing, adjustment factors, and risk control often rely on rules involving multi-dimensional judgments (object attributes, time windows, historical cumulative indicators, etc.) and require millisecond-level response times in high-concurrency scenarios. The main drawbacks of existing technologies are:

[0003] Full recalculation solution: Lack of state memory. Traditional solutions perform independent one-time matching for each request, failing to save and reuse the state information of previous matches, leading to repeated calculations in multiple rounds of interaction; Incomplete incremental matching: Existing incremental calculations are only based on change detection of the current request, lacking continuity across requests and failing to achieve true multi-round incremental matching; Insufficient adaptation to master-slave object scenarios. Traditional solutions mainly target single objects or simple object relationships, lacking targeted optimization for handling complex master-slave object relationships; Aggregation statistics require repeated traversal of historical data tables, drastically increasing database pressure and resulting in poor scalability.

[0004] Simple incremental calculation scheme: When dealing with multidimensional rules and active object relationships, it lacks a precise change detection mechanism and cannot identify which specific fields have changed; it lacks cross-request state memory and cannot support true multi-round incremental matching; window aggregation still requires full-window statistics and cannot achieve incremental aggregation calculation; rule conflict and priority handling lack effective means and are prone to data inconsistency.

[0005] Windowed pre-computation solutions suffer from several drawbacks: near real-time processing is insufficient, batch processing granularity (minutes to hours) is difficult to meet second-level business needs; data expansion occurs, and the combination of multiple windows and multiple dimensions leads to storage expansion; parameter tuning is difficult, and adjusting windows or functions requires processing historical data. Summary of the Invention

[0006] In view of one or more technical defects in the prior art, the present invention proposes the following technical solution.

[0007] A multi-round incremental rule matching method for master-slave object data, the method comprising:

[0008] The change detection step monitors the master-slave object data in the database. When one of the master-slave object data changes, a structured change message is generated. The structured change message includes an identifier and the scope of the change that indicate the change in the master-slave object data.

[0009] The multi-dimensional rule engine filtering step determines the processing rules for matching the changed data from the rule base in the database based on the structured change message, and locates the row where the changed data is located;

[0010] Incremental recalculation step: Using the processing rules, perform incremental recalculation on the master-slave object data based on the identifier of the master-slave object data change, the scope of the change, and the row where the changed data is located;

[0011] The state memory step is used to save a snapshot of the key fields of each round of matching to achieve state memory capability across requests. Through the data structure of the last matching data and Redis persistent storage, it provides the core state memory function for multi-round incremental rule matching.

[0012] Furthermore, the change detection step involves: parsing the action code of the master-slave object data, and determining the change type as addition, editing, or deletion based on the parsing result; when the change type is editing, triggering a combination key cascading detection and filtering process, retaining only the changed data rows and identifying the aggregation rule type, and outputting a list of modified slave object indexes; performing multiple types of security comparisons on the rows covered by the modified slave object index list based on field comparisons to obtain a list of fields affected by the change; performing change analysis on the affected field list, determining the scope of influence, and performing field weight sorting and field-rule dependency analysis to generate a data index-rule identifier; and sending the data index-rule identifier to the multidimensional rule engine for incremental calculation.

[0013] Furthermore, in the multi-dimensional rule engine filtering process: the built-in rule expression DSL parser of the multi-dimensional rule engine is used to convert the JSON-formatted business rules into an abstract syntax tree, which is then handed over to the extended expression engine for just-in-time compilation into bytecode; the initial compilation result is cached in the local high-speed cache, and subsequent hits are executed directly; after receiving the structured change message, batch filtering is first performed according to the macro group dimension composed of rule combination ID + main object. The batch filtering includes a two-stage pipeline: Stage 1 – Condition Matching: Boolean expressions are executed in parallel to match the data attributes of the main and slave objects to obtain a set of rule candidates; Stage 2 – Row-level Judgment: the execution conditions of the candidate rules are evaluated row by row. Each data row and rule is traversed through a double loop, the expression judgment is executed and the matching results are collected. Only the data indexes that are truly affected are marked, and it is determined whether aggregation calculation is required. If so, the batch aggregation value retrieval interface is called uniformly, and the array of the returned aggregation rule ID and value Map is injected into the execution context for subsequent formulas to directly retrieve values; a single call can complete the calculation of N aggregation indicators.

[0014] Furthermore, in the incremental recalculation step: The input is a list of modified slave object indexes obtained based on change detection. The fields in the modified slave object index list are analyzed. If a field of the master object changes, all data indexes are directly included in the recalculation to avoid a full table scan. Based on the data index-rule identifier mapping, only rules related to the changed data rows are retained. If a row in a combined slave object changes, other rows in the same group are automatically added to the recalculation to avoid errors or omissions. If the user manually specifies a rule combination, its priority is set to the minimum integer value during the recalculation stage to ensure consistent results.

[0015] Furthermore, during recalculation, a rule conflict decision algorithm is used to provide a unique and predictable result when multiple executable rules are faced with the same data row. The rule conflict decision algorithm is as follows: the conflict set is stably sorted in descending order of priority; if there is any rule tuple with a user priority identifier equal to 1, the entire tuple is placed at the top, and other elements remain in their original order; if the head element still has the same priority and user priority identifier value, the one with the smallest creation time wins; a lock-free concurrency and consistency strategy is adopted to implement the following operations: the decision logic runs on a thread-local cached copy of the conflict set, without involving shared write operations; the result is written to the row-level decision tracing view dictionary through copy-on-write to avoid lock contention, wherein the user priority identifier is 1 only when the user explicitly selects it, otherwise it is 0.

[0016] Furthermore, change detection is performed using sparse bitmap change location: snapshot fields are mapped to sparse bitmaps, and the set of changed rows is obtained by comparing with the current request bitmap. The operation is optimized based on the master-slave object data scenario: a multi-level dependency graph is constructed, such as master-slave object data combination, to realize that a single point change automatically affects other data points. When breadth-first traversal reaches the weight threshold, the radius of influence is pruned. After deleting a row or disabling a policy, the row or policy is blacklisted for a certain period of time, and subsequent requests skip it directly. For data index-rule identification, a bitmap dependency pruning algorithm is used for optimization: pre-compile field bitmaps, generate a 256-bit bitmap when the rule is published to identify its field dependency set, and only one operation is needed during its runtime to determine "potential hit"; using two-layer pruning, the bitmap pruning can remove ≥50% of useless rules.

[0017] This invention also proposes a multi-round incremental rule matching device for master-slave object data, the device comprising:

[0018] The change detection unit monitors the master-slave object data in the database. When one of the master-slave object data changes, it generates a structured change message, wherein the structured change message includes an identifier and the scope of the change indicating the change in the master-slave object data.

[0019] The multi-dimensional rule engine filtering unit determines the processing rules for matching the changed data from the rule base in the database based on the structured change message, and locates the row where the changed data is located;

[0020] Incremental recalculation unit: Uses the processing rules to perform incremental recalculation on the master-slave object data based on the identifier of the master-slave object data change, the scope of the change, and the row where the changed data is located;

[0021] The state memory unit is used to save snapshots of key fields in each round of matching to achieve state memory capability across requests. Through the data structure of the last matching data and persistent storage in Redis, it provides the core state memory function for multi-round incremental rule matching.

[0022] Furthermore, the operation of the change detection unit is as follows: parse the action code of the master-slave object data, and determine the change type as addition, editing, or deletion based on the parsing result; when the change type is editing, trigger the combination key cascading detection filtering process, retain only the changed data rows and identify the aggregation rule type, and output the modified slave object index list; perform multiple types of security comparisons on the rows covered by the modified slave object index list based on field comparison to obtain the list of fields affected by the change range; perform change analysis on the affected field list, determine the scope of influence, and perform field weight sorting and field-rule dependency analysis to generate a data index-rule identifier; send the data index-rule identifier to the multidimensional rule engine for incremental calculation.

[0023] Furthermore, in the multi-dimensional rule engine filtering process: the built-in rule expression DSL parser of the multi-dimensional rule engine is used to convert the JSON-formatted business rules into an abstract syntax tree, which is then handed over to the extended expression engine for just-in-time compilation into bytecode; the initial compilation result is cached in the local high-speed cache, and subsequent hits are executed directly; after receiving the structured change message, batch filtering is first performed according to the macro group dimension composed of rule combination ID + main object. The batch filtering includes a two-stage pipeline: Stage 1 – Condition Matching: Boolean expressions are executed in parallel to match the data attributes of the main and slave objects to obtain a set of rule candidates; Stage 2 – Row-level Judgment: the execution conditions of the candidate rules are evaluated row by row. Each data row and rule is traversed through a double loop, the expression judgment is executed and the matching results are collected. Only the data indexes that are truly affected are marked, and it is determined whether aggregation calculation is required. If so, the batch aggregation value retrieval interface is called uniformly, and the array of the returned aggregation rule ID and value Map is injected into the execution context for subsequent formulas to directly retrieve values; a single call can complete the calculation of N aggregation indicators.

[0024] Furthermore, in the incremental recalculation unit: The input is a list of modified slave object indexes obtained based on change detection. The fields in the modified slave object index list are analyzed. If a field of the master object changes, all data indexes are directly included in the recalculation to avoid a full table scan. Based on the data index-rule identifier mapping, only rules related to the changed data rows are retained. If a row in a combined slave object changes, other rows in the same group are automatically added to the recalculation to avoid errors or omissions. If the user manually specifies a rule combination, its priority is set to the minimum integer value during the recalculation phase to ensure consistent results.

[0025] Furthermore, during recalculation, a rule conflict decision algorithm is used to provide a unique and predictable result when multiple executable rules are faced with the same data row. The rule conflict decision algorithm is as follows: the conflict set is stably sorted in descending order of priority; if there is any rule tuple with a user priority identifier equal to 1, the entire tuple is placed at the top, and other elements remain in their original order; if the head element still has the same priority and user priority identifier value, the one with the smallest creation time wins; a lock-free concurrency and consistency strategy is adopted to implement the following operations: the decision logic runs on a thread-local cached copy of the conflict set, without involving shared write operations; the result is written to the row-level decision tracking dictionary through copy-on-write to avoid lock contention, wherein the user priority identifier is 1 only when the user explicitly selects it, otherwise it is 0.

[0026] Furthermore, change detection is performed using sparse bitmap change location: snapshot fields are mapped to sparse bitmaps, and the set of changed rows is obtained by comparing with the current request bitmap. The operation is optimized based on master-slave object data scenarios: a multi-level dependency graph is constructed, such as master-slave object data combination, to realize that a single point change automatically affects other data points. When breadth-first traversal reaches the weight threshold, the radius of influence is pruned. After deleting a row or disabling a policy, the row or policy is blacklisted for a certain period of time, and subsequent requests skip it directly. For data index-rule identification, a bitmap dependency pruning algorithm is used for optimization: pre-compile field bitmaps: a 256-bit bitmap is generated when the rule is published to identify its field dependency set. During its runtime, only one calculation is needed to determine "potential hit". Using two-layer pruning, bitmap pruning can remove ≥50% of useless rules.

[0027] The present invention also proposes a computer-readable storage medium storing computer program code, which, when executed by a computer, performs any of the methods described above.

[0028] The technical advantages of this invention are as follows: This invention provides a multi-round incremental rule matching method, apparatus, and storage medium for master-slave object data. The method includes: a change detection step S101, which monitors the master-slave object data in the database, and when one of the master-slave object data changes, generates a structured change message, wherein the structured change message includes an identifier and a change range indicating the change in the master-slave object data; a multi-dimensional rule engine filtering step S102, which determines the processing rules for matching the changed data from the rule base in the database based on the structured change message, and locates the row where the changed data is located; an incremental recalculation step S103, which uses the processing rules to perform incremental recalculation on the master-slave object data based on the identifier, change range, and row where the changed data is located; and a state memory step S104, which saves a snapshot of the key field state of each round of matching to achieve cross-request state memory capability. Through the data structure of the last matched data and Redis persistent storage, it provides the core state memory function for multi-round incremental rule matching. The beneficial effects of this invention are as follows: Multi-round state memory processing: Based on the state memory mechanism of the last matched data, multi-round interaction across requests is realized, and each round can identify changed data and perform incremental recalculation; Master-slave object optimization: Specifically designed for master-slave object relationships, it supports conflict handling and user preference priority when multiple rules are matched concurrently through a dynamic priority adjustment algorithm; Incremental recalculation framework: Incremental calculation based on state memory avoids full recalculation and significantly improves computational efficiency. Attached Figure Description

[0029] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0030] Figure 1 This is a flowchart of a multi-round incremental rule matching method for master-slave object data based on state memory, according to an embodiment of the present invention.

[0031] Figure 2 This is a structural diagram of a multi-round incremental rule matching device for master-slave object data based on state memory, according to an embodiment of the present invention. Detailed Implementation

[0032] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0033] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0034] Figure 1 This invention illustrates a multi-round incremental rule matching method for master-slave object data based on state memory, the method comprising:

[0035] In the change detection step S101, the master-slave object data in the database is monitored. When one of the master-slave object data is changed, a structured change message is generated. The structured change message includes an identifier and a scope of change to indicate the change in the master-slave object data.

[0036] In the multi-dimensional rule engine filtering step S102, based on the structured change message, the processing rules for matching the changed data are determined from the rule base in the database, and the row where the changed data is located is located.

[0037] Incremental recalculation step S103: Using the processing rules, perform incremental recalculation on the master-slave object data based on the identifier of the master-slave object data change, the scope of the change, and the row where the changed data is located;

[0038] The state memory step S104 is used to save a snapshot of the key field state of each round of matching to achieve state memory capability across requests. Through the LastMatchData (last matching data) data structure and Redis persistent storage, it provides the core state memory function for multi-round incremental rule matching.

[0039] The state memory step S104 operation is as follows:

[0040] Status snapshot saving: After each round of rule matching is completed, a status snapshot of key fields is automatically saved; the processing flow is as follows:

[0041] a) Extract key fields from the main object (such as account_id (customer ID), total_amount (total), etc.);

[0042] b) Extract all key fields from the object (such as quantity, product_id, unit).

[0043] c) Construct a LastMatchData object containing the complete data state;

[0044] d) Use Redis caching to store the data, with the key format "p_lastMatchData:{tenantId(tenantID)}:{objectId(objectID)}", and an expiration time of 3 hours;

[0045] State snapshot retrieval: Before a new round of matching begins, retrieve the state snapshot of the last match from the distributed cache;

[0046] State comparison analysis: Change detection algorithm, the core implementation is as follows:

[0047] a) Snapshot data retrieval: Call getOldMatchData(last matched data) to retrieve the LastMatchData (last matched data) snapshot from Redis;

[0048] b) New row processing: When oldDetailDoc(last matched data from object - single row) = null, directly add it to modifiedDataIndexList(list of modified object indices);

[0049] c) Change row detection: Perform precise comparisons on key fields;

[0050] d) Change flag: When there is a field difference, add the dataIndex (index from object) to the modifiedDataIndexList (list of modified indexes from object) collection.

[0051] This invention addresses dynamic, multi-dimensional rule matching scenarios involving master-slave objects by employing a state memory mechanism for multi-round incremental calculations. It accurately detects and categorizes data changes. This invention optimizes the handling of complex multi-dimensional scenarios through state memory, multi-round matching using a multi-dimensional rule engine, and master-slave object processing. Firstly, it monitors master-slave object data in the database. When one of the master or slave object data changes, a structured change message is generated. This message includes an identifier indicating the change (e.g., identifier 1 indicates a change in the master object data, and 0 indicates a change in the slave object data) and the scope of the change. Based on this structured change message, processing rules for matching the changed data are determined from the rule base in the database, and the row containing the changed data is located. Multi-round state memory processing is then performed, using the processing rules to incrementally recalculate the master-slave object data based on the identifier, scope, and row of the changed data. Based on the LastMatchData (last matched data) state memory mechanism, multi-round interaction across requests is achieved. Each round identifies the changed data and performs incremental recalculation, enabling accurate detection and classification of data changes in the database—this is the core inventive concept of this invention.

[0052] In one embodiment, the change detection step S101 operates as follows: Parsing the action code of the master-slave object data, determining the change type as Add, Edit, or Delete based on the parsing result; when the change type is Edit, triggering a combo-filter to retain only the changed data rows and identify the aggregation rule type, outputting a modified data object list (modifiedDataIndexList); performing multiple types of security comparisons on the rows covered by modifiedDataIndexList based on field comparisons to obtain the changed fields (list of affected fields); performing change analysis on changedFields (list of affected fields), determining the scope of influence, and performing field weight sorting and field-rule dependency analysis to generate data index-rule identifiers {dataIndex→ruleIds}; sending {dataIndex→ruleIds} to the multidimensional rule engine for incremental calculation.

[0053] In this invention, when the change type is Edit, a Combo-Filter is triggered to process the cascading detection and filtering of the combination key. Only the changed data rows are retained, and the aggregation rule type is identified. Based on field comparison, multiple types of safe comparisons are performed on the rows covered by modifiedDataIndexList to obtain the change range changedFields. Change analysis is performed on the changedFields to determine the scope of influence and to perform field weight sorting and field-rule dependency analysis. Then, it is used for incremental calculation, thereby achieving accurate processing of changed data rows and avoiding the operation of processing all data using processing rules, thus improving system performance. This is one of the important inventive concepts of this invention.

[0054] In one embodiment, in the multidimensional rule engine filtering step S102: the business rules in JSON format are converted into an abstract syntax tree (AST) using the built-in rule expression DSL parser of the multidimensional rule engine, and then handed over to the extended expression engine for just-in-time compilation into bytecode; the initial compilation result is cached in the local cache, and subsequent hits are executed directly; after receiving the structured change message, batch filtering is first performed according to the macro group dimension composed of "rule combination ID + master object", and the batch filtering includes a two-stage pipeline: Stage 1 – Condition matching: Boolean expressions are executed in parallel to match the data attributes of master and slave objects to obtain rule candidates. Phase 2 – Row-level Decision: Evaluate the execution conditions of each candidate rule row by row. Iterate through each data row and rule using a double loop, execute expression judgment and collect matching results. Only mark the dataIndex (from object index) that is truly affected, and determine whether aggregation calculation is needed. If so, call the computeAggregateValues ​​(batch get aggregation values) interface and inject the returned aggregation rule ID → value Map (i.e., an array of aggregation rule ID and value Map) into the execution context for subsequent formulas to directly retrieve values. A single call can complete the calculation of N aggregation indicators, avoiding multiple rounds of I / O.

[0055] In this invention, batch filtering is first performed according to the macro group dimension composed of "rule combination ID + main object", and data processing is carried out in a two-level pipeline manner. Each data row and rule is traversed through a double loop, expression judgment is executed and matching results are collected. Only the dataIndex (from object index) that is actually affected is marked. If aggregation calculation is required, the computeAggregateValues ​​(batch get aggregation value) interface is called uniformly, and the returned aggregation rule ID → value Map is injected into the execution context for subsequent formulas to directly retrieve values. This improves the efficiency, accuracy and timeliness of data change processing, which is one of the important inventive concepts of this invention.

[0056] In one embodiment, in the incremental recalculation step S103: The modifiedDataIndexList (list of modified slave object indices) obtained based on change detection is input. The fields in the modifiedDataIndexList are analyzed. If a field of the master object changes, all dataIndex (slave object indices) are directly included in the recalculation to avoid a full table scan. Based on the {dataIndex→ruleIds} mapping, only rules related to the changed data rows are retained. If a row in a combined slave object changes, other rows in the same group are automatically added to the recalculation to avoid errors. If the user manually specifies a rule combination, its priority is set to Integer.MIN_VALUE (minimum integer value) during the recalculation stage to ensure consistent results.

[0057] In this invention, by analyzing the fields in modifiedDataIndexList (the list of modified slave object indexes), if the main object field changes, all dataIndex (slave object indexes) are directly included in the recalculation, avoiding a full table scan. Based on the {dataIndex→ruleIds} mapping, only rules related to the changed data rows are retained. If a row in a combined slave object changes, other rows in the same group are automatically added to the recalculation, avoiding errors and omissions. Production data practice shows that it can reduce the rule calculation workload by ≥50%. During row-level recalculation, the rule engine is called row by row, utilizing local compiled-bytecode and aggregate value caching, with single-row execution time below milliseconds. In the result merging operation, unchanged rows reuse the previous round's ExecutionData (data to be executed), while changed rows only replace the difference fields and write them back. CPU usage drops significantly at peak times. A key optimization is the blacklist caching: deleted rows are added to the blacklist, and subsequent requests skip them directly. This greatly improves the incremental data processing performance in the database, which is another important inventive concept of this invention.

[0058] In one embodiment, during recalculation, a rule conflict decision algorithm is used to provide a unique and predictable result when multiple executable rules are faced with the same data row. The rule conflict decision algorithm is as follows: the ConflictSet is stably sorted in descending order of priority; if there is any RuleTuple with userBoost equal to 1, the entire group is placed first, and other elements are kept in their original order; if the head element still has the same priority & userBoost value, the one with the smallest createTime wins; a lock-free concurrency and consistency strategy is adopted to implement the following operations: the decision logic runs on a thread-local cached copy of the ConflictSet, without involving shared write operations; the result is written to the row-level DecisionTrace Map via Copy-On-Write to avoid lock contention, wherein userBoost is only 1 when the user explicitly selects it, otherwise it is 0. This invention introduces ruleHash (rule ID + version number + policy fingerprint) as an idempotent key into RuleTuple, ensuring safe overwriting of repeated calculations and maintaining cross-node consistency: the decision output is serialized as...<dataIndex,ruleHash> The data is written to Redis; downstream consumers employ a last-write-wins strategy, combined with createTime to ensure weak consistency. These are the key inventive concepts of this invention.

[0059] In one embodiment, sparse bitmap change location is used for change detection: the snapshot field is mapped to a sparse bitmap (bit-vector), and the set of changed rows Δ-Index is obtained by comparing it with the current request bitmap O(Δ). The operation is optimized based on the master-slave object data scenario: a multi-level dependency graph such as master-slave object data combination is constructed to realize that a single point change automatically affects other data points. When the breadth-first traversal reaches the weight threshold, the radius of influence is pruned. After deleting a row or disabling a policy, the row or policy is blacklisted for a certain period of time, such as several hours. During this period, subsequent requests are directly skipped. For {dataIndex→ruleIds}, a bitmap dependency pruning algorithm is used for optimization: pre-compile field bitmap: a 256-bit bitmap is generated when the rule is published to identify its field dependency set. During its runtime, only one operation is needed to determine "potential hit". The use of two-layer pruning makes the bitmap pruning able to remove ≥50% of useless rules.

[0060] This invention provides a foundation for incremental computation based on state memory, utilizes a master-slave object optimization algorithm to reduce computational load, employs a lock-free conflict resolution mechanism to ensure the uniqueness and interpretability of results, and enhances the real-time performance of metric statistics through asynchronous aggregation, thereby supporting application requirements in high-concurrency, multi-dimensional rule-based scenarios. These are the key inventive concepts of this invention.

[0061] Figure 2 This invention illustrates a multi-round incremental rule matching device for master-slave object data based on state memory. The device includes:

[0062] The change detection unit 201 monitors the master-slave object data in the database. When one of the master-slave object data changes, it generates a structured change message, wherein the structured change message includes an identifier and the scope of the change indicating the change of the master-slave object data.

[0063] The multi-dimensional rule engine filtering unit 202 determines the processing rules for matching the changed data from the rule base in the database based on the structured change message, and locates the row where the changed data is located;

[0064] Incremental recalculation unit 203: Uses the processing rules to perform incremental recalculation on the master-slave object data based on the identifier of the master-slave object data change, the scope of the change, and the row where the changed data is located;

[0065] State memory unit 204 is used to save snapshots of key fields in each round of matching to achieve state memory capability across requests. Through the LastMatchData (last match data) data structure and Redis persistent storage, it provides core state memory functionality for multi-round incremental rule matching.

[0066] This invention addresses dynamic, multi-dimensional rule matching scenarios involving master-slave objects by employing a state memory mechanism for multi-round incremental calculations. It accurately detects and categorizes data changes. This invention optimizes the handling of complex multi-dimensional scenarios through state memory, multi-round matching using a multi-dimensional rule engine, and master-slave object processing. Firstly, it monitors master-slave object data in the database. When one of the master or slave object data changes, a structured change message is generated. This message includes an identifier indicating the change (e.g., identifier 1 indicates a change in the master object data, and 0 indicates a change in the slave object data) and the scope of the change. Based on this structured change message, processing rules for matching the changed data are determined from the rule base in the database, and the row containing the changed data is located. Multi-round state memory processing is then performed, using the processing rules to incrementally recalculate the master-slave object data based on the identifier, scope, and row of the changed data. Based on the LastMatchData (last matched data) state memory mechanism, multi-round interaction across requests is achieved. Each round identifies the changed data and performs incremental recalculation, enabling accurate detection and classification of data changes in the database—this is the core inventive concept of this invention.

[0067] In one embodiment, the operation of the change detection unit 201 is as follows: Parsing the actionCode of the master-slave object data, determining the change type as Add, Edit, or Delete based on the parsing result; when the change type is Edit, triggering a combo-filter to retain only the changed data rows and identify the aggregation rule type, outputting a modified data object list (modifiedDataIndexList); performing multiple types of security comparisons on the rows covered by modifiedDataIndexList based on field comparisons to obtain the changed Fields list; performing change analysis on changedFields list to determine the scope of influence and performing field weight sorting and field-rule dependency analysis to generate data index-rule identifiers {dataIndex→ruleIds}; and sending {dataIndex→ruleIds} to the multidimensional rule engine for incremental calculation.

[0068] In this invention, when the change type is Edit, a Combo-Filter is triggered to process the cascading detection and filtering of the combination key. Only the changed data rows are retained, and the aggregation rule type is identified. Based on field comparison, multiple types of safe comparisons are performed on the rows covered by modifiedDataIndexList to obtain the change range changedFields. Change analysis is performed on the changedFields to determine the scope of influence and to perform field weight sorting and field-rule dependency analysis. Then, it is used for incremental calculation, thereby achieving accurate processing of changed data rows and avoiding the operation of processing all data using processing rules, thus improving system performance. This is one of the important inventive concepts of this invention.

[0069] In one embodiment, in the multidimensional rule engine filtering step S102: the business rules in JSON form are converted into an abstract syntax tree (AST) using the built-in rule expression DSL parser of the multidimensional rule engine, and then handed over to the extended expression engine for just-in-time compilation into bytecode; the initial compilation result is cached in the local high-speed cache, and subsequent hits are executed directly; after receiving the structured change message, batch filtering is first performed according to the macro group dimension composed of "rule combination ID + master object". The batch filtering includes a two-stage pipeline: Stage 1 – Condition matching: Boolean expressions are executed in parallel to match the data attributes of master and slave objects to obtain a set of rule candidates; Stage 2 – Row-level judgment: the execution conditions of candidate rules are evaluated row by row. Each data row and rule is traversed through a double loop, the expression judgment is executed and the matching results are collected. Only the dataIndex (slave object index) that is truly affected is marked, and it is determined whether aggregation calculation is required. If so, the computeAggregateValues ​​(batch get aggregation value) interface is called uniformly, and the returned aggregation rule ID → value Map is injected into the execution context for subsequent formulas to directly retrieve values; a single call can complete the calculation of N aggregation indicators, avoiding multiple rounds of IO.

[0070] In this invention, batch filtering is first performed according to the macro group dimension composed of "rule combination ID + main object", and data processing is carried out in a two-level pipeline manner. Each data row and rule is traversed through a double loop, expression judgment is executed and matching results are collected. Only the dataIndex (from object index) that is actually affected is marked. If aggregation calculation is required, the computeAggregateValues ​​(batch get aggregation value) interface is called uniformly, and the returned aggregation rule ID → value Map is injected into the execution context for subsequent formulas to directly retrieve values. This improves the efficiency, accuracy and timeliness of data change processing, which is one of the important inventive concepts of this invention.

[0071] In one embodiment, in the incremental recalculation unit 203: The input is a modifiedDataIndexList (a list of modified slave object indices) obtained based on change detection. The fields in the modifiedDataIndexList are analyzed. If a field of the master object changes, all dataIndex (slave object indices) are directly included in the recalculation to avoid a full table scan. Based on the {dataIndex→ruleIds} mapping, only rules related to the changed data rows are retained. If a row in a combined slave object changes, other rows in the same group are automatically added to the recalculation to avoid errors. If the user manually specifies a rule combination, its priority is set to Integer.MIN_VALUE (minimum integer value) during the recalculation phase to ensure consistent results.

[0072] In this invention, by analyzing the fields in modifiedDataIndexList (the list of modified slave object indexes), if the main object field changes, all dataIndex (slave object indexes) are directly included in the recalculation, avoiding a full table scan. Based on the {dataIndex→ruleIds} mapping, only rules related to the changed data rows are retained. If a row in a combined slave object changes, other rows in the same group are automatically added to the recalculation, avoiding errors and omissions. Production data practice shows that it can reduce the rule calculation workload by ≥50%. During row-level recalculation, the rule engine is called row by row, utilizing local compiled-bytecode and aggregate value caching, with single-row execution time below milliseconds. In the result merging operation, unchanged rows reuse the previous round's ExecutionData (data to be executed), while changed rows only replace the difference fields and write them back. CPU usage drops significantly at peak times. A key optimization is the blacklist caching: deleted rows are added to the blacklist, and subsequent requests skip them directly. This greatly improves the incremental data processing performance in the database, which is another important inventive concept of this invention.

[0073] In one embodiment, during recalculation, a rule conflict decision algorithm is used to provide a unique and predictable result when multiple executable rules are faced with the same data row. The rule conflict decision algorithm is as follows: the ConflictSet is stably sorted in descending order of priority; if there is any RuleTuple with userBoost equal to 1, the entire group is placed first, and other elements are kept in their original order; if the head element still has the same priority & userBoost value, the one with the smallest createTime wins; a lock-free concurrency and consistency strategy is adopted to implement the following operations: the decision logic runs on a thread-local cached copy of the ConflictSet, without involving shared write operations; the result is written to the row-level DecisionTrace Map via Copy-On-Write to avoid lock contention, wherein userBoost is only 1 when the user explicitly selects it, otherwise it is 0. This invention introduces ruleHash (rule ID + version number + policy fingerprint) as an idempotent key into RuleTuple, ensuring safe overwriting of repeated calculations and maintaining cross-node consistency: the decision output is serialized as...<dataIndex,ruleHash> The data is written to Redis; downstream consumers employ a last-write-wins strategy, combined with createTime to ensure weak consistency. These are the key inventive concepts of this invention.

[0074] In one embodiment, sparse bitmap change location is used for change detection: the snapshot field is mapped to a sparse bitmap (bit-vector), and the set of changed rows Δ-Index is obtained by comparing it with the current request bitmap O(Δ). The operation is optimized based on the master-slave object data scenario: a multi-level dependency graph such as master-slave object data combination is constructed to realize that a single point change automatically affects other data points. When the breadth-first traversal reaches the weight threshold, the radius of influence is pruned. After deleting a row or disabling a policy, the row or policy is blacklisted for a certain period of time, during which subsequent requests are directly skipped. For {dataIndex→ruleIds}, a bitmap dependency pruning algorithm is used for optimization: pre-compile field bitmap: a 256-bit bitmap is generated when the rule is published to identify its field dependency set. During its runtime, only one operation is needed to determine "potential hit". The use of two-layer pruning makes the bitmap pruning able to remove ≥50% of useless rules.

[0075] This invention provides a foundation for incremental computation based on state memory, utilizes a master-slave object optimization algorithm to reduce computational load, employs a lock-free conflict resolution mechanism to ensure the uniqueness and interpretability of results, and enhances the real-time performance of metric statistics through asynchronous aggregation, thereby supporting application requirements in high-concurrency, multi-dimensional rule-based scenarios. These are the key inventive concepts of this invention.

[0076] The terminology used in this invention is as follows:

[0077]

[0078] One embodiment of the present invention provides a computer storage medium storing a computer program. When the computer program on the computer storage medium is executed by a processor, the above-described method is implemented. The computer storage medium may be a hard disk, DVD, CD, flash memory, or other storage device.

[0079] For ease of description, the above-described apparatus is divided into various functional units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0080] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the apparatus described in various embodiments or some parts of the embodiments of this application.

[0081] Finally, it should be noted that the above embodiments are for illustration only and not for limiting the technical solutions of the present invention. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention without departing from the spirit and scope of the present invention. Any modifications or partial substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A multi-round incremental rule matching method for master-slave object data, characterized in that, The method includes: The change detection step monitors the master-slave object data in the database. When one of the master-slave object data changes, a structured change message is generated. The structured change message includes an identifier and the scope of the change that indicate the change in the master-slave object data. The multi-dimensional rule engine filtering step determines the processing rules for matching the changed data from the rule base in the database based on the structured change message, and locates the row where the changed data is located; Incremental recalculation step: Using the processing rules, perform incremental recalculation on the master-slave object data based on the identifier of the master-slave object data change, the scope of the change, and the row where the changed data is located; The state memory step is used to save a snapshot of the key fields of each round of matching to achieve state memory capability across requests. Through the data structure of the last matching data and Redis persistent storage, it provides the core state memory function for multi-round incremental rule matching.

2. The method according to claim 1, characterized in that, The change detection step is as follows: the action code of the master-slave object data is parsed, and the change type is determined to be addition, editing or deletion based on the parsing result; when the change type is editing, the combination key cascade detection and filtering process is triggered, only the changed data rows are retained and the aggregation rule type is identified, and the modified slave object index list is output. Based on field comparison, perform various types of safe comparisons on the rows covered by the modified object index list to obtain a list of fields whose scope of change is affected; A change analysis is performed on the list of affected fields to determine the scope of the impact, and field weight sorting and field-rule dependency analysis are conducted to generate data index-rule identifiers; The data index-rule identifier is sent to the multidimensional rule engine for incremental calculation.

3. The method according to claim 2, characterized in that, In the multi-dimensional rule engine filtering: the built-in rule expression DSL parser of the multi-dimensional rule engine is used to convert the JSON-formatted business rules into an abstract syntax tree, which is then handed over to the extended expression engine for just-in-time compilation into bytecode; the initial compilation result is cached in the local high-speed cache, and subsequent hits are executed directly; after receiving the structured change message, batch filtering is first performed according to the macro group dimension composed of rule combination ID + main object. The batch filtering includes a two-stage pipeline: Stage 1 – Condition matching: Boolean expressions are executed in parallel to match the data attributes of the main and slave objects to obtain a set of rule candidates; Stage 2 – Row-level judgment: the execution conditions of the candidate rules are evaluated row by row. Each data row and rule is traversed through a double loop, the expression judgment is executed and the matching results are collected. Only the data indexes that are truly affected are marked, and it is determined whether aggregation calculation is required. If so, the batch aggregation value acquisition interface is called uniformly, and the array of the returned aggregation rule ID and value Map is injected into the execution context for subsequent formulas to directly retrieve values. A single call can complete the calculation of N aggregate metrics.

4. The method according to claim 3, characterized in that, In the incremental recalculation step: The input is a list of modified slave object indexes obtained based on change detection. The fields in the modified slave object index list are analyzed. If a field of the master object changes, all data indexes are directly included in the recalculation to avoid a full table scan. Based on the data index-rule identifier mapping, only rules related to the changed data rows are retained. If a row in a combined slave object changes, other rows in the same group are automatically added to the recalculation to avoid errors or omissions. If the user manually specifies a rule combination, its priority is set to the minimum integer value during the recalculation stage to ensure consistent results.

5. The method according to claim 4, characterized in that, During recalculation, a rule conflict decision algorithm is used to provide a unique and predictable result when multiple executable rules are faced with the same data row. The rule conflict decision algorithm is as follows: the conflict set is stably sorted in descending order of priority; if there is a rule tuple with any user priority identifier equal to 1, the entire tuple is placed at the top, and other elements are kept in their original order; if the head element still has the same priority and user priority identifier value, the one with the smallest creation time wins. The following operations are implemented using a lock-free concurrency and consistency strategy: the decision logic runs on a conflict set copy of the thread-local cache, without involving shared write operations; the results are written to the row-level decision trace dictionary via copy-on-write to avoid lock contention. The user priority flag is 1 only when the user explicitly selects it, and 0 otherwise.

6. The method according to claim 5, characterized in that, Change detection is performed using sparse bitmap change location: snapshot fields are mapped to sparse bitmaps, and the set of changed rows is obtained by comparing with the current request bitmap. The operation is optimized based on the master-slave object data scenario: a multi-level dependency graph such as master-slave object data combination is constructed to realize that a single point change automatically affects other data points. When breadth-first traversal reaches the weight threshold, the radius of influence is pruned. After deleting a row or disabling a policy, the row or policy is blacklisted for a certain period of time, and subsequent requests skip it directly. For data index-rule identification, a bitmap dependency pruning algorithm is used for optimization: pre-compile field bitmaps, generate a 256-bit bitmap when the rule is published, and identify its field dependency set.

7. A multi-round incremental rule matching device for master-slave object data, characterized in that, The device includes: The change detection unit monitors the master-slave object data in the database. When one of the master-slave object data changes, it generates a structured change message, wherein the structured change message includes an identifier and the scope of the change indicating the change in the master-slave object data. The multi-dimensional rule engine filtering unit determines the processing rules for matching the changed data from the rule base in the database based on the structured change message, and locates the row where the changed data is located; Incremental recalculation unit: Uses the processing rules to perform incremental recalculation on the master-slave object data based on the identifier of the master-slave object data change, the scope of the change, and the row where the changed data is located; The state memory unit is used to save snapshots of key fields in each round of matching to achieve state memory capability across requests. Through the data structure of the last matching data and persistent storage in Redis, it provides the core state memory function for multi-round incremental rule matching.

8. The apparatus according to claim 7, characterized in that, The operation of the change detection unit is as follows: parse the action code of the master-slave object data, and determine the change type as addition, editing or deletion based on the parsing result; when the change type is editing, trigger the combination key cascade detection and filtering process, retain only the changed data rows and identify the aggregation rule type, and output the modified slave object index list; Based on field comparison, perform various types of safe comparisons on the rows covered by the modified object index list to obtain a list of fields whose scope of change is affected; A change analysis is performed on the list of affected fields to determine the scope of the impact, and field weight sorting and field-rule dependency analysis are conducted to generate data index-rule identifiers; The data index-rule identifier is sent to the multidimensional rule engine for incremental calculation.

9. The apparatus according to claim 8, characterized in that, In the multi-dimensional rule engine filtering: the built-in rule expression DSL parser of the multi-dimensional rule engine is used to convert the JSON-formatted business rules into an abstract syntax tree, which is then handed over to the extended expression engine for just-in-time compilation into bytecode; the initial compilation result is cached in the local high-speed cache, and subsequent hits are executed directly; after receiving the structured change message, batch filtering is first performed according to the macro group dimension composed of rule combination ID + main object. The batch filtering includes a two-stage pipeline: Stage 1 – Condition matching: Boolean expressions are executed in parallel to match the data attributes of the main and slave objects to obtain a set of rule candidates; Stage 2 – Row-level judgment: the execution conditions of the candidate rules are evaluated row by row. Each data row and rule is traversed through a double loop, the expression judgment is executed and the matching results are collected. Only the data indexes that are truly affected are marked, and it is determined whether aggregation calculation is required. If so, the batch aggregation value acquisition interface is called uniformly, and the array of the returned aggregation rule ID and value Map is injected into the execution context for subsequent formulas to directly retrieve values. A single call can complete the calculation of N aggregate metrics.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-6.

Images