A real-time rule dynamic adjustment method and system of an integral calculation engine

Abstract

The application relates to the technical field of integral calculation, and discloses a real-time rule dynamic adjustment method and system of an integral calculation engine. The method comprises the following steps: obtaining a promotion activity trigger signal from a business scene through a preset event listening module; obtaining an applicable rule set by matching a trigger condition of the trigger signal with a preset threshold value; extracting configuration parameters of the rule set from a rule library, and generating a rule switching instruction after verification; distributing the instruction to the integral calculation engine by a rule scheduling module, and updating integral calculation logic; obtaining user requests according to a preset proportion by a gray release mechanism, applying new logic, comparing the new logic with expected results, and obtaining verification results; and if the data consistency of the verification results meets the standard, deploying the new logic to the integral calculation engine by the rule scheduling module. The method realizes real-time dynamic adjustment of integral rules, guarantees system stability and business continuity during rule switching, and effectively improves the accuracy and response efficiency of integral calculation in a business scene.

Description

Technical Field

[0001] This invention relates to the field of integral calculation technology, and in particular to a method and system for real-time dynamic adjustment of rules for an integral calculation engine. Background Technology

[0002] With the large-scale development of modern business systems and the diversification and upgrading of user needs, points calculation engines have become a core component connecting business strategies and user experience. By calculating the points rewards corresponding to user consumption, interaction, and task completion in real time, it directly affects user stickiness, business flexibility, and corporate revenue conversion. Especially in key scenarios such as major promotional events and holiday marketing, efficient points calculation and rule adjustment capabilities are crucial for enterprises to quickly respond to market demands and maintain user trust. Developing points calculation engines with real-time dynamic rule adjustment capabilities has become an important topic for industry optimization.

[0003] Currently, most mainstream points calculation solutions rely on static rule configuration and centralized processing architecture: the system pre-enters fixed points rules, receives business data through a central server and performs standardized calculations; some solutions only add rule backup storage to ensure basic reliability, but core rule adjustments still require manual intervention - when the business needs to switch rules, technical personnel need to manually modify the configuration parameters, and in complex scenarios, it may even be necessary to shut down the system to update the rule scripts, and resume calculation after the central server reloads the rules.

[0004] However, this type of solution has significant drawbacks: First, it lacks flexibility in rule adjustment, with manual intervention and downtime updates leading to long response cycles, making it unable to adapt to rapidly changing market demands. Second, it lacks stability in high-concurrency scenarios, with rule switching during peak sales periods easily causing calculation errors, delayed payments, or even business interruptions. Third, it lacks event triggering and risk mitigation mechanisms, failing to automatically switch rules based on preset business conditions and lacking effective version management and canary release mechanisms, making it difficult to quickly roll back after rule switching failures, easily leading to data inconsistencies. Therefore, how to design an event-triggered rule contingency management system that balances real-time rule adjustment with business and system stability has become the core challenge for the development of points calculation engines. Summary of the Invention

[0005] This invention provides a method and system for real-time dynamic adjustment of rules in an points calculation engine, so as to realize real-time dynamic adjustment of points rules, ensure system stability and business continuity when switching rules, and effectively improve the accuracy and response efficiency of points calculation in commercial scenarios.

[0006] Firstly, in order to solve the above-mentioned technical problems, the present invention provides a method for real-time dynamic adjustment of rules in an integral calculation engine, comprising:

[0007] The promotional activity trigger signal is obtained from the business scenario through a pre-established event listening module;

[0008] The applicable rule set is obtained by matching the triggering conditions corresponding to the triggering signal with the preset triggering threshold.

[0009] According to the applicable rule set, rule configuration parameters are extracted from the preset rule base, and a rule switching instruction is obtained after parameter verification;

[0010] The rule switching instruction is distributed to the integral calculation engine through the rule scheduling module to obtain the updated integral calculation logic;

[0011] User requests are obtained in a preset proportion through a canary release mechanism. The updated points calculation logic is applied to the user requests, and the calculation results are compared with the expected results to obtain the verification results.

[0012] When the data consistency in the verification result meets the preset verification standard, the updated integral calculation logic is fully deployed to the integral calculation engine through the rule scheduling module.

[0013] The trigger signal carries trigger conditions, which include at least time parameters, user behavior parameters, and transaction parameters in the business scenario. The applicable rule set is a points calculation rule that matches the trigger conditions. The rule configuration parameters include at least points calculation coefficients, rule effective range, and conflict handling strategies.

[0014] In one optional implementation, the step of matching the triggering condition corresponding to the triggering signal with a preset triggering threshold to obtain an applicable rule set includes:

[0015] The triggering conditions corresponding to the triggering signal are analyzed to extract time parameters, user behavior parameters, and transaction parameters. These parameters are then aggregated in real time and processed in a structured manner to obtain structured condition features.

[0016] By using multi-dimensional matching, the structured condition features are compared with preset trigger thresholds to obtain the comparison results;

[0017] Based on the comparison results, integral calculation rules that have reached the corresponding preset trigger thresholds in each dimension are selected from the preset rule base to form a candidate rule set;

[0018] The candidate rule set is used to identify conflicts and eliminate conflicting rules through a rule priority mechanism.

[0019] The candidate rule set after conflict identification is adapted and adjusted based on the real-time characteristics of the current business scenario to obtain the applicable rule set;

[0020] The trigger thresholds include time period range thresholds, interaction frequency thresholds, and transaction amount thresholds. The adaptation adjustment includes the effective scope, trigger frequency, and calculation coefficient of the points calculation rules.

[0021] In one optional implementation, the step of extracting rule configuration parameters from a preset rule base according to the applicable rule set, and obtaining a rule switching instruction after parameter verification, includes:

[0022] The system queries the rule base for applicable rule sets corresponding to the current business scenario, and removes rules that do not match the current business scenario or have expired by using preset filtering conditions, thereby obtaining an optimized rule set.

[0023] Based on the optimized rule set, the rule configuration parameters supporting the integral calculation are extracted layer by layer through the preset data extraction logic;

[0024] The extracted rule configuration parameters are passed to the parameter validation mechanism, which performs parameter format validation according to the preset validation dimensions and outputs the validation results.

[0025] When the verification result is passed, the parameter matching logic is activated to match the appropriate parameter items according to the current business scenario requirements and generate the matched parameter set.

[0026] Based on the matched parameter set, the instruction generation mechanism is invoked, and the parameter information is integrated according to the preset instruction format to obtain the rule switching instruction.

[0027] In one optional implementation, the step of distributing the rule switching instruction to the integration calculation engine through the rule scheduling module to obtain the updated integration calculation logic includes:

[0028] The rule switching instructions are format-validated and content-decomposed to output standardized instruction data.

[0029] The rule scheduling module extracts the rule set identifier from the standardized instruction data and queries the preset rule base for the matching rule set version.

[0030] Based on the rule set version, extract rule set data from the rule base and generate a rule execution sequence;

[0031] The rule execution sequence is parsed and loaded by the integral calculation engine, and the integral calculation logic is updated.

[0032] In one optional implementation, the step of obtaining user requests at a preset ratio through a canary release mechanism, applying the updated points calculation logic to the user requests, and comparing the calculation results with the expected results to obtain verification results includes:

[0033] User requests are distributed from the business request queue according to a preset ratio using a canary release mechanism.

[0034] The user requests are preprocessed by the data acquisition module to output a standardized user request dataset;

[0035] Based on the user request dataset, the updated points calculation logic is applied to perform calculations and generate the calculation results.

[0036] The calculation results are compared with the expected results, and the difference analysis is performed simultaneously using the deviation calculation method, and the deviation analysis results are output.

[0037] Based on the deviation analysis results, deviation verification is performed to generate the verification results.

[0038] In one optional implementation, comparing the calculation result with the expected result, simultaneously performing a difference analysis using a deviation calculation method, and outputting the deviation analysis result includes:

[0039] Retrieve the expected result corresponding to the current user request from the preset result repository; wherein, the expected result is a set of historical valid score calculation results that match the current business scenario, and includes score value, rule trigger identifier and calculation time information;

[0040] The calculation results are associated with the expected results one by one according to the user identifier and business scenario dimension, and the consistency of the rule trigger identifier is checked to remove invalid comparison samples caused by rule mismatch.

[0041] For valid comparison samples with consistent rule triggering identifiers, the deviation calculation method is used to determine the integral value deviation between the calculated result and the expected result, and the difference between the calculation time of the calculated result and the expected time is analyzed.

[0042] Based on the deviation of the integral value and the calculation time, a deviation analysis result containing the deviation type, deviation degree and corresponding sample information is generated.

[0043] In one optional implementation, the step of deploying the updated points calculation logic to the points calculation engine through the rule scheduling module includes:

[0044] Deployment instructions are generated through the rule scheduling module;

[0045] According to the deployment instructions, the updated points calculation logic is obtained and its integrity is verified. The points calculation logic that passes the verification is used as the logic version to be deployed.

[0046] The rule scheduling module transmits the logic version to be deployed to the points calculation engine to complete the full deployment.

[0047] In one alternative implementation, after deploying the updated integration calculation logic to the integration calculation engine, the method further includes:

[0048] The operation log is obtained from the integral calculation engine, and the abnormal state is analyzed using a preset anomaly detection algorithm to obtain the abnormal state analysis results.

[0049] When the abnormal state analysis result indicates that an anomaly exists, the integral calculation logic will be restored to the previous version of the rule configuration.

[0050] User points data are obtained from the restored points calculation engine, and user experience optimization parameters are obtained after cluster analysis.

[0051] Based on the mapping relationship between the user experience optimization parameters and the rule configuration, the corresponding rule parameters are adjusted in the rule base, and the rule base is updated.

[0052] In one optional implementation, the step of obtaining user points data from the recovered points calculation engine, and then performing cluster analysis to obtain user experience optimization parameters includes:

[0053] Retrieve user points data from the restored points calculation engine;

[0054] The user points data is preprocessed by classification, and divided into three data subsets according to the source of points: transaction type, interaction type, and task type. Abnormal and disputed records are removed from each data subset.

[0055] Cluster analysis was used to perform cluster analysis on each data subset to identify common characteristics of users within the same data subset;

[0056] The common problems corresponding to the common features are transformed into quantified user experience optimization parameters;

[0057] The user points data includes the channels through which user points are acquired, the time it takes for points to be credited, the conversion rate of points usage, and records of objections to points calculation. The user experience optimization parameters include the target value for the timeliness of points crediting, the control threshold for the objection rate of points calculation, and the adjustment range of the points calculation coefficient for the corresponding channel.

[0058] Secondly, the present invention also provides a real-time rule dynamic adjustment system for an integral calculation engine, comprising:

[0059] Signal acquisition module: Acquires promotional activity trigger signals from business scenarios through a pre-established event listening module;

[0060] Matching module: Matches the triggering signal with the triggering condition and the preset triggering threshold to obtain an applicable rule set;

[0061] Command output module: Based on the applicable rule set, extracts rule configuration parameters from the preset rule base, and obtains the rule switching command after parameter verification;

[0062] Update module: The rule switching instruction is distributed to the points calculation engine through the rule scheduling module to obtain the updated points calculation logic;

[0063] Verification module: It acquires user requests at a preset ratio through a canary release mechanism, applies the updated points calculation logic to the user requests, and compares the calculation results with the expected results to obtain the verification results;

[0064] Deployment module: When the data consistency in the verification results meets the preset verification criteria, the updated points calculation logic is fully deployed to the points calculation engine through the rule scheduling module;

[0065] The trigger signal carries trigger conditions, which include at least time parameters, user behavior parameters, and transaction parameters in the business scenario. The applicable rule set is a points calculation rule that matches the trigger conditions. The rule configuration parameters include at least points calculation coefficients, rule effective range, and conflict handling strategies.

[0066] Compared with the prior art, the present invention has the following beneficial effects:

[0067] (1) The applicable rule set is obtained by matching the triggering conditions and preset triggering thresholds corresponding to the triggering signals. Through multi-dimensional condition comparison and threshold verification mechanism, the accuracy of rule selection is achieved. This process combines the real-time characteristics of business scenarios to perform structured parsing of triggering conditions, ensuring that the selected rule set is highly compatible with the current promotional activities, user behavior and other scenario characteristics, avoiding the deviation in score calculation caused by rule mismatch, and improving the scenario fit of rule application.

[0068] (2) The configuration parameters are extracted from the preset rule base according to the applicable rule set and verified to obtain the rule switching instruction. The validity of the rule parameters is ensured through a dual verification mechanism of parameter format compliance and business adaptability. Invalid or conflicting parameters are removed during the verification process to ensure that the generated rule switching instruction conforms to the operation specifications of the points calculation engine, reducing engine operation failures caused by abnormal parameters and enhancing the reliability of rule switching.

[0069] (3) The rule switching instructions are distributed to the points calculation engine through the rule scheduling module to obtain the updated points calculation logic. With the help of standardized instruction parsing and efficient distribution mechanism, the real-time nature of rule switching is achieved. The scheduling module unifies the format and prioritizes the instructions to ensure that the points calculation engine can quickly load new rules, shorten the response cycle of rule updates, and meet the timeliness requirements of dynamic rule adjustment in commercial scenarios.

[0070] (4) User requests were obtained and calculation results were verified at a preset ratio through a canary release mechanism. A small-scale trial and error and result comparison strategy was adopted to reduce the risk of full deployment of the rules. During the canary release process, the deviation analysis between the calculation results and the expected results was used to discover potential problems of the new rules in advance, avoid the impact of large-scale rule errors on user experience, and balance rule innovation and system stability.

[0071] (5) When the abnormal status analysis result indicates the existence of an anomaly, the points calculation logic is restored to the previous version of the rule configuration, and a fault fallback capability is built through the version backtracking mechanism. The recovery process quickly calls the historical stable version of the rules to ensure that the points calculation business is not interrupted, which solves the problem of business stagnation after the rule switching failure in the traditional system and ensures business continuity.

[0072] (6) User points data are obtained from the restored points calculation engine and user experience optimization parameters are obtained through cluster analysis. By classifying user behavior features and mining common problems, the optimization direction of the points rules is accurately located. Cluster analysis focuses on core experience dimensions such as points acquisition efficiency and result accuracy, providing data-driven decision-making basis for rule adjustment and improving the pertinence of rule optimization. Attached Figure Description

[0073] Figure 1 This is a flowchart illustrating a real-time rule dynamic adjustment method for an integral calculation engine provided in an embodiment of the present invention.

[0074] Figure 2 This is a schematic diagram of the structure of a real-time rule dynamic adjustment system for an integral calculation engine provided in an embodiment of the present invention. Detailed Implementation

[0075] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0076] Reference Figure 1 This invention provides a method for real-time dynamic adjustment of rules in an integral calculation engine, comprising the following steps:

[0077] S11, obtains promotional activity trigger signals from business scenarios through a pre-established event listening module;

[0078] S12, Match the triggering condition and preset triggering threshold corresponding to the triggering signal to obtain an applicable rule set;

[0079] S13, Based on the applicable rule set, extract rule configuration parameters from the preset rule base, and obtain a rule switching instruction after parameter verification;

[0080] S14, The rule switching instruction is distributed to the integral calculation engine through the rule scheduling module to obtain the updated integral calculation logic;

[0081] S15, User requests are obtained according to a preset ratio through a gray-scale release mechanism, the updated points calculation logic is applied to the user requests, and the calculation results are compared with the expected results to obtain the verification results;

[0082] S16, when the data consistency in the verification result meets the preset verification standard, the updated integral calculation logic is fully deployed to the integral calculation engine through the rule scheduling module.

[0083] In step S11, a pre-established event listening module retrieves promotional activity trigger signals from the business scenario. This embodiment uses an e-commerce platform's "Member Day Exclusive Discount" activity as a scenario to illustrate the implementation process of trigger signal retrieval and condition matching. The event listening module captures user behavior data in real time based on Kafka, and rule matching relies on the PrestoSQL engine and the Drools rule engine, with the rule base stored in Redis.

[0084] User U002 browsed member-exclusive product C 12 times and added it to the shopping cart 3 times between 14:00 and 15:00 on August 15, 2024, ultimately purchasing one item for a total of 450 yuan. The event monitoring module aggregated the data for this period and extracted the triggering conditions: the time parameter was "2024-08-15 14:00-15:00" (falling within the member-exclusive activity period); the user behavior parameters were "browsed product C 12 times and added it to the cart 3 times"; and the transaction parameters were "spent 450 yuan and product type was member-exclusive".

[0085] The preset promotional rule is "a 10% discount is triggered if a member browses products ≥ 10 times and spends ≥ 400 yuan within 1 hour". The system matches this using an SQL query, and the query results show that U002's 12 browsing times and 450 yuan spending both meet the threshold, thus triggering the signal generation.

[0086] The rule base stores two rules: R003 for "10% off member product C" and R004 for "80 RMB off member product D for purchases over 500 RMB". By matching user behavior data using the Drools rule engine, it was found that U002's browsing and purchasing behavior both pointed to product C. Therefore, R003 was determined to be the applicable rule, generating the rule set {R003}, and the 10% discount information was pushed to U002's member center page in real time. The entire process forms a closed loop through real-time data aggregation, condition validation, and rule matching, ensuring the accurate triggering of promotional rules.

[0087] In step S12, the applicable rule set is obtained by matching the triggering conditions and preset triggering thresholds corresponding to the triggering signal.

[0088] In one implementation, taking the aforementioned member day activity scenario of user U002, this embodiment details the process of matching triggering conditions with preset thresholds and generating applicable rule sets. First, the system parses U002's trigger signal: the time parameter is extracted as "2024-08-15 14:00-15:00", which is confirmed to fall within the member day activity period (August 15, 10:00-20:00) after real-time aggregation; the user behavior parameter is extracted as "browsed member product C 12 times, added to cart 3 times", which is structured as "valid browsing 10 times, added to cart 2 times" after deduplication through a 5-minute sliding window; the transaction parameter is extracted as "consumption amount 450 yuan, product type = member exclusive", which is then validated to form structured conditional features.

[0089] Subsequently, multi-dimensional matching was performed: the time period threshold was preset to "August 15th 10:00-20:00", and the comparison result was a match; in the interaction frequency threshold, "member product browsing ≥ 10 times", U002's 10 valid browsing times met the condition; the transaction amount threshold "consumption ≥ 400 yuan", and the 450 yuan consumption also met the standard. The results of the three-dimensional comparison were all "compliant".

[0090] Based on the comparison results, candidate rule sets were selected from the preset Redis rule base: rule R003 ("Member discount of 10% on C-grade products, points calculation coefficient 1.2, priority 2") and rule R005 ("Members receive an extra 50 points for spending over 400 RMB on a single day, priority 1"). Both rules met all trigger thresholds. Conflicts were identified using the priority mechanism of the Drools rule engine. Since R005 has a higher priority than R003 and the two point rules can be superimposed (the rule base is marked "superposition allowed in the same scenario"), both rules were retained.

[0091] Based on real-time business characteristics (only 20 units of product C remain in stock on the member's day, requiring restrictions on excessive triggering), adjustments were made: the scope of R003 was narrowed from "all members" to "silver and above members," and the trigger frequency was changed from "unlimited" to "once per user per day"; the points calculation coefficient for R005 was increased from "base value 50" to "60" (due to sufficient points budget on the platform that day). The final applicable rule set is {R005 (priority execution), R003 (supplementary execution)}, ensuring that points calculation both meets the triggering conditions and adapts to real-time business needs.

[0092] In step S13, rule configuration parameters are extracted from the preset rule base according to the applicable rule set, and a rule switching instruction is obtained after parameter verification.

[0093] In one implementation, taking the applicable rule set {R005, R003} generated in the above-mentioned Member Day activity scenario, this embodiment specifically describes the process of extracting rule configuration parameters and generating rule switching instructions. First, the system queries the rule set corresponding to the "Member Day - Product C" business scenario from the Redis rule library, and filters it through preset filtering conditions (rule status is "effective" and the applicable category includes "Product C"): the expired rule R006 (valid until 2024-08-14) and the rule R007 whose applicable category is "non-member product" are removed, and the optimized rule set is still {R005, R003}.

[0094] Next, the optimized rule set is analyzed through data extraction logic: the parameters extracted for R005 ("50 extra points for spending over 400 yuan on member days") include "threshold amount of 400 yuan, extra points of 60 (adjusted), applicable user level of silver and above"; the parameters extracted for R003 ("9% discount on C-grade products for members") include "discount rate of 0.9, points calculation coefficient of 1.2, and a daily trigger limit of 1 time". All parameters are stored in a hierarchical structure of "basic parameters - calculation parameters - restriction parameters".

[0095] Subsequently, the parameter validation mechanism validated the parameters from two dimensions: format compliance (numerical parameters are positive, date parameters conform to ISO format) and business adaptability (the points coefficient of 1.2 is within the preset range of 0.5-2.0, and the discount rate of 0.9 is not lower than the minimum threshold of 0.8). The results were all "passed". Based on the current business scenario requirements (product C has tight inventory), the parameter matching logic further filtered out the suitable parameter items: R005 retained "60 extra points, threshold of 400 yuan", and R003 retained "discount rate of 0.9, trigger limit of 1 time", forming the matched parameter set.

[0096] Finally, the command generation mechanism is invoked to integrate parameter information according to a preset JSON format and generate a rule switching command:

[0097] The instruction generation process is completed by sending the instruction to the points calculation engine via a message queue. The instruction is generated using the following methods: {"instructionId":"INS20240815U002","executeOrder":[1,2],"rules":[{"ruleId":"R005","params":{"threshold":400,"extraPoints":60}},{"ruleId":"R003","params":{"discount":0.9,"dailyLimit":1}}]}.

[0098] In step S14, the rule switching instruction is distributed to the integral calculation engine through the rule scheduling module to obtain the updated integral calculation logic.

[0099] In one implementation, following the generated rule switching instruction, this embodiment details the process by which the rule scheduling module distributes the instruction to the points calculation engine and updates the logic. First, the system performs format validation on the instruction {"instructionId":"INS20240815U002",...}, checking whether it contains required fields such as "instructionId", "executeOrder", and "rules" using a JSONSchema validation tool, confirming that the parameter types match (e.g., "discount" is numeric and "dailyLimit" is integer). Simultaneously, the content is decomposed into independent rule units: R005 (execution order 1) and R003 (execution order 2) output standardized instruction data. The rule scheduling module extracts the rule set identifiers "R005_v2.1" and "R003_v1.3" from the standardized data. Using the Redis query tool, it calls HGET "rule_versions" "R005|R003" to obtain the matching rule set version—confirming that all are the latest versions effective August 15, 2024 (excluding the test version v2.0). Based on the version information, it extracts the complete rule set data from the rule base. First, it performs basic score calculation (as the calculation base for subsequent rules), using the simplified basic score calculation formula preset in the rule base: Where S represents the user's base value for points calculation (subsequent rules R005 and R003 are calculated based on this value), M represents the user's actual consumption amount (taken from user U002's transaction parameters, which is 450 yuan); r represents the fixed consumption points ratio coefficient (the rule base is preset to 0.1, that is, 1 base point corresponds to every 10 yuan of consumption, which conforms to the conventional conversion logic of e-commerce points); L represents the user's membership level (U002 is a silver member, and the rule base marks the level as 3); c represents the fixed bonus points for membership level (the rule base is preset to 10 points / level, which is used to reflect the additional bonus of membership level to base points). Calculate U002's base score: S = 450 × 0.1 + 3 × 10 = 75 points; then load the core logic of R005 and R003. The R005 rule logic is "base score × activity budget coefficient" (daily budget coefficient 1.2), i.e., R005 score = 75 × 1.2 = 90 points. The R003 rule logic is "base score × interaction bonus coefficient" (based on U002's browsing and add-to-cart behavior, interaction bonus coefficient is 1.12), i.e., R003 score = 75 × 1.12 = 84 points. The engine executes the core rules in the order of "pre-calculation of base score → execution of core rules". The generated rule execution sequence is: [Basic score calculation → R005 parameter verification → R005 score calculation → R003 parameter verification → R003 score calculation → Total score summary (90+84=174 points)]. After receiving the execution sequence, the score calculation engine parses the formula and rule script through a hot loading mechanism, associates the basic score formula with the user transaction data interface and the member system interface, and binds the R005 and R003 logics to the basic score calculation results. After loading, the old rule logic is automatically replaced, and the new logic takes effect in real time. The entire process takes ≤50 milliseconds and does not interrupt the existing transaction processing.

[0100] In step S15, user requests are obtained at a preset ratio through a canary release mechanism, the updated points calculation logic is applied to the user requests, and the calculation results are compared with the expected results to obtain the verification results.

[0101] In one implementation, following the scenario after the update of the points calculation engine, this embodiment specifically describes the process of verifying the new logic using a canary release mechanism. The system presets a canary release ratio of 10%, and obtains user requests from the business request queue through a user ID hash modulo algorithm (ID%100<10), covering users who browsed, added to cart, and paid for product C during the Member Day event, including user U002 and 99 other eligible users.

[0102] The data acquisition module preprocesses the distributed user requests: it removes test accounts (such as user IDs prefixed with "TEST") and duplicate requests (multiple submissions of the same order within 30 seconds), and standardizes the request data into a unified format, including fields such as "user ID, consumption amount, product ID, behavior type, and timestamp." For example, the processed request data for U002 is as follows:

[0103] {"userId":"U002","amount":450,"goodsId":"C001","action":"purchase","timestamp":"2024-08-1515:30:22"}.

[0104] Based on a standardized dataset, the updated points calculation logic is applied: for U002's 450 yuan purchase, rule R005 (60 points for purchases over 400 yuan) is executed first, followed by rule R003 (10% discount + points coefficient 1.2). The calculation result is "actual payment of 413.1 yuan (450 × 0.9), points earned: 54 points (450 ÷ 10 × 1.2) + 60 points = 114 points". Simultaneously, the system generates the expected result according to preset rules: "Payment of 413.1 yuan, points: 114".

[0105] After comparing the calculated results with the expected results, a deviation calculation method (mean squared error, MSE) was used for difference analysis: the deviation was calculated for the points and payment amounts of 100 gray-scale requests. Among them, the result for U002 was without deviation. Of the remaining 99 requests, only one had a point deviation due to rounding, with an MSE of 0.01, which is far below the preset threshold of 0.5. The deviation verification result was judged as "passed", meaning that the updated points calculation logic is consistent with the expectation within the gray-scale range, and can proceed to the full deployment stage.

[0106] It is worth noting that the process of comparing the calculated results with the expected results and simultaneously using the deviation calculation method to perform difference analysis and output the deviation analysis results specifically includes: (based on MySQL + Elasticsearch) retrieving the expected results corresponding to the current "Member Day - Product C" business scenario: selecting the historical valid result set from the last 3 similar activities where the user browsed ≥10 times, spent ≥400 yuan, and triggered rules R005 and R003, containing the fields "User ID, Points Value, Rule Trigger Identifier (R005|R003), Calculation Time (Average 80ms)", where the expected result of historical samples with similar spending power to user U002 is "Points Value". The initial result was 114 points, consistent rule trigger identifier, and 75ms processing time. Next, the calculation result of U002 in the gray-scale test ("point value 114 points, rule trigger identifier R005|R003, processing time 78ms") was correlated with the expected result along the dimension of "user ID=U002 + business scenario=member day - product C" to verify the consistency of the rule trigger identifier: both were confirmed to trigger R005 and R003, with no rule mismatch issues, and were therefore considered valid samples. Of the 100 requests in the same gray-scale test, 2 were marked as invalid samples due to historical data triggering the old rule R006; after removing these, 98 valid samples were retained. The valid samples were analyzed using a deviation calculation method, specifically a weighted comprehensive deviation formula:

[0107] Where E is the sample aggregate bias, and A i Let B be the actual integral value of the i-th sample. i For its expected integral value, T i T represents the actual calculation time. i0 W is the expected time. iThe sample weights are 1.2 for high-value users, 1.0 for ordinary samples, and 1.2 for U002. β is the numerical deviation weight coefficient (0.7), γ=0.1, and θ=10ms. Calculation example: The comprehensive deviation of U002 is 1.2×(0.7×0+0.3×min(0.3,1))×100%=10.8%. The comprehensive deviation calculation process for sample ID56 is as follows: Sample ID56 is one of the 98 valid samples in the gray-scale test. The user attribute is ordinary member (level 2, participated in member day activities once in the last 30 days, historical points usage rate 55%). The business behavior data is that on August 15, 2024, from 14:30 to 14:40 (the core time period of member day), the user browsed member product C 8 times (6 valid browsing times after deduplication), added to cart 2 times, and spent 420 yuan (member exclusive product). The expected result is generated from the result repository built on MySQL+Elasticsearch, that is, matching the last 3 The expected result was obtained by averaging 20 valid historical samples from the "regular member + spending 400-450 yuan + browsing product C 5-10 times + adding to cart 2 times" activity during the second member day event: 114 points, 76ms calculation time, and rule trigger identifiers R005|R003. The weight W of sample ID56 is... i Based on the rule base's "User Value - Scenario Importance" two-dimensional mapping table, the following weights are determined: User value weight is 1.0 (regular members with a historical points usage rate <60%), and scenario importance weight is 1.0 (core time periods). Ultimately, W... i =1.0 × 1.0 = 1.0. Combining the weighted comprehensive deviation formula, substituting the parameter: actual integral value A i =115 points, expected score B i =114 points, actual calculation time T i =82ms, expected time T i0=76ms, numerical deviation weighting coefficient β=0.7, minimum value γ=0.1, time consumption deviation threshold θ=10ms, substituting into the weighted comprehensive deviation formula for calculation: 1.0×(0.7×1 / 114.1+0.3×min(0.6,1))×100%=18.6%. This deviation mainly stems from the calculation time exceeding expectations (82ms-76ms=6ms). The numerical deviation of the integral is only 0.88% (1 point), which does not affect the validity of the integral rights, so it is included in the valid samples. The overall analysis shows that the average comprehensive deviation rate of 98 samples is ≈0.92% (numerical deviation contributes 0.65%, and time consumption deviation contributes 0.27%). The largest single sample deviation is 18.6% (i.e., the comprehensive deviation of sample ID56), but the overall mean does not exceed the threshold. The final deviation analysis results include "deviation type, comprehensive deviation rate, sample coverage" and the specific sample deviation composition (such as the deviation of sample ID56 being mainly time consumption deviation), which clarifies that the current integral calculation logic is in line with expectations.

[0108] In step S16, when the data consistency in the verification result meets the preset verification standard, the updated integral calculation logic is fully deployed to the integral calculation engine through the rule scheduling module.

[0109] In one implementation, following the scenario where the gray-scale verification passes, this embodiment specifically describes the process by which the rule scheduling module fully deploys the updated points calculation logic to the points calculation engine. First, the rule scheduling module automatically generates a deployment instruction based on the gray-scale verification result (deviation analysis result is "passed"). The instruction includes core information such as "Deployment ID: DEP20240815001", "Target Engine Cluster: Points Calculation Engine Nodes 1-5", "Version to be Deployed: V2.3 (including optimized logic for R005 and R003)", and "Deployment Time Window: 2024-08-15 16:00-16:05 (off-peak hours)", ensuring the uniqueness and traceability of the deployment instruction.

[0110] Subsequently, the system retrieves the updated complete package of points calculation logic from the rule version repository (based on GitLab storage) according to the deployment instructions. This package includes R005's "60 points bonus for every 400 points spent" calculation script, R003's "10% discount + points coefficient 1.2 execution code", the associated user level determination interface configuration, and the dependent calculation function libraries. The integrity verification mechanism uses SHA-256 hash value comparison (verifying that the logic package has not been tampered with) and file list check (confirming that it contains 12 necessary files and none are missing) to determine that the logic package is complete and valid, and marks it as "Logic version V2.3 to be deployed".

[0111] The rule scheduling module synchronizes the version to be deployed to the five points calculation engine nodes via the distributed file transfer protocol (SFTP), employing a "rolling deployment" strategy: first, traffic access to node 1 is paused, version V2.3 is loaded and verified to be successfully loaded (returning a "logic ready" status code), then traffic is restored; deployment is then completed sequentially for nodes 2-5, with each node deployment taking approximately 30 seconds. Throughout the process, a load balancer ensures uninterrupted business requests. After deployment is complete, the engine cluster returns a "full deployment successful" confirmation message, and all node logs display "current running version: V2.3". The updated points calculation logic (R005 is executed first + R003 is executed supplementarily) takes effect across all users, and subsequent points calculations for user U002 and other users participating in member day activities are executed based on the new logic.

[0112] Following step S16, the process further includes: obtaining the running log from the points calculation engine and performing anomaly analysis using a preset anomaly detection algorithm to obtain anomaly analysis results; when the anomaly analysis results indicate the presence of anomalies, restoring the points calculation logic to the previous version of the rule configuration; obtaining user points data from the restored points calculation engine, performing cluster analysis to obtain user experience optimization parameters; and adjusting the corresponding rule parameters in the rule base based on the mapping relationship between the user experience optimization parameters and the rule configuration, thereby updating the rule base.

[0113] In one implementation, following the scenario where the aforementioned points calculation logic is fully deployed to the engine cluster, this embodiment specifically describes the anomaly handling and rule optimization process after deployment. First, the system uses a log collection tool (based on ELKStack) to obtain the real-time running logs of the points calculation engine. The logs contain fields such as "user ID, points calculation result, rule trigger record, calculation time, and error code." A preset anomaly detection algorithm (combining threshold method and isolated forest model) is used for analysis: the normal thresholds are set as "point deviation ≤ 1%, calculation time ≤ 100ms, and error code frequency ≤ 0.1%". After examining 5000 log entries within one hour of deployment, it was found that 3% of users (such as users U009, U015, etc.) had a points calculation deviation of 6% (actual points lower than expected), and the frequency of error code "E003" (rule script execution anomaly) increased to 1.2%. The anomaly analysis result determined that "anomaly exists."

[0114] The system immediately triggered a rollback mechanism: the rule scheduling module called the version management interface to restore the logical version of the points calculation engine from V2.3 to the previous stable version V2.2 (including the unadjusted R005 and R003 rules). The rollback process ensured data consistency through atomic operations, taking approximately 20 seconds, during which normal user transactions were not affected. After the recovery, user points data (including spending amount, points earned, user level, etc.) from the engine were extracted. K-means clustering analysis was used to divide users into three clusters: "high spending and high activity," "low spending and high frequency," etc. It was found that the points growth rate of "high spending and high activity" users (such as the cluster containing U002) was lower than expected under version V2.2. User experience optimization parameters were extracted: "The points coefficient for high-spending users needs to be increased to 1.3, and the trigger frequency limit should be relaxed to twice per day."

[0115] Based on the preset mapping relationship between optimized parameters and rule configurations (adjusting the point coefficient for "high-spending users" corresponding to R005, and adjusting the trigger frequency for "active frequency" corresponding to R003), the system updates the corresponding parameters in the rule base: increasing the extra points for R005 from 60 to 70 (coefficient 1.3), changing the daily trigger limit for R003 from 1 to 2 times, generating a new rule set {R005_v2.4, R003_v1.4}, and storing it in the Redis rule base after passing integrity verification, marking it as "version to be verified", and waiting for the next round of gray-scale testing.

[0116] It is worth noting that the process of obtaining user points data from the restored points calculation engine, performing cluster analysis, and obtaining user experience optimization parameters is more specifically implemented as follows: Following the scenario where the points calculation engine is restored to version V2.2, this embodiment specifically describes the cluster analysis of user points data and the generation process of user experience optimization parameters. First, the system obtains user points data from the restored engine for the past 7 days, covering 1000 users who participated in the Member Day activity, including detailed records of user U002. The data fields include: "Points Acquisition Channel (Transaction type, such as purchasing product C; Interaction type, such as browsing the activity page; Task type, such as completing member check-in)", "Points Arrival Time (Transaction type, average 45 seconds; Interaction type, average 3 minutes; Task type, average 1 minute)", "Points Usage Conversion Rate (Transaction type, 60%; Interaction type, 20%; Task type, 30%)", and "Points Calculation Dispute Records (23 records in total, including 15 transaction type and 8 interaction type)".

[0117] The acquired user points data is preprocessed and categorized: it is divided into three subsets based on the point acquisition channel—the transaction subset (including records of users earning points by purchasing goods, such as U002 earning 114 points by purchasing item C), the interaction subset (including records of users earning points by browsing and adding items to their cart), and the task subset (including records of users earning points by completing tasks such as check-ins). Each subset is then processed using an outlier detection algorithm (Z-score method) to remove abnormal and disputed records: for example, one erroneous record in the transaction subset showing "points arrival time - 5 seconds," and three duplicate disputed records in the interaction subset. Ultimately, 98% of the valid data is retained.

[0118] K-means clustering analysis was used to cluster the subsets: the transaction subset was clustered into 3 clusters, of which cluster 1 (high-spending users represented by U002) showed the common characteristics of "points arrival time > 60 seconds (higher than average) and objection records concentrated on 'points calculation delay'"; the interaction subset was clustered into 2 clusters, of which cluster 2 (high-frequency browsing users) showed the common characteristics of "points usage conversion rate < 15% (lower than average) and objection records concentrated on 'low perceived value of points'"; the task subset clustering results showed that the common characteristics were "stable arrival time and low objection rate".

[0119] The aforementioned common characteristics are transformed into quantifiable user experience optimization parameters: for the "delay in crediting" of transaction cluster 1, a target value for "points crediting time ≤ 30 seconds" is set; for the "high objection rate" of interaction cluster 2, a control threshold for "points calculation objection rate ≤ 2%" is set; and considering the perceived value of points for both clusters, "adjustment ranges for points calculation coefficients in transaction channels [1.3, 1.5] and for interaction channels [1.1, 1.3]" are set. These parameters are directly related to the subsequent rule adjustments for R005 (transaction category) and R003 (including interaction behavior association) in the rule base, providing data support for the generation of new rule sets.

[0120] refer to Figure 2 The second embodiment of the invention provides a real-time rule dynamic adjustment system for an integral calculation engine, comprising:

[0121] Signal acquisition module: Acquires promotional activity trigger signals from business scenarios through a pre-established event listening module;

[0122] Matching module: Matches the triggering signal with the triggering condition and the preset triggering threshold to obtain an applicable rule set;

[0123] Command output module: Based on the applicable rule set, extracts rule configuration parameters from the preset rule base, and obtains the rule switching command after parameter verification;

[0124] Update module: The rule switching instruction is distributed to the points calculation engine through the rule scheduling module to obtain the updated points calculation logic;

[0125] Verification module: It acquires user requests at a preset ratio through a canary release mechanism, applies the updated points calculation logic to the user requests, and compares the calculation results with the expected results to obtain the verification results;

[0126] Deployment module: When the data consistency in the verification results meets the preset verification criteria, the updated points calculation logic is fully deployed to the points calculation engine through the rule scheduling module;

[0127] The trigger signal carries trigger conditions, which include at least time parameters, user behavior parameters, and transaction parameters in the business scenario. The applicable rule set is a points calculation rule that matches the trigger conditions. The rule configuration parameters include at least points calculation coefficients, rule effective range, and conflict handling strategies.

[0128] It should be noted that the real-time rule dynamic adjustment system for an integral calculation engine provided in this embodiment of the invention is used to execute all the process steps of the real-time rule dynamic adjustment method for an integral calculation engine in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0129] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A method for real-time rule dynamic adjustment of an integral calculation engine, characterized in that, The method comprises the following steps: obtaining a promotion event trigger signal from a business scenario through a pre-established event listening module; matching a trigger condition corresponding to the trigger signal and a preset trigger threshold to obtain an applicable rule set; extracting rule configuration parameters from a preset rule library according to the applicable rule set, and obtaining a rule switching instruction after parameter verification; distributing the rule switching instruction to an integral calculation engine through a rule scheduling module to obtain updated integral calculation logic; obtaining a user request according to a preset proportion through a gray release mechanism, applying the updated integral calculation logic to the user request, and comparing the calculation result with an expected result to obtain a verification result; when the data consistency in the verification result meets a preset verification standard, deploying the updated integral calculation logic to the integral calculation engine in full through the rule scheduling module; wherein the trigger signal carries a trigger condition, the trigger condition at least includes a time parameter, a user behavior parameter and a transaction parameter in the business scenario, the applicable rule set is an integral calculation rule matched with the trigger condition, and the rule configuration parameter at least includes an integral calculation coefficient, a rule effective range and a conflict processing strategy.

2. The method of claim 1, wherein, The matching of the trigger condition corresponding to the trigger signal and the preset trigger threshold to obtain the applicable rule set comprises: parsing the trigger condition corresponding to the trigger signal, extracting the time parameter, the user behavior parameter and the transaction parameter, and structuring the parameters through real-time aggregation to obtain structured condition features; comparing the structured condition features with the preset trigger threshold through multi-dimensional matching to obtain a comparison result; based on the comparison result, screening integral calculation rules from the preset rule library, wherein each dimension comparison result reaches the corresponding preset trigger threshold, to form a candidate rule set; eliminating conflict rules through a rule priority mechanism for conflict identification of the candidate rule set; adapting and adjusting the candidate rule set after conflict identification in combination with real-time features of the current business scenario to obtain the applicable rule set; wherein the trigger threshold includes a time range threshold, an interaction frequency threshold and a transaction amount threshold, and the adjustment content of the adaptation and adjustment includes the effective range, the trigger frequency and the calculation coefficient of the integral calculation rule.

3. The method of claim 1, wherein, The extraction of the rule configuration parameters from the preset rule library according to the applicable rule set, and the generation of the rule switching instruction after parameter verification comprises: querying the applicable rule set corresponding to the current business scenario from the rule library, and eliminating rules that do not match the current business scenario and have been invalidated through a preset screening condition to obtain an optimized rule set; extracting rule configuration parameters supporting integral calculation through a preset data extraction logic according to the optimized rule set; transmitting the extracted rule configuration parameters to a parameter verification mechanism for parameter format verification according to a preset verification dimension, and outputting a verification result; when the verification result is passed, enabling a parameter matching logic to match the adapted parameter items according to the current business scenario requirements to generate a matched parameter set; generating a rule switching instruction by integrating parameter information according to a preset instruction format through an instruction generation mechanism based on the matched parameter set.

4. The method of claim 1, wherein, The rule switching instruction is distributed to the integral calculation engine by the rule scheduling module to obtain updated integral calculation logic, including: The rule switching instruction is format-verified and content-decomposed to output standardized instruction data; The rule set identifier is extracted from the standardized instruction data by the rule scheduling module, and the matching rule set version is queried from the preset rule library; According to the rule set version, the rule set data is extracted from the rule library, and a rule execution sequence is generated; The rule execution sequence is parsed and loaded by the integral calculation engine to update the integral calculation logic.

5. The method of claim 1, wherein, The updated integral calculation logic is applied to the user request according to the preset proportion through the gray release mechanism, and the calculation result is compared with the expected result to obtain a verification result, including: The user request is obtained from the business request queue according to the preset proportion through the gray release mechanism; The user request is preprocessed by the data acquisition module to output a standardized user request data set; According to the user request data set, the updated integral calculation logic is applied for calculation to generate the calculation result; The calculation result is compared with the expected result, and the deviation calculation method is used for difference analysis to output the deviation analysis result; According to the deviation analysis result, the deviation is verified to generate the verification result.

6. The method of claim 5, wherein, The calculation result is compared with the expected result, and the deviation calculation method is used for difference analysis to output the deviation analysis result, including: The expected result corresponding to the current user request is called from the preset result storage library; wherein the expected result is a set of historical effective integral calculation results matching the current business scenario, and contains integral value, rule trigger identifier and calculation time information; The calculation result and the expected result are associated one by one according to the user identifier and the business scenario dimension, and the consistency of the rule trigger identifier is verified to eliminate invalid comparison samples caused by rule mismatch; For the valid comparison samples with consistent rule trigger identifier, the integral value deviation between the calculation result and the expected result is determined by using the deviation calculation method, and the difference between the calculation time of the calculation result and the expected time is analyzed; According to the integral value deviation and the calculation time, the deviation analysis result containing the deviation type, the deviation degree and the corresponding sample information is generated.

7. The method of claim 1, wherein, The updated integral calculation logic is deployed to the integral calculation engine by the rule scheduling module, including: A deployment instruction is generated by the rule scheduling module; According to the deployment instruction, the updated integral calculation logic is obtained and integrity-verified, and the integral calculation logic that passes the verification is used as the logic version to be deployed; The logic version to be deployed is transmitted to the integral calculation engine by the rule scheduling module to complete the full deployment.

8. The method of claim 1, wherein, After the updated integral calculation logic is fully deployed to the integral calculation engine, it further includes: The running log is obtained from the integral calculation engine, and the preset abnormality detection algorithm is used for abnormality state analysis to obtain an abnormality state analysis result; When the abnormal state analysis result is that there is an abnormality, the integral calculation logic is restored to a previous version rule configuration; User integral data is obtained from the restored integral calculation engine, and after cluster analysis, user experience optimization parameters are obtained; Based on the mapping relationship between the user experience optimization parameters and the rule configuration, the corresponding rule parameters are adjusted in the rule library, and the rule library is updated.

9. The method of claim 8, wherein, The user integral data is obtained from the restored integral calculation engine, and after cluster analysis, user experience optimization parameters are obtained, including: User integral data is obtained from the restored integral calculation engine; The user integral data is classified and preprocessed, divided into three data subsets of transaction, interaction and task according to the integral source, and each data subset excludes abnormal objection records; A clustering analysis method is used to cluster and analyze each data subset to identify the common characteristics of users in the same data subset; The common problem corresponding to the common characteristics is converted into quantified user experience optimization parameters; The user integral data includes user integral acquisition channel, integral account duration, integral use conversion rate and integral calculation objection record, and the user experience optimization parameters include integral account time limit target value, integral calculation objection rate control threshold and integral calculation coefficient adjustment interval of the corresponding channel.

10. A system for dynamic adjustment of real-time rules for a credit calculation engine, characterized in that, It includes: Signal acquisition module: obtain the promotion activity trigger signal from the business scene through the pre-established event listening module; Matching module: match the trigger condition corresponding to the trigger signal and the preset trigger threshold to obtain the applicable rule set; Instruction output module: according to the applicable rule set, extract rule configuration parameters from the preset rule library, and obtain rule switching instructions after parameter verification; Update module: distribute the rule switching instructions to the integral calculation engine through the rule scheduling module to obtain the updated integral calculation logic; Verification module: through the gray release mechanism, obtain user requests according to the preset proportion, apply the updated integral calculation logic to the user request, and compare the calculation result with the expected result to obtain the verification result; Deployment module: when the data consistency in the verification result meets the preset verification standard, deploy the updated integral calculation logic to the integral calculation engine through the rule scheduling module; The trigger signal carries the trigger condition, the trigger condition at least includes the time parameter, the user behavior parameter and the transaction parameter in the business scene, the applicable rule set is the integral calculation rule matched with the trigger condition, and the rule configuration parameter at least includes the integral calculation coefficient, the rule effective range and the conflict processing strategy.

Images