A message-driven data center consistency control method based on low-code rule evolution

Abstract

The application provides a message-driven data center consistency control method based on low-code rule evolution, comprising: constructing a low-code rule model, establishing a rule version evolution mechanism, implementing a message-driven event flow, constructing a rule consistency control mechanism, and executing state synchronization through a data center. The rule conditions, rule actions and event relationships are configured visually in a low-code manner. Rule dynamic evolution control is achieved through a rule state space model, a rule evolution model, a message consistency model and a double rule window model. The rule engine performs message routing, field parsing and rule processing according to the associated rule version of the message, and combines idempotent checking, rule conflict detection, event traceability and compensation recalculation mechanism to realize data consistency control between distributed nodes, thereby improving the stability, reliability and eventual consistency control capability of the data center in a high-concurrency and dynamic rule scenario.

Description

Technical Field

[0001] This invention relates to the fields of low-code platforms, message-driven architectures, and distributed data consistency technologies, and in particular to a message-driven data platform consistency control method based on low-code rule evolution. Background Technology

[0002] With the development of low-code platforms, microservice architectures, and message-driven technologies, an increasing number of data platform systems are adopting rule engines to implement business logic orchestration, data processing, and event-driven control. Visually configuring rules in a low-code manner reduces the complexity of business rule development and improves system flexibility and scalability, and is now widely used in scenarios such as IoT monitoring, intelligent operation and maintenance, energy management, and data governance. In existing technologies, business rules are typically transmitted and executed between multiple business nodes via message queues, with each node performing data calculations, state synchronization, and event processing based on the rule content. However, in distributed data processing platform scenarios, business rules are frequently updated as business needs change, resulting in a dynamic evolution of the rule model. When rule versions change, inconsistencies in rule execution logic between different nodes can easily occur, further leading to problems such as duplicate message consumption, rule execution conflicts, invalid historical data results, and asynchronous node states.

[0003] Furthermore, most existing rule systems employ static rule loading, lacking a unified management and dynamic control mechanism for rule versions, making it difficult to achieve hot rule updates, canary releases, and version rollbacks. Simultaneously, in message-driven scenarios, some systems lack idempotent verification, event tracing, and compensation recalculation mechanisms. When messages are abnormal, nodes fail, or rules change, they cannot perform consistency repairs on historical events, thus affecting the accuracy of data platform results and system stability. Therefore, how to achieve unified rule version management, message-driven event synchronization, and distributed data consistency control in low-code rule dynamic evolution scenarios has become a pressing technical problem that needs to be solved in current data platform systems. Summary of the Invention

[0004] Purpose of the Invention: The purpose of this invention is to solve the data consistency control problem existing in message-driven data platforms during the dynamic evolution of rules. Specifically, this invention provides a consistency control method for message-driven data platforms based on low-code rule evolution. It includes the following steps:

[0005] Step 1: Build a low-code rules model;

[0006] Step 2: Establish a rule version evolution mechanism;

[0007] Step 3: Implement rule-based event flow based on a message-driven architecture;

[0008] Step 4: Construct a rule consistency control mechanism;

[0009] Step 5: Aggregate rule execution results and synchronize distributed states through the data platform.

[0010] Step 1 includes the following steps:

[0011] Step S100: Build the rule model: Create a rule model in the low-code platform and configure the basic attributes of the rules and the rule editing functions;

[0012] Step S110: Configure rule conditions and execution actions: Configure rule trigger conditions, execution actions, and event relationships through visual forms, drag-and-drop components, or DSL expressions;

[0013] Step S120: Configure rule events: Configure rule trigger events, event types, and event flow relationships based on the target business scenario;

[0014] Step S130: Configure rule variables: Configure rule variables in the rule mapping unit to establish the mapping relationship between rule fields and business data fields;

[0015] Step S140: Generate rule metadata: Convert the rule logic into structured rule metadata and store it uniformly;

[0016] Step S150: Establish the Rule State Space Model (RSSM); the low-code rule platform generates rule state objects based on the rule schema structure, rule constraints, rule version number, and field mapping relationships, and calculates the rule state index. ,in As weight, Represents the schema structure of the rules; Indicates rule conditions and constraints; Indicates the rule version number; This represents the field mapping relationship, where i takes values ​​from 1 to n, and n is a positive integer.

[0017] Feature values ​​are calculated based on the rule structure, rule conditions, rule version, and field mapping. The weighted values ​​are then used to obtain the rule state index, and a state space is established according to the rule state index.

[0018] In step S100, the basic attributes of a rule include rule name, rule number, rule type, priority, and effective status; the rule editing function includes adding, modifying, deleting, querying, and starting / stopping rules.

[0019] In step S110, the rule conditions include conditional expressions, logical operators, and trigger thresholds; the execution actions include any one of message push, status update, device control, data calculation, and event forwarding.

[0020] In step S130, the rule variables include variable name, variable type, event topic, field key, and data source identifier; among them, the variable type can be any of the following: integer, floating point, character, or JSON object.

[0021] Step 2 includes the following steps:

[0022] Step S200: Establish a rule version number management mechanism;

[0023] Step S210: Record the rule creation time, effective time, and version change records;

[0024] Step S220: Implement hot rule updates based on the rule center;

[0025] Step S230: The business node subscribes to the rule change event and synchronizes the latest rule version;

[0026] Step S240: Implement rule canary release and version switching based on rule version information;

[0027] Step S250: When a rule is abnormal, perform a rule rollback operation, which includes: when the rule center detects that the new rule version has an execution abnormality, data conflict or business failure, it automatically restores to the previous stable rule version and reloads the historical rule cache;

[0028] Step S260: Establish a rule-based evolution model and calculate the degree of evolution. When the degree of evolution If the value exceeds the evolution judgment value corresponding to the current rule state, a new rule version is generated; the rule evolution result is calculated based on the change in rule state. ,in , , These are weighting coefficients; Represents the regular evolution function; This represents the set of target rule states after a single evolution, i.e., the rule states corresponding to the next time step. Indicates the current rule status; Indicates the amount of change in the rule structure; Indicates the amount of change in the rule conditions; This indicates the amount of change in the field mapping.

[0029] In step S200, a unique rule identifier RuleID is generated for each rule, and a rule version chain is established based on the version number Version. The same rule identifier corresponds to two or more historical rule versions. The rule version number is incremented in chronological order to distinguish different rule states in the rule evolution process.

[0030] In step S220, after detecting a change in rule configuration, the rule center automatically generates a new rule version and loads the new rule into the rule cache. Before the new rule takes effect, the original rule continues to process the current business events, thereby achieving uninterrupted hot updates of rules.

[0031] In step S230, the business node listens for rule update events by subscribing to the rule change Topic; when it receives a rule update notification, the business node pulls the corresponding rule content according to the rule number and version number, and updates the local rule cache.

[0032] In step S240, the canary release process progressively enables the new rule version according to device type, service group, tenant identifier, or node range; a canary evolution control model (GECM) is established, defining the canary state. Represented as: The rules center calculates the gray-scale release ratio of the current new rule version based on the gray-scale status. ;in This indicates the canary release ratio of the current new rule version; Indicates the grayscale node coverage rate; Indicates the coverage rate of grayscale users; Indicates the grayscale flow ratio; Indicates the time window factor; These are the weighting coefficients, and ;when If the threshold for gray-scale release is exceeded, the release scope of the new rule version will be expanded; otherwise, the current rule version will continue to operate.

[0033] Step 3 includes the following steps:

[0034] Step S300: A business event is generated by the business system or terminal device;

[0035] Step S310: The message producer sends the business event to the message queue, and encapsulates the event identifier, rule number, rule version number, event timestamp and business context information.

[0036] Step S320: The message queue completes message classification and routing based on the event Topic, business tag, or rule type, and writes the messages to the corresponding message partitions in the order of the events, thus completing message routing and distribution;

[0037] Step S330: The rule engine subscribes to event messages and executes rule logic. That is, after receiving an event message, the rule engine loads the corresponding rule according to the rule version information and executes rule matching, condition judgment and action scheduling according to the rule priority.

[0038] Step S340: The rule execution result is written to the event log and synchronized to the data platform;

[0039] Step S350: Establish a message consistency model. The rule engine calculates the message consistency identifier based on business event data and rule version. A one-to-one correspondence between messages and rule versions is established based on the message consistency identifier (CID); whereby... Represents a hash function;

[0040] The business events in step S300 include any one of the following: device status events, user operation events, alarm events, control events, and data acquisition events;

[0041] The message queue in step S320 includes RabbitMQ, Kafka, or other message middleware that supports the publish-subscribe pattern.

[0042] In step S340, the rule execution log includes the event identifier, rule version number, execution status, execution result, exception information, and execution time;

[0043] Step 4 includes the following steps:

[0044] Step S400: Establish a rule version binding mechanism. The system calls the corresponding rule instance according to the rule version information to ensure the consistency of the correspondence between historical events and rule versions.

[0045] Step S410: Establish a message idempotency verification mechanism. When a duplicate event is detected, the system automatically intercepts duplicate execution requests.

[0046] Step S420: Establish the Rule Conflict Evaluation Model (RCEM), and the rule engine calculates the rule conflict value. Select a conflict handling strategy based on the rule conflict value. Execute conflict resolution if necessary, otherwise execute directly; where , , Indicates the weighting coefficient; This indicates a conflict in the rules; Indicates a conflict between rules and actions; This indicates a rule priority conflict; T represents the system's preset rule conflict threshold.

[0047] Step S430: Establish an event tracing and compensation recalculation mechanism. When the rule version changes or a node execution is abnormal, the data platform performs event replay, historical tracing and compensation recalculation based on the event log.

[0048] Step S440: Establish an eventual consistency control mechanism, enabling the system to achieve eventual data consistency control in a distributed environment through rule version binding mechanism, message idempotency verification mechanism, event tracing mechanism, and compensation recalculation mechanism;

[0049] Step S450: Establish a dual-rule window model to enable the parallel operation of old and new rules and state transition control during rule switching.

[0050] In step S400, when a business event executes a rule, it binds the corresponding rule version information. The event data includes the event identifier, rule number, rule version number, and timestamp.

[0051] In step S410, the system generates an idempotent check key using the event's unique identifier and the rule version number, and implements message deduplication control through Redis caching or a unique index in the database.

[0052] In step S420, rule conflict detection includes rule condition conflict detection, rule action conflict detection, and rule priority conflict detection; rule compatibility verification includes rule field compatibility verification, rule structure compatibility verification, and rule version dependency verification.

[0053] The compensation recalculation process in step S430 includes obtaining the abnormal event log, loading the corresponding rule version, re-executing the rule logic, updating the business status data, and synchronizing the compensation results; all business events are written to the event storage center in chronological order, and the original event data, rule version information, and execution results are retained.

[0054] The consistency control in step S440 includes node state consistency verification, message processing result consistency verification, rule version consistency verification, and cache state consistency verification.

[0055] In step S450, a dual-rule window is created. When the event satisfies: The rules engine performs calculations based on the event timestamp.

[0056] ,

[0057] in Indicates timestamp as The rule engine selects the rule version to execute at any time; This indicates the time point that marks the boundary between old and new rules within the rules window; Indicates the start time of the rules window; Indicates the end time of the rules window;

[0058] The rule engine calls the corresponding rule version to complete event parsing based on the calculation results; when the event time exceeds the window end time... At that time, only the new rule is invoked. Execute parsing;

[0059] Step 5 includes the following steps:

[0060] Step S500: The data platform receives rule execution results and status events: It receives rule execution results, device status data, and business event logs through message subscription and establishes a unified event access channel;

[0061] Step S510: Aggregate data and synchronize status for the rule results;

[0062] Step S520: Create the rule result table and event log table;

[0063] Step S530: Business nodes synchronize execution status according to rule version information, that is, each business node periodically reports local rule version information and execution status to the data platform; the data platform generates a unified status view based on the node status;

[0064] Step S540: When a node is in an abnormal state, the consistency compensation process is triggered. That is, when the system detects that the node rule version is inconsistent, message processing fails, or state synchronization is abnormal, the consistency compensation process is automatically triggered.

[0065] Step S550: Implement data consistency control among multiple business nodes through the data middle platform. That is, the data middle platform performs unified verification and consistency control on the data status of multiple business nodes based on the rule version binding mechanism, event tracing mechanism and compensation mechanism.

[0066] In step S510, data aggregation includes rule execution result aggregation, device status aggregation, event statistical analysis, and rule hit statistics; status synchronization includes node status synchronization, rule status synchronization, and cache status synchronization.

[0067] In step S520, the rule result table is used to store the rule execution result, rule version number and business status information; the event log table is used to record the original event data, event processing process and exception information.

[0068] This application provides a message-driven data platform consistency control method based on low-code rule evolution. It adopts a low-code approach to visualize and dynamically orchestrate business rules, and is suitable for data processing platform scenarios with multiple data sources, multiple business nodes, and distributed service collaboration. It realizes rule event flow through message-driven architecture, and combines rule version control, idempotent verification, event tracing, and compensation recalculation mechanisms to achieve distributed consistency control in the dynamic evolution process of rules, thereby improving the data reliability, state consistency, and operational stability of the system in high-concurrency and dynamic rule scenarios.

[0069] Beneficial Effects: This invention enables visualized configuration and dynamic evolution management of business rules through a low-code rule platform. It combines the Rule State Space Model (RSSM), Rule Evolution Model (REM), Message Consistency Model (MCM), and Dual Rule Window Model (DRWM) to establish a consistency control mechanism during the dynamic evolution of rules, achieving correlation management between rule versions, business events, and message processing processes. Compared with existing technologies, this invention ensures the correct parsing of historical and new messages during dynamic rule updates, improving data consistency, rule evolution stability, and system reliability in a distributed data platform. It is suitable for message-driven data processing platforms with multiple business nodes, high concurrency, and complex business scenarios. Attached Figure Description

[0070] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.

[0071] Figure 1 This is a flowchart illustrating the construction process of a low-code rule model in one embodiment of the present invention.

[0072] Figure 2 This is a flowchart illustrating the rule version evolution in one embodiment of the present invention.

[0073] Figure 3 This is a flowchart illustrating the message-driven event flow in one embodiment of the present invention.

[0074] Figure 4 This is a flowchart of the message consistency model processing in one embodiment of the present invention.

[0075] Figure 5 This is a flowchart of rule consistency control in one embodiment of the present invention.

[0076] Figure 6 This is a flowchart of idempotency verification in one embodiment of the present invention.

[0077] Figure 7 This is a flowchart of rule compensation recalculation in one embodiment of the present invention.

[0078] Figure 8 This is a diagram of the overall architecture of a message-driven data platform according to one embodiment of the present invention. Detailed Implementation

[0079] This invention provides a message-driven data platform consistency control method based on low-code rule evolution, comprising the following steps:

[0080] Step 1: Build a low-code rule model:

[0081] In one implementation, please refer to Figure 1 It includes the following steps:

[0082] S100: Constructing a rule model;

[0083] Specifically, in one embodiment, the system creates a rule model in a low-code rule platform and configures the basic attributes and rule editing functions of the rules. In one embodiment, the basic attributes of the rules include rule name, rule number, rule type, rule priority, rule version number, rule active status, rule scope, rule triggering event, and rule execution action. The rule editing functions include adding, modifying, deleting, starting, stopping, and version switching of rules. Furthermore, in one embodiment, the rule editing functions also include rule restrictions, such as unique rule numbers, non-repeating rule versions, and prohibition of direct deletion when the rule is active. The system completes rule orchestration through a low-code visual interface, and users complete rule logic configuration through form configuration, drag-and-drop components, DSL expressions, and process nodes.

[0084] Furthermore, in one implementation scheme, the rule platform uses a JSON Schema structure to describe the rule model and stores it uniformly in the rule metadata database. An example is as follows:

[0085] {

[0086] “ruleID”:“R1001”,

[0087] "eventType":"temperature",

[0088] "condition":"temperature>60",

[0089] "action": "sendAlarm",

[0090] "priority": "high",

[0091] "version": "v1.0"

[0092] }

[0093] When a rule is saved, the system automatically generates a unique rule identifier (RuleID) and establishes a rule version index. After the rule is saved, it automatically generates a rule cache and synchronizes it to the rule center.

[0094] S110: Configure rule logic;

[0095] Specifically, in one implementation, users configure rule logic through visual forms, drag-and-drop components, or DSL expressions. The rule conditions include conditional expressions, logical operators, and trigger thresholds. The logical operators include AND, OR, and NOT. The execution actions include message push, status update, device control, data calculation, service invocation, event forwarding, and status synchronization.

[0096] For example:

[0097] IF temperature > 35℃;

[0098] THEN send an alarm event;

[0099] In one embodiment, the rule platform automatically converts DSL expressions into a structured rule tree, which includes condition nodes, logical operation nodes, and action execution nodes. In another embodiment, the system constructs the rule condition tree using a recursive parsing method, where the logical operators include AND, OR, and NOT. The system executes the rule tree using a depth-first traversal approach. When a rule condition is met, the system calls an action executor to execute the corresponding business action. The action executor includes a message sending component, a status update component, a service call component, a data synchronization component, and an event forwarding component. Further, in one embodiment, a status event is automatically generated after the rule execution is completed.

[0100] S120: Configuration rule event;

[0101] Specifically, in one implementation, the system configures rule events based on business scenarios. These rule events include device events, user behavior events, data change events, state synchronization events, and system alarm events. In one implementation, all rule events are published and subscribed to via Topics, where message queues route messages according to different Topics.

[0102] For example:

[0103] Iot / devic / alarm;

[0104] order / pay / success;

[0105] rule / update;

[0106] device / status / change;

[0107] Furthermore, in one embodiment, the system achieves asynchronous event decoupling through Kafka or RabbitMQ. After the message producer sends the event message to the message queue, the message consumer consumes the corresponding event according to the subscription relationship.

[0108] S130: Configure rule variables;

[0109] Specifically, in one embodiment, the system configures rule variables in the rule mapping unit and establishes a mapping relationship between rule fields and business data fields. The rule variables include variable name, variable type, event topic, field key, data source identifier, and field path. The variable type can be integer, floating-point, character, or JSON object.

[0110] For example:

[0111] Temperature corresponds to sensor / temp / value;

[0112] status corresponds to device / state / code;

[0113] Furthermore, in one implementation, the rules engine automatically parses the JSON event data based on the mapping relationship. For example:

[0114] {

[0115] “device”:{

[0116] “sensor”:{

[0117] "temp":{

[0118] “value”:68

[0119] }

[0120] }

[0121] }

[0122] }

[0123] In one implementation, the system extracts the corresponding rule variable value based on the field path sensor.temp.value;

[0124] S140: Generate rule metadata;

[0125] Specifically, in one implementation, the system automatically converts rule logic into structured rule metadata. Rule metadata includes rule structure, rule conditions, action sets, rule dependencies, rule version, rule priority, Topic relationships, and field mapping relationships. In one implementation, the system uniformly stores the rule metadata in a rule metadata database, and simultaneously establishes a rule cache center, automatically pulling the latest rules from the rule center when business nodes start.

[0126] S150: Establish a rule-based state-space model.

[0127] Specifically, in one implementation scheme, a Rule State Space Model (RSSM) is established to provide a unified abstract description of rule structure, rule constraints, and rule mapping relationships.

[0128] Specifically, the rule set is defined as:

[0129] ,

[0130] Each rule state is represented as follows:

[0131] ,

[0132] Represents the schema structure of the rules; Indicates rule conditions and constraints; Indicates the rule version number; This indicates the mapping relationship between rule fields.

[0133] Furthermore, in one embodiment, the system automatically generates rule state objects through a low-code rule platform and writes them into the rule state space model. When a rule is modified, the platform automatically updates the corresponding rule state and automatically writes the rule state change event to the event log center.

[0134] Step 2: Establish a rule version evolution mechanism:

[0135] Please see Figure 2 The steps for the evolution of the rule version are as follows:

[0136] S200: Establish a rule version number management mechanism;

[0137] Specifically, in one implementation, the system uses a combination of major and minor version numbers to manage rule versions;

[0138] For example:

[0139] v1.0,

[0140] v1.1,

[0141] v1.2,

[0142] Major versions indicate changes in rule structure, while minor versions indicate adjustments to rule parameters.

[0143] S210: Record rule change messages;

[0144] Specifically, in one implementation, the system records the rule creation time, effective time, modification time, and user information. A corresponding version snapshot is generated after each rule modification.

[0145] S220: Implement hot rule updates based on the rule center;

[0146] Specifically, in one implementation, the rule center publishes the latest rules to the message bus. Business nodes listen for rule updates (Topic: rule / update). When a business node receives a rule change message, the system executes rule cache invalidation, new rule loading, rule tree reconstruction, and local rule synchronization. In one implementation, business services are not interrupted during rule updates; the system uses a hot update mechanism to achieve dynamic rule switching.

[0147] S230: Business node synchronization rule version;

[0148] Specifically, in one implementation, the business node subscribes to rule change events. When a rule version change is detected, the business node reloads the rule cache and synchronously updates the local rule status.

[0149] S240: Enables rule canary release and version switching;

[0150] Specifically, in one implementation, the system establishes a Gray Evolution Control Model (GECM) to control the grayscale switching range between old and new rule versions during rule evolution. The grayscale control state is defined as follows:

[0151] ,

[0152] in Indicates the range of grayscale nodes; Indicates the range of users in the grayscale test; Indicates the grayscale flow ratio; This represents the grayscale time window.

[0153] Furthermore, the system dynamically adjusts the traffic allocation ratio between the old and new rule versions based on the grayscale control status, and adjusts the grayscale release range in real time according to the node's operating status.

[0154] S250: Rule exception rollback;

[0155] Specifically, in one implementation, when the rule execution anomaly rate exceeds a preset threshold, the system automatically switches to the previous stable version. At the same time, the system restores the corresponding business status data based on the event log, resynchronizes the node cache status, and records the rule rollback log.

[0156] S260: Establish a rule evolution model;

[0157] Specifically, in one implementation, a rule evolution model (REM) is established. When a rule is updated, the system implements rule migration through a rule evolution function:

[0158] ,

[0159] in Indicates the amount of change in the rule structure; Indicates the amount of change in the rule conditions; Indicates the amount of change in the field mapping; Represents the rule evolution function.

[0160] Furthermore, in one embodiment, the system automatically generates rule migration paths, rule dependencies, and rule impact scopes based on rule differences, thereby determining whether to perform historical event recalculation based on the impact scope. REM performs state transition calculations based on rule state objects in RSSM and generates new rule state nodes according to changes in rule structure, rule conditions, and field mapping.

[0161] Step 3: Please refer to Figure 3 , Figure 4 The rule-based event flow steps based on the message-driven architecture are as follows:

[0162] S300: Business system generates business events;

[0163] Specifically, in one embodiment, business events are generated by a business system, device terminal, or application service. These business events include order events, device alarm events, device status events, and data synchronization events.

[0164] S310: The message producer sends an event message;

[0165] Specifically, in one implementation, the message producer encapsulates the event into a JSON structure and sends it to the message queue. An example is as follows:

[0166] {

[0167] “eventID”:“E1001”

[0168] "temperature": 68,

[0169] "timestamp":"2026-05-18",

[0170] }

[0171] S320: The message queue completes message routing;

[0172] Specifically, in one implementation, the message queue uses Kafka, RabbitMQ, or other message middleware that supports the publish-subscribe pattern to complete message routing and distribution based on the Topic;

[0173] S330: The rule engine subscribes to and executes rule logic;

[0174] Specifically, in one implementation, after the rule engine retrieves an event message from the message queue, it first loads the corresponding rule cache based on the subscribed Topic and rule version number. The system then parses the event data according to the field mapping relationship. Further, in another implementation, the system generates a rule condition tree based on DSL expressions. When the rule conditions are met, the system calls the action executor to execute the rule action; after the rule execution is complete, a status event is generated. The system then writes the execution result to the event log center. An example is as follows:

[0175] {

[0176] “eventId”:“E1001”

[0177] “ruleId”:“R1001”

[0178] "ruleVersion":"v1.0",

[0179] "executeResult":"success",

[0180] }

[0181] S340: The rule execution result is written to the event log and synchronized to the data platform;

[0182] Specifically, in one implementation, after the rule engine completes the execution of the rule logic, it automatically generates the rule execution result and writes the result to the event log center. Simultaneously, it synchronizes the result to the data platform via a message queue for subsequent state synchronization, consistency verification, and event tracing. The rule execution result includes the event identifier (EventID), rule number (RuleID), rule version number (RuleVersion), node number (NodeID), execution status, execution result, exception information, and execution time.

[0183] Furthermore, in one embodiment, the system encapsulates the rule execution results into structured log objects and writes them to the event storage center in chronological order. The data platform receives the rule execution results by subscribing to the corresponding Topic and establishes an event index relationship based on the event identifier and rule version number. When rule execution fails, the system records the exception information and triggers message retry, event compensation, or historical event replay processes based on the exception status.

[0184] S350: Establish a message consistency model;

[0185] Specifically, in one implementation, a Message Consistency Model (MCM) is established. Business events are defined as follows:

[0186] ,

[0187] in Represents event data; Indicates the rule version corresponding to the event; Indicates the event timestamp.

[0188] Furthermore, the system uses a rule version binding mechanism to achieve the association and parsing of events and rules.

[0189] Step 4: Please refer to Figure 5 , Figure 6 , Figure 7 The steps to build a rule consistency control mechanism are as follows;

[0190] S400: Establish a rule version binding mechanism;

[0191] Specifically, in one implementation, business events are bound to corresponding rule version information when executing rules. Event data includes an event identifier, rule number, rule version number, node number, and timestamp. For example:

[0192] {

[0193] “eventId”:“E1001”

[0194] “ruleId”:“R1001”

[0195] "ruleVersion":"v1.0",

[0196] “nodeId”:“Node01”

[0197] "timestamp":"2026-05-1810:00:00",

[0198] }

[0199] In one implementation, the system establishes a unique association between events and rules based on event identifiers and rule version numbers, which is used for subsequent rule tracing, event replay, and compensation recalculation. In another implementation, the rule engine automatically loads the corresponding rule cache based on the rule version number when consuming messages, thereby ensuring rule consistency during event execution.

[0200] S410: Establish a message idempotency verification mechanism;

[0201] Specifically, in one implementation, the system uses a unique event identifier and a rule version number to generate an idempotent verification key. A reference example is shown below:

[0202] IdempotentKey=EventId+RuleVersion.

[0203] Furthermore, the system implements message deduplication through Redis caching, database unique indexes, or message consumption offset recording mechanisms. When the system detects a duplicate message, it automatically terminates the duplicate execution and records a duplicate consumption log. In one embodiment, the system establishes a message consumption status record table, which includes event ID, consumption node, consumption status, consumption time, and rule version information to prevent message duplication, message loss, and message out-of-order issues. Simultaneously, in high-concurrency scenarios, the system employs a distributed lock mechanism to control the concurrent execution of the same event, avoiding data inconsistency caused by multiple nodes processing the same business event simultaneously.

[0204] S420: Establish a rule conflict detection and compatibility verification mechanism;

[0205] Specifically, in one implementation, the system establishes a Rule Conflict Evaluation Model (RCEM) to quantitatively analyze and evaluate the conflict relationships between multiple rules. The rule conflict evaluation function is expressed as:

[0206] ,

[0207] in Indicates the degree of conflict between rule conditions; Indicates the degree of conflict between rules and actions; Indicates the degree of conflict in rule priority; This indicates the results of a comprehensive conflict assessment of the rules.

[0208] Furthermore, in one embodiment, the system calculates rule conflict weights based on rule condition overlap rate, rule action scope, and rule priority differences, and generates a rule conflict handling strategy based on the conflict assessment results. For example:

[0209] when When the threshold is below a preset value, rules can be executed in parallel.

[0210] when When the threshold is exceeded, the system will automatically execute rule priority arbitration or block the publication of the rule.

[0211] S430: Establish an event tracing and compensation recalculation mechanism;

[0212] Specifically, in one implementation, all business events are written to the event storage center in chronological order. The system retains the original event data, rule version information, execution results, execution time, and node information. The system enables event retrieval and event playback based on event ID, time window, event topic, and rule version, and supports historical result tracing, data recovery, and rule execution process reconstruction.

[0213] In one implementation, when a rule version changes, a business node fails to execute, or a node status becomes abnormal, the system locates the affected data range based on rule difference analysis results and performs historical event replay based on event logs. In another implementation, the system establishes a message retry mechanism. When a business node fails to execute, the system writes the failure message to a retry queue and resends the message at preset time intervals. For example:

[0214] First retry: 5 seconds

[0215] Second retry: 30 seconds

[0216] Third retry: 1 minute

[0217] The system also sets a maximum number of retries. When the maximum number of retries is exceeded, the system writes the message to the DeadLetterQueue and generates an exception alarm event.

[0218] Furthermore, in one embodiment, the compensation process includes message redelivery, data resynchronization, historical event replay, state recalculation, and cache reloading. Application scenarios are as follows:

[0219] Node A executed successfully under rule version v1.0, while Node B failed to consume the event during the rule upgrade. After detecting the missing state of Node B, the system automatically read the corresponding historical event from the event log center and re-executed the rule logic, thereby restoring the business state of Node B.

[0220] In one implementation, the system uses an incremental correction method, performing compensation recalculation only on affected events, thereby reducing the system resource consumption caused by full recalculation.

[0221] S440: Establish an eventual consistency control mechanism;

[0222] Specifically, in one implementation, the system achieves eventual consistency control of data in a distributed environment by coordinating rule version binding mechanisms, message idempotency verification mechanisms, event tracing mechanisms, and compensation recalculation mechanisms.

[0223] In one implementation, the data platform establishes a node status monitoring module to periodically monitor the rule execution status, message consumption status, message consumption offset, and version rule status of each business node. When the system detects a consistency anomaly, it automatically determines that a node has experienced a consistency anomaly and triggers a consistency recovery process. The consistency anomaly includes situations such as a node failing to return a status confirmation message for an extended period, message consumption timeout, inconsistent node status, inconsistent rule versions, or abnormal message consumption offsets. The consistency recovery process includes invoking the message retry mechanism to resend failed messages; invoking the event tracing mechanism to obtain historical event records; invoking the compensation recalculation mechanism to re-execute the abnormal rules; and resynchronizing the node rule version and status data.

[0224] Furthermore, in one embodiment, when the abnormal node recovers to normal, the system re-verifies the consistency of the status of each business node and updates the node status table. When the status of all business nodes meets the requirements of consistent rule version, consistent data status, and consistent message consumption offset, the system determines that the current distributed nodes have reached the final consistent state.

[0225] S450: Establish a dual-rule window model;

[0226] Specifically, in one implementation, a dual-rule window model (DRWM) is established.

[0227] When the rule is Evolved into The system establishes a rules window:

[0228] ,

[0229] in Indicates the start time of the rules window; Indicates the end time of the rule window.

[0230] During the window:

[0231] ,

[0232] The system retains both old and new rules simultaneously, enabling parallel rule parsing. When the event duration exceeds the window's end time... Afterwards, the system stopped the old rules. The analysis only retains the new rules. Continue execution.

[0233] Furthermore, in one implementation, old events are still processed by the old rules, and new events are processed by the new rules, thereby avoiding data inconsistency issues during rule switching. In a canary release scenario, the system dynamically selects the rule version based on business nodes, user scope, or time windows to achieve smooth rule migration and uninterrupted switching.

[0234] In one implementation, DRWM is used to solve the problem of parallel parsing and state transition during rule version switching. It differs from the event version binding mechanism in MCM. MCM is used to establish a static association between events and rule versions, while DRWM is used to achieve dynamic parallel control of old and new rules during the rule evolution window.

[0235] Step 5: Implement rule linkage and status synchronization through the data platform;

[0236] Please see Figure 8 The data platform is responsible for the unified aggregation, consistency verification, and global state coordination of the rule execution results uploaded by each business node. It does not directly participate in the execution of rule logic, thereby achieving data collaboration and distributed state consistency among multiple business nodes.

[0237] S500: The data platform receives the rule execution results;

[0238] Specifically, in one implementation, after the rule engine completes rule calculation, it sends the rule execution result, status events, and node status information to a message queue. Subsequently, the data platform subscribes to the corresponding Topic and receives the rule execution result. The rule execution result includes an event identifier, rule number, rule version number, node number, execution status, execution result, and execution time. In one implementation, the data platform establishes an event index relationship based on the rule version number and event identifier for subsequent status synchronization, event tracing, and compensation recovery.

[0239] Furthermore, in one embodiment, the data platform establishes a unified event access gateway to perform unified format conversion, protocol parsing, and event standardization processing on data uploaded from different business nodes. The protocols include HTTP, MQTT, WebSocket, TCP, and Kafka message protocols. The system achieves unified access to multi-protocol data through a unified event model.

[0240] S510: Performs data aggregation and state synchronization;

[0241] Specifically, in one embodiment, the data platform aggregates data uploaded from different business nodes and updates the business status synchronously; the data aggregation includes rule execution result aggregation; device status aggregation; node running status aggregation; event statistical analysis; and message consumption status statistics. In one embodiment, the system establishes aggregation dimensions based on rule number, rule version number, device identifier, and business node number, and generates a unified business status view.

[0242] Specifically, in one implementation, when the system detects a change in node status, it automatically sends a status synchronization message to the corresponding service node, thereby ensuring data consistency among multiple nodes. Simultaneously, the system employs incremental synchronization, synchronizing only the changed states, thus reducing network transmission pressure and system resource consumption.

[0243] S520: Create a rule result table and an event log table;

[0244] Specifically, in one embodiment, the system establishes a rule result table and an event log table. The rule result table stores rule execution results, rule version numbers, execution nodes, business status, execution time, execution duration, and exception states. The event log table records raw event data, message topics, rule execution processes, node status, exception information, message consumption offsets, and compensation execution records. Further, in one embodiment, the system establishes a composite index based on event timestamps, rule version numbers, and event identifiers to improve historical event retrieval efficiency. In one embodiment, the event log is written to the event storage center in chronological order and supports event playback, historical tracing, and event reconstruction.

[0245] S530: Business node synchronization execution status;

[0246] Specifically, in one implementation, business nodes synchronize their execution status based on rule version information; the execution status includes the current rule version, message consumption offset, node online status, rule cache status, number of abnormal events, and current task queue status. The data platform generates a unified status view based on the node status and verifies the consistency of rule versions between different nodes.

[0247] In one implementation, when a node rule version is detected to be lagging behind the currently effective version, the system automatically triggers a rule synchronization process. This process includes fetching the latest rule version, reloading the rule cache, rebuilding the rule condition tree, updating the local rule status, and synchronizing the rule version number. In another implementation, after completing rule synchronization, the node returns a rule synchronization confirmation message to the data platform.

[0248] S540: Trigger consistency compensation process;

[0249] Specifically, in one implementation, when the system detects inconsistencies in node rule versions; message processing failures; abnormal state synchronization; node offline; abnormal message consumption offsets; invalid rule caches; duplicate message consumption; or messages remaining unacknowledged for an extended period, the system automatically triggers a consistency compensation process. The consistency compensation process includes: resynchronizing rule versions; reloading the rule cache; resubscribing to message topics; re-executing rule logic; resynchronizing node state data; re-consuming failed messages; performing historical event compensation recalculation; repairing message consumption offsets; and updating business state data. Based on the rule version information and time window corresponding to the abnormal event, the system reads the corresponding historical event from the event log center and re-executes the rule logic.

[0250] In one implementation, the system employs an incremental compensation mechanism, performing compensation recalculation only on affected events, thereby reducing system resource consumption. After compensation is completed, the system re-verifies node state consistency and updates the node state table.

[0251] S550: Implements data consistency control;

[0252] Specifically, in one implementation, the data platform achieves data consistency control among multiple business nodes through event logs, rule version control, and compensation mechanisms. In another implementation, the system establishes a consistency status detection model for periodic checks; the checks include rule version consistency, node status consistency, message consumption status consistency, data cache consistency, and business data consistency.

[0253] Furthermore, in one embodiment, when all business nodes meet the requirements of consistent rule versions, consistent message consumption offsets, consistent node states, and consistent business states, the system determines that the current distributed system has reached an eventual consistent state. In one embodiment, the data platform simultaneously supports cross-node event collaboration, distributed state recovery, and dynamic rule migration control, thereby improving the system's data reliability, fault tolerance, and operational stability in scenarios of dynamic rule evolution.

[0254] This invention provides a message-driven data platform consistency control method based on low-code rule evolution. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. A message-driven data platform consistency control method based on low-code rule evolution, characterized in that, Includes the following steps: Step 1: Build a low-code rules model; Step 2: Establish a rule version evolution mechanism; Step 3: Implement rule-based event flow based on a message-driven architecture; Step 4: Construct a rule consistency control mechanism; Step 5: Aggregate rule execution results and synchronize distributed states through the data platform.

2. The method according to claim 1, characterized in that, Step 1 includes the following steps: Step S100: Build the rule model: Create a rule model in the low-code platform and configure the basic attributes of the rules and the rule editing functions; Step S110: Configure rule conditions and execution actions: Configure rule trigger conditions, execution actions, and event relationships through visual forms, drag-and-drop components, or DSL expressions; Step S120: Configure rule events: Configure rule trigger events, event types, and event flow relationships based on the target business scenario; Step S130: Configure rule variables: Configure rule variables in the rule mapping unit to establish the mapping relationship between rule fields and business data fields; Step S140: Generate rule metadata: Convert the rule logic into structured rule metadata and store it uniformly; Step S150: Establish the rule-based state-space model RSSM; The low-code rules platform generates rule status objects based on the rule schema structure, rule conditions and constraints, rule version number, and field mapping relationships, and calculates the rule status index. ,in As weight, Represents the schema structure of the rules; Indicates rule conditions and constraints; Indicates the rule version number; This represents the field mapping relationship, where i takes values ​​from 1 to n, and n is a positive integer. Feature values ​​are calculated based on the rule structure, rule conditions, rule version, and field mapping. The weighted values ​​are then used to obtain the rule state index, and a state space is established according to the rule state index.

3. The method according to claim 2, characterized in that, In step S100, the basic attributes of a rule include rule name, rule number, rule type, priority, and effective status; the rule editing function includes adding, modifying, deleting, querying, and starting / stopping rules.

4. The method according to claim 3, characterized in that, In step S110, the rule conditions include conditional expressions, logical operators, and trigger thresholds; the execution actions include any one of message push, status update, device control, data calculation, and event forwarding.

5. The method according to claim 4, characterized in that, In step S130, the rule variables include variable name, variable type, event topic, field key, and data source identifier; among them, the variable type can be any of the following: integer, floating point, character, or JSON object.

6. The method according to claim 5, characterized in that, Step 2 includes the following steps: Step S200: Establish a rule version number management mechanism; Step S210: Record the rule creation time, effective time, and version change records; Step S220: Implement hot rule updates based on the rule center; Step S230: The business node subscribes to the rule change event and synchronizes the latest rule version; Step S240: Implement rule canary release and version switching based on rule version information; Step S250: When a rule is abnormal, perform a rule rollback operation, which includes: when the rule center detects that the new rule version has an execution abnormality, data conflict or business failure, it automatically restores to the previous stable rule version and reloads the historical rule cache; Step S260: Establish a rule-based evolution model and calculate the degree of evolution. When the degree of evolution If the value exceeds the evolution judgment value corresponding to the current rule state, a new rule version is generated; the rule evolution result is calculated based on the change in rule state. ,in , , These are weighting coefficients; Represents the regular evolution function; This represents the set of target rule states after a single evolution, i.e., the rule states corresponding to the next time step. Indicates the current rule status; Indicates the amount of change in the rule structure; Indicates the amount of change in the rule conditions; This indicates the amount of change in the field mapping.

7. The method according to claim 6, characterized in that, In step S200, a unique rule identifier RuleID is generated for each rule, and a rule version chain is established based on the version number Version. The same rule identifier corresponds to two or more historical rule versions. The rule version number is incremented in chronological order to distinguish different rule states in the rule evolution process.

8. The method according to claim 7, characterized in that, In step S220, after detecting a change in rule configuration, the rule center automatically generates a new rule version and loads the new rule into the rule cache. Before the new rule takes effect, the original rule continues to process the current business events, thereby achieving uninterrupted hot updates of rules.

9. The method according to claim 8, characterized in that, In step S230, the business node listens for rule update events by subscribing to the rule change Topic; upon receiving a rule update notification, the business node retrieves the corresponding rule content based on the rule number and version number, and updates the local rule cache. In step S240, the canary release process gradually enables the new rule version according to device type, service group, tenant identifier, or node range; a canary evolution control model (GECM) is established, and the canary state is defined. Represented as: The rules center calculates the gray-scale release ratio of the current new rule version based on the gray-scale status. ;in This indicates the canary release ratio of the current new rule version; Indicates the grayscale node coverage rate; Indicates the coverage rate of grayscale users; Indicates the grayscale flow ratio; Indicates the time window factor; These are the weighting coefficients, and ;when If the threshold for gray-scale release is exceeded, the release scope of the new rule version will be expanded; otherwise, the current rule version will continue to operate.

10. The method according to claim 9, characterized in that, Step 3 includes the following steps: Step S300: A business event is generated by the business system or terminal device; Step S310: The message producer sends the business event to the message queue, and encapsulates the event identifier, rule number, rule version number, event timestamp and business context information. Step S320: The message queue completes message classification and routing based on the event Topic, business tag, or rule type, and writes the messages to the corresponding message partitions in the order of the events, thus completing message routing and distribution; Step S330: The rule engine subscribes to event messages and executes rule logic. That is, after receiving an event message, the rule engine loads the corresponding rule according to the rule version information and executes rule matching, condition judgment and action scheduling according to the rule priority. Step S340: The rule execution result is written to the event log and synchronized to the data platform; Step S350: Establish a message consistency model. The rule engine calculates the message consistency identifier based on business event data and rule version. A one-to-one correspondence between messages and rule versions is established based on the message consistency identifier (CID); whereby... Represents a hash function; The business events in step S300 include any one of the following: device status events, user operation events, alarm events, control events, and data acquisition events; The message queue in step S320 includes RabbitMQ, Kafka, or other message middleware that supports the publish-subscribe pattern; In step S340, the rule execution log includes the event identifier, rule version number, execution status, execution result, exception information, and execution time; Step 4 includes the following steps: Step S400: Establish a rule version binding mechanism. The system calls the corresponding rule instance according to the rule version information to ensure the consistency of the correspondence between historical events and rule versions. Step S410: Establish a message idempotency verification mechanism. When a duplicate event is detected, the system automatically intercepts duplicate execution requests. Step S420: Establish the Rule Conflict Evaluation Model (RCEM), and the rule engine calculates the rule conflict value. Select a conflict handling strategy based on the rule conflict value. Execute conflict resolution if necessary, otherwise execute directly; where , , Indicates the weighting coefficient; This indicates a conflict in the rules; Indicates a conflict between rules and actions; This indicates a rule priority conflict; T represents the system's preset rule conflict threshold. Step S430: Establish an event tracing and compensation recalculation mechanism. When the rule version changes or a node execution is abnormal, the data platform performs event replay, historical tracing and compensation recalculation based on the event log. Step S440: Establish an eventual consistency control mechanism, enabling the system to achieve eventual data consistency control in a distributed environment through rule version binding mechanism, message idempotency verification mechanism, event tracing mechanism, and compensation recalculation mechanism; Step S450: Establish a dual-rule window model to enable parallel operation of old and new rules and state transition control during rule switching; In step S400, when a business event executes a rule, it binds the corresponding rule version information. The event data includes the event identifier, rule number, rule version number, and timestamp. In step S410, the system generates an idempotent verification key using the event unique identifier and rule version number, and implements message deduplication control through Redis caching or database unique indexing. In step S420, rule conflict detection includes rule condition conflict detection, rule action conflict detection, and rule priority conflict detection; rule compatibility verification includes rule field compatibility verification, rule structure compatibility verification, and rule version dependency verification. The compensation recalculation process in step S430 includes obtaining the abnormal event log, loading the corresponding rule version, re-executing the rule logic, updating the business status data, and synchronizing the compensation results; all business events are written to the event storage center in chronological order, and the original event data, rule version information, and execution results are retained; The consistency control in step S440 includes node state consistency verification, message processing result consistency verification, rule version consistency verification, and cache state consistency verification. In step S450, a dual-rule window is created. When the event satisfies: The rules engine performs calculations based on the event timestamp. ， in Indicates timestamp as The rule engine selects the rule version to execute at any time; This indicates the time point that marks the boundary between old and new rules within the rules window; Indicates the start time of the rules window; Indicates the end time of the rules window; The rule engine calls the corresponding rule version to complete event parsing based on the calculation results; when the event time exceeds the window end time... At that time, only the new rule is invoked. Execute parsing; Step 5 includes the following steps: Step S500: The data platform receives rule execution results and status events: It receives rule execution results, device status data, and business event logs through message subscription and establishes a unified event access channel; Step S510: Aggregate data and synchronize status for the rule results; Step S520: Create the rule result table and event log table; Step S530: Business nodes synchronize execution status according to rule version information, that is, each business node periodically reports local rule version information and execution status to the data platform; the data platform generates a unified status view based on the node status; Step S540: When a node is in an abnormal state, the consistency compensation process is triggered. That is, when the system detects that the node rule version is inconsistent, message processing fails, or state synchronization is abnormal, the consistency compensation process is automatically triggered. Step S550: Implement data consistency control among multiple business nodes through the data middle platform. That is, the data middle platform performs unified verification and consistency control on the data status of multiple business nodes based on the rule version binding mechanism, event tracing mechanism and compensation mechanism. In step S510, data aggregation includes rule execution result aggregation, device status aggregation, event statistical analysis, and rule hit statistics; status synchronization includes node status synchronization, rule status synchronization, and cache status synchronization. In step S520, the rule result table is used to store the rule execution result, rule version number and business status information; the event log table is used to record the original event data, event processing process and exception information.

Images