Data distribution system and method based on business model, equipment and storage medium

Abstract

The invention discloses a data distribution system and method based on a service model, equipment and a storage medium, and relates to the technical field of communication, a service model containing data attribute characteristics, a data source mapping relation and an operation rule is constructed through a configuration platform, and the service model is issued to a target edge node for storage; collecting target business data from a central database based on the business model, screening and cleaning the target business data, packaging the target business data into standard format data, and publishing the standard format data to an associated target theme through a message bus; the edge node subscribes to the target theme to receive data, analyzes according to a locally stored service model and generates a local database operation instruction for execution, also supports a service model update synchronization and grading retry mechanism, realizes service logic and data transmission decoupling, improves distribution flexibility, efficiency and reliability, and adapts to a multi-edge-node distributed scene.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to data distribution systems, methods, devices and storage media based on business models. Background Technology

[0002] In distributed business systems, such as railway passenger transport, chain retail, and IoT platforms, the core requirement is for the central node to synchronize business data (user information, scheduling instructions, promotional strategies, etc.) to multiple edge nodes (stations, stores, edge gateways).

[0003] In related technologies, when designing distributed business system solutions, direct database connection synchronization requires exposing the central database, posing serious security risks. Furthermore, the central database's connection count and performance bottlenecks limit system scalability. Point-to-point API calls require developing customized interfaces for each edge node, resulting in extensive development and high coupling. When business data formats change or nodes are added or removed, both the central database and all edge nodes need to be synchronously modified and upgraded, leading to extremely high maintenance costs. Full data table synchronization, achieved through database replication or ETL tools, transmits a large amount of data unnecessary for edge nodes, wasting network bandwidth and storage space, and making it impossible to process data according to business logic. The problem with these solutions is the tight coupling between business logic and data transmission logic. Any minor business change requires modification of transmission-related code, interfaces, or configurations, leading to system rigidity, high upgrade and maintenance costs, and difficulty in adapting to scenarios requiring flexible addition or removal of edge nodes and rapid business iteration. Summary of the Invention

[0004] The data distribution system, method, device, and storage medium based on a business model provided in this application are configured to build a business model on a platform and distribute it to storage. Then, based on the model, target data from the central database is collected and encapsulated into a standard format. The data is then published to the associated target topic via a message bus. After the edge nodes subscribe to and receive the data, they parse it according to the local model and generate database operation instructions for execution, thus completing the distribution. This achieves decoupling of business and transmission, eliminates the need for customized interfaces to support flexible distribution, reduces development and maintenance costs, and improves data distribution efficiency and reliability.

[0005] In a first aspect, embodiments of this application provide a data distribution method based on a business model, applied to a server, the method comprising: A business model is built by configuring the platform, and the built business model is sent to the target edge node for storage. Upon receiving the storage confirmation message of the business model returned by the target edge node, the synchronous storage of the business model is completed. Based on the data source mapping relationship of the business model, query instructions are generated periodically. Target business data is collected from the central database based on the query instructions, and data filtering and data completion processing are performed on the target business data. The processed target business data is then encapsulated into business model format data that the business model can recognize. The business model format data is published to the target topic associated with the business model via a message bus, so that the target edge node subscribes to the corresponding target topic and parses the business model format data based on the stored business model to generate local operation instructions.

[0006] Furthermore, the business model is used to define the attribute characteristics, data source mapping relationships, and data operation rules of the target business data; The process of building a business model through a configuration platform includes: The business model identifier, attribute list, data source table, and field mapping relationship are defined through the configuration interface; the attribute list includes the name, data type, and description information of the target business data, and the field mapping relationship is used to associate the attribute list of the business model with the fields of the data source table; The configuration interface defines data operation rules, which specify the local database operation type when the business data changes.

[0007] Furthermore, the step of collecting target business data from the central database based on the query instruction includes: According to a preset period or triggering condition, a query instruction for the target business data is generated based on the data source mapping relationship of the business model; The system executes a query command for the target business data to retrieve the target business data from the central database, and then filters, cleans, and structures the target business data according to the attribute characteristics of the business model. The processed target business data is encapsulated into business model format data in a preset format, wherein the business model format data includes a business model identifier, data content, and data change identifier.

[0008] Furthermore, the naming rules for the target topic are associated with the business model identifier and the target edge node identifier, and a one-to-one distribution and a one-to-many distribution are adopted; The step of publishing the business model format data to the target topic associated with the business model via the message bus includes: The target edge node identifier is determined based on the distribution requirements, and the target topic is generated by combining the business model identifier; The business model format data is published to the target topic, and the business model format data is transmitted to the target edge node that subscribes to the target topic through the routing configuration of the message bus.

[0009] Furthermore, the target edge node subscribes to the corresponding target topic and parses the business model format data based on the stored business model to generate local operation instructions, including: The target edge node subscribes to the target topic and receives the business model format data; Based on the business model stored in the target edge node, the business model format data is parsed, and operation instructions for the local database of the target edge node are generated and executed to complete the distribution of the target business data; The step of parsing the business model format data based on the business model stored on the target edge node, generating and executing operation instructions for the local database of the target edge node, includes: Parse the business model identifier in the business model format data, and match the corresponding business model pre-stored by the target edge node according to the business model identifier; Based on the attribute features and field mapping relationship of the business model, the formatted data content of the business model is parsed. Based on the data change identifier and the data operation rules defined in the business model, local database operation instructions for the target edge node are generated.

[0010] Furthermore, after the distribution of the target business data is completed, the process also includes: In the event of a change in the business model, the business model update notification is pushed to all target edge nodes that have subscribed to the target topic associated with the business model via the message bus. The target edge nodes receive the business model update notification, obtain the updated business model, and replace the old business model in the local database.

[0011] Furthermore, after the distribution of the target business data is completed, the process also includes: Record the transmission status of the business model format data, the reception status of the target edge node, the execution result of the local database operation command, and the QoS level corresponding to the business model format data; The QoS level and retry parameter mapping relationship corresponding to different business model format data scenarios is preset, and the retry parameters include retry number threshold, retry time interval and retry timeout threshold; Based on the QoS level configured in the business model associated with the business model format data, the corresponding retry parameters are matched. If the data transmission failure of the business model format or the abnormal execution of the instruction is detected, a tiered retry is triggered according to the matched retry parameters; For business model format data that fails to complete a tiered retry, an anomaly marker is set and stored in the anomaly data queue of the local database for manual intervention.

[0012] In a second aspect, embodiments of this application provide a data distribution system based on a business model, including: The model configuration module constructs a business model through the configuration platform, sends the constructed business model to the target edge node for storage, and completes the synchronous storage of the business model upon receiving a storage confirmation message for the business model returned by the target edge node. The acquisition and encapsulation module is used to periodically generate query instructions based on the data source mapping relationship of the business model, acquire target business data from the central database based on the query instructions, perform data filtering and data completion processing on the target business data, and encapsulate the processed target business data into business model format data that the business model can recognize. The message publishing module is used to publish the business model format data to the target topic associated with the business model through the message bus, so that the target edge node subscribes to the corresponding target topic, and parses the business model format data based on the stored business model to generate local operation instructions.

[0013] In a third aspect, embodiments of this application provide an electronic device, including: a memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the business model-based data distribution method as described in the first aspect.

[0014] In a fourth aspect, embodiments of this application provide a storage medium for storing computer-executable instructions, which, when executed by a computer processor, are used to perform the data distribution method based on a business model as described in the first aspect.

[0015] This application's embodiments achieve deep decoupling of business logic and data transmission through standardized business model construction. Because the business model clearly defines data attributes, data source mapping relationships, and operational rules, when business requirements change or the database table structure is adjusted, only model parameters need to be modified on the configuration platform, without altering the data distribution and edge node receiving programs, reducing development and maintenance costs. Due to the adoption of a message bus and topic routing mechanism, target topics are strongly associated with business model identifiers and edge node identifiers, supporting one-to-many broadcasting and one-to-one precise delivery. When adding edge nodes, only the corresponding topic needs to be subscribed to; the central system requires no adjustments, significantly improving system scalability. Because the central data is filtered, cleaned, and structured based on the business model, only the data required by the edge nodes is synchronized, avoiding resource waste caused by full data transmission and effectively saving network bandwidth and storage space. The design of a tiered retry and exception handling mechanism, combined with QoS level matching corresponding retry parameters, triggers retries for data that fails to transmit or executes abnormally. Failed retry data is stored in an exception queue for manual processing, improving the reliability and integrity of data distribution, ensuring accurate and efficient data synchronization at edge nodes, and adapting to the central-edge data distribution needs of multiple scenarios such as railway passenger transport and chain retail. Attached Figure Description

[0016] Figure 1 This is a flowchart of a data distribution method based on a business model provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the business model construction provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the data acquisition and encapsulation process of the business model provided in this application embodiment; Figure 4 This is a flowchart of target topic generation and message publishing provided in an embodiment of this application; Figure 5 This is a flowchart of the target edge node subscription provided in the embodiments of this application; Figure 6 This is a flowchart of the target edge node parsing and execution provided in the embodiments of this application; Figure 7 This is a flowchart of QoS classification retry and exception handling provided in the embodiments of this application; Figure 8 This is a structural diagram of the data distribution system based on a business model provided in the embodiments of this application; Figure 9 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but additional steps not included in the drawings may also be present. The above processes can correspond to methods, functions, procedures, subroutines, subroutines, etc.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship. The data distribution system, method, equipment, and storage medium based on the business model relate to the field of communication technology and are applicable to data synchronization scenarios from a central node to multiple edge nodes in distributed business systems, such as railway passenger transport systems (center-station), chain retail systems (headquarters-store), and IoT platforms (cloud-edge gateway). By using the business model, business logic and data transmission are decoupled, improving the flexibility, efficiency, and reliability of data distribution. In distributed business systems, synchronizing business data from a central node to multiple edge nodes is a core requirement, but traditional solutions have significant drawbacks. Direct database connection synchronization exposes the central database, posing serious security risks, and the central database's connection limit and performance bottleneck restrict system scalability. Point-to-point API calls require developing customized interfaces for each edge node, resulting in extensive development and high coupling. When business changes occur, both the central and edge nodes need to be modified and upgraded simultaneously, leading to extremely high maintenance costs. Full data table synchronization transmits a large amount of data that edge nodes do not need, wasting network bandwidth and storage space, and making it impossible to process data according to business logic. These core problems stem from the tight coupling between business logic and data transmission logic. Any minor business change requires modification of transmission-related code, interfaces, or configurations, leading to system rigidity, high upgrade and maintenance costs, and difficulty in adapting to scenarios requiring flexible addition or removal of edge nodes and rapid business iteration. Figure 1 This is a flowchart of the data distribution method based on a business model provided in the embodiments of this application. Please refer to [link / reference]. Figure 1 The data distribution method of this application includes business model construction and synchronization, target data collection and encapsulation, and message publish-subscribe parsing steps, forming a closed loop of model definition, data processing, and distribution execution, specifically including: Step 101: Build a business model through the configuration platform, send the built business model to the target edge node for storage, and complete the synchronous storage of the business model upon receiving the storage confirmation message of the business model returned by the target edge node.

[0019] In one embodiment, a business model is built through a configuration platform and sent to the target edge node storage. Synchronization is completed upon receiving a storage confirmation message. The configuration platform provides a visual interface, allowing administrators to define business model elements—including data attribute characteristics, data source mapping relationships, and data operation rules—without writing code, through drag-and-drop and check-and-click methods. For example, when building a user model, an attribute list (user ID, name, type, etc.) can be defined, mapping to the user table in the central database and field relationships can be established, and the local database operation type for data changes can be specified (INSERT command for adding, UPDATE command for changing).

[0020] Once the business model is built, the server pushes it to the target edge nodes through the Tunnel service and message bus. The Tunnel service provides an encrypted transmission channel for synchronous business model push, supporting both precise single-node push and batch push to multiple nodes. After receiving the business model, the target edge node stores it in a dedicated table in its local database and returns a storage confirmation message through the Tunnel service, which includes the model identifier and storage status.

[0021] After the server receives confirmation messages from all target edge nodes, it records the business model synchronization status as complete. If no confirmation is received from some nodes within a timeout period, a retry mechanism is triggered (3 retries by default, with a 5-second interval). If the retry fails, an exception is marked and the administrator is notified to ensure the integrity of the business model synchronization.

[0022] Step 102: Based on the data source mapping relationship of the business model, periodically generate query instructions, collect target business data from the central database based on the query instructions, perform data filtering and data completion processing on the target business data, and encapsulate the processed target business data into business model format data recognized by the business model.

[0023] In one embodiment, based on the data source mapping relationship of the business model, query instructions are generated periodically, target data from the central database is collected and processed and packaged into a standard format to ensure data accuracy and compatibility. The server automatically generates SQL query commands based on preset periods (configurable from 1 minute to 24 hours) or trigger conditions, such as changes in central database data, according to the data source tables and field mapping relationships of the business model. For example, the query command for the user model can accurately filter core fields such as user ID and name, rather than the entire user table, avoiding the waste of resources caused by full data collection. After retrieving target data from the central database by executing a query command, the data is filtered (removing unnecessary fields from target edge nodes), cleaned (removing null values ​​and outliers), and completed (filling in default values) according to the attribute characteristics of the business model. For example, internal management fields such as creator and approval time are filtered out, and the default user type is completed to "ordinary user" to ensure that the data meets the usage requirements of the target edge node.

[0024] The processed data is encapsulated into business model format data, with a unified JSON structure, containing business model identifiers such as UserModel, data content (business data in key-value pair form), and data change identifiers (added / modified / deleted), ensuring that the target edge nodes can be identified and parsed based on the business model without needing to adapt to different data formats.

[0025] Step 103: Publish the business model format data to the target topic associated with the business model via the message bus, so that the target edge node subscribes to the corresponding target topic, and parses the business model format data based on the stored business model to generate local operation instructions.

[0026] In one embodiment, standard format data is published to the target topic through a message bus combined with the Tunnel service. After the target edge node subscribes, it parses the data based on its local business model and generates database operation instructions for execution, thus completing the data distribution.

[0027] The target topic naming rules are strongly associated with the business model identifier and edge node identifier, with the format "data / sync / {NodeID} / {ModelID}". It supports one-to-many distribution (e.g., "data / sync / all / UserModel" for all nodes) and one-to-one precise distribution (e.g., "data / sync / StationA / UserModel" for station A), meeting the needs of different distribution scenarios.

[0028] The server publishes business model format data to the corresponding target topic. The message bus, such as MQTT Broker, based on topic routing configuration, passes the message to the Tunnel service. The Tunnel service, as a dedicated data transmission channel, uses encryption, fragmentation, and retransmission mechanisms to push messages securely and efficiently to edge nodes that have subscribed to the topic. It supports millions of concurrent subscriptions, eliminates central performance bottlenecks, and solves the problems of high pressure on the central hub and insecure transmission in traditional point-to-point architectures.

[0029] After receiving data through the local Tunnel client, the edge node parses the data content based on the business model of local storage, generates SQL operation instructions (INSERT / UPDATE / DELETE) for the local database according to the data change identifier and preset operation rules, and executes them to complete data synchronization. The entire process does not require manual intervention and achieves automated distribution.

[0030] Figure 1 The model building, data processing, and distribution execution process decouples business operations from transmission. Through visualized model synchronization, on-demand data collection, and topic subscription distribution, it avoids the direct connection security risks, interface coupling problems, and waste of full transmission inherent in traditional solutions. Standardized processes ensure consistent collaboration between central and edge nodes, and new nodes or business changes do not require significant modifications, improving deployment flexibility and iteration efficiency, and providing an efficient and reliable distribution framework for large-scale distributed scenarios.

[0031] Figure 2 This is a flowchart illustrating the business model construction provided in this application embodiment. Please refer to it. Figure 2 The business model construction process involves decoupling business processes from transmission. Model elements are defined through visual configuration, and the specific implementation includes: Step 201: Define the business model identifier, attribute list, data source table, and field mapping relationship through the configuration interface; the attribute list includes the name, data type, and description information of the target business data, and the field mapping relationship is used to associate the attribute list of the business model with the fields of the data source table.

[0032] In one embodiment, a configuration interface defines business model identifiers, attribute lists, data source tables, and field mapping relationships, clearly defining the core characteristics and source associations of the data. The model identifier is a globally unique string identifier, such as "ProductModel" and "MemberModel," used for model matching between the central server and edge nodes to avoid confusion between different models, ensure the accuracy of data distribution, and also serve as one of the identifiers used by the Tunnel service to identify data ownership.

[0033] The attribute list defines the name, data type, and description of the target business data. For example, the attributes of a product model include product ID (string), product name (string), selling price (decimal), and inventory (int). The description information is used by administrators to understand the meaning of the attributes and improve the readability and maintainability of the model.

[0034] The data source mapping specifies the central database table corresponding to the model, such as "product_table" for "product model", and establishes the mapping relationship between model attributes and table fields, such as "prod_id" for product ID and "price" for price. It supports multi-table association mapping (associating fields of multiple tables through primary keys) to meet the data collection needs of complex business scenarios.

[0035] The configuration platform verifies the validity of the mapping relationship in real time, such as checking whether the data source table exists and whether the field types match. For example, if the model attribute is of type int, the mapped field cannot be of type varchar. Only after the verification passes can the next step be taken to avoid data collection failure due to configuration errors. Step 202: Define data operation rules through the configuration interface. The data operation rules are used to specify the local database operation type corresponding to the change of the business data.

[0036] In one embodiment, data operation rules are defined through a configuration interface, specifying the corresponding local database operation type when business data changes, ensuring that edge nodes correctly perform data synchronization. Optionally, for each data change identifier (add / modify / delete), the corresponding database operation type is specified, such as configuring "add identifier → INSERT command", "modify identifier → UPDATE command (based on primary key update)" and "delete identifier → DELETE command (based on primary key deletion)", ensuring that edge nodes can generate correct operation commands according to the rules.

[0037] It supports custom rule configuration for complex business scenarios. For example, when the price of a product changes, in addition to generating an UPDATE command to update the price field, it also records a change log (automatically generating an INSERT command in the log table); when the inventory is below the threshold, it triggers an early warning logic (calling the local early warning interface of the edge node) to meet diverse business needs.

[0038] Once configured, the operation rules are bound to other information in the business model and stored. After being synchronized to the edge nodes, they are stored locally along with the business model, serving as the basis for generating operation instructions during data parsing and ensuring consistency in rule execution. At the same time, rule-related metadata is synchronized through the Tunnel service to ensure consistency between the rules in the center and the edge nodes.

[0039] Figure 2 The model building process is key to decoupling. Visual configuration lowers the technical threshold, multi-table association mapping adapts to complex business, and standardized configuration of attribute definition, field mapping and operation rules allows business logic changes to be adjusted only by adjusting the model without modifying upstream and downstream code. Real-time verification avoids configuration errors, and custom rules support diverse needs, ensuring model consistency and scalability. It solves the problems of high business change costs and difficult adaptation in traditional solutions from the source.

[0040] Figure 3 This is a flowchart illustrating the data acquisition and encapsulation process of the business model provided in this application embodiment. Please refer to [link / reference]. Figure 3 Through the process of target data collection, processing, and packaging, data quality and standardization are ensured, specifically including: Step 301: Generate a query instruction for the target business data according to the data source mapping relationship of the business model, based on a preset period or triggering condition.

[0041] In one embodiment, a query instruction for the target data is generated according to the data source mapping relationship of the business model, based on a preset period or triggering conditions, to ensure the accuracy and timeliness of data collection.

[0042] The triggering mechanism supports two triggering methods: one is periodic triggering (administrators set the collection period in the configuration platform, such as 5 minutes / time), which is suitable for scenarios with frequent data changes, such as product inventory data; the other is event triggering (listening to the data change log of the central database, such as Binlog, and triggering collection immediately when data changes), which is suitable for scenarios with high real-time requirements, such as transaction order data, to meet different real-time needs.

[0043] Based on the data source tables, field mapping relationships, and filtering conditions of the business model, such as only collecting product data with a valid status, optimized SQL query instructions are automatically generated to avoid full table scans. For example, the query instruction for the "product model" is "SELECT prod_id, prod_name, price, stock FROM product_table WHERE status = 1", which only collects core fields and valid data, improving query efficiency. Once the query command for the same model is generated, it is cached locally on the server and reused directly the next time it is triggered. Only dynamic parameters such as timestamp and filtering conditions are updated. For example, when triggered periodically, the query time range is updated, which improves the efficiency of command generation and reduces redundant calculations.

[0044] Step 302: Execute the query command for the target business data to obtain the target business data from the central database, and filter, clean and structure the target business data according to the attribute characteristics of the business model.

[0045] In one embodiment, a query command is executed to retrieve target data from the central database, and the data is then filtered, cleaned, and structured based on the attributes and characteristics of the business model to improve data quality.

[0046] The server executes query commands through a database connection pool. The maximum number of connections in the connection pool is configurable (default 100) to avoid data collection failures caused by connection overflow. It supports mainstream databases such as MySQL, Oracle, and SQL Server, improving system compatibility.

[0047] Filter fields according to the attribute list of the business model, and retain only the data required by the edge nodes. For example, the "product model" only retains 4 core fields, and filters fields used internally by the center such as "creator", "approval status" and "deletion mark" to reduce the amount of data transmitted and reduce the transmission pressure on the Tunnel service.

[0048] Handle outliers and missing values ​​in the data, such as correcting records with negative selling prices to 0, filling missing inventory values ​​with 0, and converting string-type dates to standard formats to ensure that the data conforms to the field constraints of the edge node database (non-null, numerical range, format requirements, etc.) and avoid execution errors.

[0049] Convert row data from relational databases into key-value pair structured data. For example, convert query results into “{"prod_id":"P001","prod_name":"mobile","price":3999","stock":100}”, which facilitates subsequent encapsulation into a standard format, improves parsing efficiency, and enhances the transmission efficiency of Tunnel services and the parsing efficiency of edge nodes.

[0050] Step 303: Encapsulate the processed target business data into business model format data in a preset format, wherein the business model format data includes a business model identifier, data content, and data change identifier.

[0051] In one embodiment, the processed target data is encapsulated into a business model format data in a preset format to ensure that edge nodes can identify and parse it based on the local model and adapt to the transmission requirements of the Tunnel service.

[0052] It is uniformly encapsulated in JSON format and contains three core fields. Optionally, ModelID is a business model identifier, such as "ProductModel", used by edge nodes to match local models, and also serves as key information for the Tunnel service to identify data ownership, ensuring parsing accuracy; DataContent is the structured business data (a collection of key-value pairs) that maintains a one-to-one correspondence with business model attributes; ChangeType is a data change identifier ("INSERT", "UPDATE", "DELETE") used to trigger the corresponding operation rules of edge nodes.

[0053] The encapsulated data supports Gzip compression, reducing the bandwidth usage of the Tunnel service; sensitive data, such as user mobile phone numbers and member passwords, supports AES encryption. The encryption key is pre-negotiated and configured by the central and edge nodes through the Tunnel service to ensure data transmission security and prevent data leakage.

[0054] Figure 3 The data acquisition and packaging process focuses on data quality and standardization. The periodic / event dual trigger mechanism adapts to different real-time requirements. On-demand filtering, cleaning and completion reduce transmission redundancy. Standard JSON encapsulation ensures multi-node compatibility. Compression and encryption balance efficiency and security. Instruction caching improves execution performance. It effectively solves the pain points of traditional solutions such as poor data quality, inconsistent formats and serious bandwidth waste.

[0055] Figure 4 This is a flowchart of the target topic generation and message publishing process provided in the embodiments of this application. Please refer to [link / reference]. Figure 4 Target topic generation and message publishing are crucial steps in achieving precise distribution and high scalability, specifically including: In one embodiment, the distribution scope (one-to-many / one-to-one) is determined based on business needs, and the target edge node identifier is clearly defined to provide a basis for topic generation and tunnel routing. When configuring the platform to publish data, the administrator selects the distribution scope, supporting three modes: "all nodes," "specified node group," and "single node." For example, when publishing product data, "all nodes" can be selected to target all stores; when publishing station-specific dispatch instructions, "single node" can be selected to target only the target station, meeting the needs of different distribution scenarios.

[0056] The system maintains a list of edge node identifiers, such as store IDs and station numbers, and supports node group management, such as grouping by region into "North Region" and "South Region". When a specific node group is selected, all node identifiers within the group are automatically associated, reducing the workload of administrators and improving distribution efficiency. At the same time, the node identifiers serve as the basis for Tunnel service routing, ensuring accurate data delivery.

[0057] The system verifies the validity of the target node identifier (whether it has registered and connected to the system and completed the Tunnel service access). Invalid identifiers are automatically filtered and the administrator is notified to prevent messages from being published to non-existent nodes and ensure accurate distribution. Step 401: Determine the target edge node identifier based on the distribution requirements, and generate the target topic by combining it with the business model identifier.

[0058] In one embodiment, the target topic is generated by combining the business model identifier and the target node identifier according to a unified rule, ensuring the uniqueness and readability of the topic, while providing a clear basis for Tunnel routing.

[0059] The topic naming rules adopt a hierarchical naming format, with the core format being "data / sync / {TargetType} / {TargetValue} / {ModelID}", where TargetType is the target type, all represents all nodes, group represents a node group, and node represents a single node; TargetValue is the target value, all corresponds to all, node group corresponds to the group ID, and single node corresponds to the node identifier; and ModelID is the business model identifier.

[0060] For example, the product model data for all nodes is "data / sync / all / all / ProductModel"; User model data for the North Region node group: "data / sync / group / NorthRegion / UserModel"; The order model data for station A is "data / sync / node / StationA / OrderMode".

[0061] The generated target topics are automatically registered in the message bus and Tunnel service, supporting topic access control (only authorized nodes can subscribe), preventing unauthorized nodes from subscribing to sensitive data (such as financial data), and ensuring data security.

[0062] Step 402: Publish the business model format data to the target topic, and transmit the business model format data to the target edge node that subscribes to the target topic through the routing configuration of the message bus.

[0063] In one embodiment, standard format data is published to the target topic, and routing and forwarding are achieved through the message bus and Tunnel service to achieve efficient distribution. Optionally, the server publishes business model format data to the target topic through the message bus SDK, supporting QoS (Quality of Service) level configuration (QoS0 / 1 / 2). For example, core business data (such as transaction orders) can be configured with QoS2 (ensuring that the message is received only once to avoid duplicate execution), while non-core data (such as announcements) can be configured with QoS0 (receiving at most once, allowing a small amount of loss), adapting to different reliability requirements.

[0064] After receiving a message, the message bus passes it to the Tunnel service. Based on the target node identifier in the topic and the registered subscription relationship, the Tunnel service starts a dedicated routing channel to push the message to all edge nodes that have subscribed to the topic. It adopts an asynchronous forwarding mechanism, does not occupy central server resources, supports concurrent push of millions of nodes, has no performance bottleneck, and solves the problem of high pressure on the central server in traditional point-to-point architecture.

[0065] The Tunnel service returns the publication status (success / failure) to the server. If publication fails, a retry is triggered (the number of retries and the interval are configurable, such as 3 retries with a 5-second interval by default for QoS1). If a retry fails, an exception log is recorded and the administrator is notified to ensure that no messages are lost.

[0066] Figure 4 The topic generation and publishing process achieves accurate and efficient distribution. Hierarchical topic naming ensures both uniqueness and readability. QoS classification adapts to different reliability requirements. Asynchronous routing reduces the pressure on the central office. Access control ensures data security. Publishing status feedback and retry mechanisms improve reliability. It solves the problems of difficult expansion, high central office load, and inaccurate data distribution in traditional point-to-point architectures, and supports concurrent node access. Figure 5 This is a flowchart illustrating the target edge node subscription provided in this application embodiment. Please refer to [link / reference]. Figure 5 The process of edge nodes subscribing to target topics, receiving data, and performing synchronization is the final execution stage of data distribution, specifically including: Step 501: The target edge node subscribes to the target topic and receives the business model format data.

[0067] In one embodiment, the edge node automatically subscribes to a preset target topic upon startup and connects to the Tunnel service, establishing a long-term connection with the message bus to ensure real-time data reception. Optionally, the target topics to be subscribed to are preset in the edge node's local configuration file, supporting wildcard subscriptions (e.g., "data / sync / node / StationA / #" subscribes to all model data of station A), reducing configuration workload and avoiding cumbersome configuration caused by too many topics. Simultaneously, the subscription information is synchronized to the Tunnel service to complete route binding.

[0068] After the edge node starts up, it establishes a long TCP connection with the central Tunnel service through the Tunnel client. It adopts an access process of identity authentication and encryption negotiation (username / password + device certificate dual authentication) to prevent unauthorized nodes from accessing the system. It supports automatic reconnection (retrying the connection after network interruption) to ensure connection stability. After the connection is established, a session key is negotiated for encrypted data transmission.

[0069] Once the edge node successfully subscribes and the tunnel connection is completed, it synchronizes the subscription status (topic name + subscription time + node identifier + tunnel connection status) to the central server. The central server maintains a list of node subscriptions and tunnel connections, which facilitates operations and maintenance personnel to monitor the node access status and promptly detect anomalies.

[0070] Step 502: Based on the business model stored in the target edge node, parse the business model format data, generate operation instructions for the local database of the target edge node, and execute them to complete the distribution of the target business data.

[0071] In one embodiment, after receiving data through the Tunnel client, the edge node parses the data based on the business model stored locally and generates database operation instructions for execution, thereby completing data synchronization.

[0072] After receiving data through the Tunnel client, the edge node first verifies the data format (whether it conforms to the JSON standard) and signature (to prevent data tampering). If the verification fails, the data is discarded and logged. If the verification is successful, the ModelID and DataContent are extracted. The system matches the business model stored locally with the ModelID. If no corresponding model is found, it requests the central server to synchronize the model via the Tunnel service before parsing. Once the model is found, it parses the key-value pairs in the DataContent based on the model's attribute mapping relationship and converts them into the field format of the local database, such as converting the model attribute "prod_id" into the local field "product_id". Based on the ChangeType and the operation rules defined in the model, SQL operation instructions (INSERT / UPDATE / DELETE) are generated and executed through the local database connection pool. The execution results (success / failure + number of rows affected) are synchronized to the central server through the Tunnel service to facilitate monitoring of data synchronization status. When execution fails, detailed logs are recorded, such as primary key conflicts and excessively long fields, to provide a basis for troubleshooting. Figure 5 The node subscription process ensures the real-time and stability of data reception, wildcard subscription simplifies configuration, long connections and automatic reconnection prevent data loss, identity authentication prevents unauthorized access, reception verification and model matching ensure accurate parsing, execution result feedback facilitates operation and maintenance monitoring, and process automation reduces manual intervention. It solves the problems of cumbersome node access, opaque status, and error-prone data synchronization in traditional solutions, and improves the reliability of terminal execution.

[0073] Figure 6 This is a flowchart of the target edge node parsing and execution provided in this application embodiment. The logic of the edge node parsing business model format data and generating database operation instructions is a link to ensure correct data synchronization, specifically including: Step 601: Parse the business model identifier in the business model format data, and match the corresponding business model pre-stored by the target edge node according to the business model identifier.

[0074] In one embodiment, after receiving data through the Tunnel client, the edge node first decrypts the data and then extracts the business model identifier, matching it with the locally pre-stored business model to provide a basis for parsing.

[0075] Extract the model identifier, such as "MemberModel", from the "ModelID" field of the business model format data. Use exact string matching (case sensitive) to avoid matching failures caused by case sensitivity or spaces, and ensure the accuracy of model correspondence.

[0076] Edge nodes query the local model storage table (structured storage of model configuration information), find the corresponding model record based on ModelID, which contains complete information such as model attribute list, field mapping relationship, operation rules, etc., to ensure that all the information required for parsing is complete.

[0077] If the corresponding model is not found, a model synchronization request (carrying ModelID and node identifier) ​​is sent to the central server through the Tunnel service. The central server pushes the model to the edge node, and the edge node stores it and re-executes the parsing process to ensure that the parsing is not interrupted and improve the system's fault tolerance. Step 602: Based on the attribute features and field mapping relationship of the business model, parse the formatted data content of the business model.

[0078] In one embodiment, based on the attribute features and field mapping relationship of the business model, the data content is parsed and converted into field data in the local database. Business data in key-value pair form is extracted from the DataContent field, such as "{"mem_id":"M001", "mem_name":"Zhang San", "mem_level":"VIP"}", to maintain data integrity and structure. Based on the mapping relationship between the model's attributes and table fields, the keys of the data content are converted into local database table fields. For example, "mem_id" is mapped to "member_id" and "mem_leve" is mapped to "member_level". At the same time, data type conversion is performed, such as converting JSON string type to database VARCHAR type and numeric type to INT / DECIMAL type to ensure data compatibility with local fields.

[0079] Based on the constraints of the model attributes, such as field length, numerical range, and enumeration value limits, the converted data is validated. For example, membership levels are only allowed to be ordinary, VIP, and SVIP. If the range is exceeded, an anomaly is recorded and the data is discarded to avoid database execution errors and ensure data synchronization quality.

[0080] Step 603: Generate local database operation instructions for the target edge node based on the data change identifier and the data operation rules defined in the business model.

[0081] In one embodiment, operation instructions for the local database are generated based on data change identifiers and operation rules defined in the model to ensure correct data synchronization. Optionally, the ChangeType field (“INSERT”, “UPDATE”, “DELETE”) in the data is extracted to determine the data operation type, providing a basis for instruction generation.

[0082] The INSERT command generates an insert instruction based on the transformed field data, such as "INSERT INTO member_table (member_id, member_name, member_level) VALUES ('M001', 'Zhang San', 'VIP')", ensuring a one-to-one correspondence between fields and values.

[0083] The UPDATE command generates update instructions based on the primary key field (a unique identifier field specified in the model, such as "member_id"), for example, "UPDATE member_table SET member_level = 'SVIP' WHERE member_id = 'M001'", avoiding a full table update and improving execution efficiency.

[0084] The DELETE command generates deletion instructions based on the primary key field, such as "DELETE FROM member_table WHERE member_id = 'M001'", ensuring accurate deletion and avoiding accidental data deletion. For batch data, such as synchronizing multiple product data at once, batch operation instructions are generated, such as batch INSERT, which reduces the number of database interactions and improves execution efficiency; the instructions are cached locally after generation, and can be retried if execution fails, thus improving reliability.

[0085] Figure 6 The parsing and execution process enables accurate conversion of standard data to local operations. Model identifier matching ensures parsing specificity, attribute mapping and data verification guarantee the accuracy of data entry, batch instruction optimization improves execution efficiency, and the automatic synchronization mechanism for missing models enhances fault tolerance, avoiding data inconsistency caused by parsing errors. This solves the problems of difficult data adaptation, numerous data entry errors, and low execution efficiency in traditional solutions.

[0086] Figure 7 This is a flowchart of the QoS classification retry and exception handling provided in the embodiments of this application. Please refer to [link / reference]. Figure 7 QoS-based retry and exception handling procedures during data distribution are crucial mechanisms for ensuring the integrity and reliability of data distribution. These include: Step 701: Record the transmission status of the business model format data, the reception status of the target edge node, the execution result of the local database operation command, and the QoS level corresponding to the business model format data.

[0087] In one embodiment, the transmission status of business model format data, edge node reception status, instruction execution results, and QoS level are recorded throughout the process, providing a basis for retry and exception handling.

[0088] Record the transmission status, message bus publication status (success / failure), message arrival timestamps at edge nodes, and network latency.

[0089] Record the reception status, the reception result (success / failure) of the edge node, the data verification result (pass / fail), and the reception time.

[0090] Record the execution results, including the execution status of the database operation command (success / failure), the number of rows affected, and the reason for failure, such as primary key conflict, field exceeding the limit, or database unavailability.

[0091] QoS level, the QoS level configured when publishing data (0 / 1 / 2), and the importance of the associated business model (core / non-core). Status information is stored in the log table of the central server and the local logs of the edge nodes. The retention period is configurable (default 90 days). It supports querying by model, node, time range, and status type, making it easy for operation and maintenance personnel to trace problems.

[0092] Step 702: Preset the QoS level and retry parameter mapping relationship for different business model format data scenarios. The retry parameters include retry number threshold, retry time interval and retry timeout threshold.

[0093] In one embodiment, retry parameters corresponding to different QoS levels are configured based on service importance to achieve tiered retries and balance reliability and resource consumption. QoS level definitions: Optionally, QoS0 (at most once) is suitable for non-core data, such as announcements and advertisements, allowing data loss, no retries, and reducing resource consumption; QoS1 (at least once) is suitable for important data, such as product inventory, ensuring that the data is received at least once and supporting limited retries; QoS2 (exactly once) is suitable for core data, such as transaction orders and user balances, ensuring that the data is received only once, supporting multiple retries, and avoiding repeated execution.

[0094] The pre-defined mapping relationship specifies the retry threshold, retry interval, and retry timeout threshold for different QoS levels. It also includes Tunnel service retransmission parameters, such as the number of fragment retransmissions and retransmission timeout. For example, QoS level 1 retryes 3 times with a 5-second interval and a 30-second timeout, and tunnel fragment retransmissions 2 times; QoS level 2 retryes 5 times with a 10-second interval and a 60-second timeout, and tunnel fragment retransmissions 3 times. These parameters can be dynamically adjusted through the configuration platform to adapt to different business needs.

[0095] Step 703: Match the corresponding retry parameters based on the QoS level configured in the business model associated with the business model format data.

[0096] In one embodiment, when a data transmission failure or command execution anomaly is detected, a tiered retrieval is triggered based on the corresponding retry parameters matched according to the QoS level. Optionally, status information is monitored in real time, and abnormal scenarios that trigger retries include message publishing failure, edge node not receiving data, data verification failure (non-format error), and command execution failure (non-business logic failure, such as network interruption or temporary database unavailability), clearly defining retry boundaries and avoiding invalid retries.

[0097] Tunnel-level retry: When tunnel transmission fails, such as due to fragment loss or network interruption, the Tunnel service automatically triggers fragment retransmission based on retransmission parameters, without the need for central server intervention, thus improving transmission reliability. The central server handles retrying. When message publishing fails, the central server triggers a retry based on the retry parameters. Each retry records the number of retries and the time. Retrying stops when the retry threshold or timeout threshold is reached to avoid infinite retries.

[0098] Edge-side retry: When an instruction fails to execute, the edge node triggers a retry based on the retry parameters cached locally. During the retry process, the primary key is used to determine whether the data has been synchronized (e.g., the UPDATE instruction checks whether the current data has been updated) to avoid data inconsistency caused by repeated execution. The retry request synchronizes the status to the center through the Tunnel service.

[0099] The result of each retry is updated in the status log, which makes it easier for administrators to monitor the progress and effect of retry and intervene in abnormal situations in a timely manner.

[0100] Step 704: If the data transmission failure of the business model format or the instruction execution abnormality is detected, a tiered retry is triggered according to the matched retry parameters.

[0101] In one embodiment, abnormal data that fails to complete a tiered retry is marked and stored in an exception queue, supporting manual intervention and ensuring the integrity of data distribution.

[0102] Data that fails to retry is marked as an anomaly, categorized into transmission anomalies (network problems, message bus failures), parsing anomalies (incorrect data format, missing models that cannot be synchronized), and execution anomalies (database constraint conflicts, incompatible fields), facilitating targeted handling.

[0103] Abnormal data is stored in the abnormal data queue of the central server (structured storage, containing complete business model format data, status information, and abnormal type), which supports filtering and querying by abnormal type, model, time, and node, making it easy for administrators to quickly locate problematic data.

[0104] Administrators can view abnormal data through the configuration platform, which offers three handling methods: manual retry, data correction, and ignore / discard. Manual retry is suitable after fixing the cause of the anomaly, such as restoring the network or correcting the database configuration, and then redistributing the data through the Tunnel service; data correction is suitable for issues such as incorrect data format or excessively long fields, which are corrected online and then redistributed; ignore / discard is suitable for scenarios where data does not need to be synchronized, marking it as ignored and deleting it to ensure that abnormal data is not missed or accumulated.

[0105] Figure 7The hierarchical retry and anomaly handling process improves distribution reliability. The full-link status record provides a complete basis for troubleshooting. QoS and retry parameter binding enables differentiated strategies to avoid excessive resource consumption. Anomaly classification storage and multiple manual intervention methods ensure that core data is not lost and anomaly data is traceable. It solves the problems of no feedback on faults, blind retries, and no one to handle anomaly data in traditional solutions, and ensures the integrity of distribution.

[0106] Figure 8 This is a structural diagram of the data distribution system based on a business model provided in the embodiments of this application. Please refer to it. Figure 8 The data distribution system of this application consists of functional modules including a model configuration module 801, a data acquisition and encapsulation module 802, and a message publishing module 803. These modules work together to achieve end-to-end data distribution, specifically including: In one embodiment, the model configuration module 801 is used for the construction, storage, synchronization, and updating of business models. The synchronization process is secured through the Tunnel service, enabling standardized definition of business logic. Optionally, the visual configuration unit provides a web-based visual configuration interface, supporting the creation, editing, and deletion of business models. The interface is divided into a business model basic information configuration area, an attribute list configuration area, a data source mapping configuration area, and an operation rule configuration area. Administrators complete the configuration through drag-and-drop, checkboxes, and input, eliminating the need for coding and lowering the technical barrier.

[0107] The model storage unit stores the constructed business model information in the model management table of the central database. It adopts structured storage (JSON format to store attribute lists and mapping relationships) and supports business model version management (recording the version number, modifier, modification time, and modification content of each modification), which facilitates the rollback of historical versions and the tracing of change records.

[0108] The model synchronization unit is used to synchronize newly built or updated business models to target edge nodes. It achieves secure push through the Tunnel service, supports batch synchronization and incremental synchronization (synchronizing only the modified parts), and ensures the consistency of business models through an acknowledgment mechanism (the edge node returns an acknowledgment message after receiving the data) during the synchronization process. When synchronization fails, it triggers retries and exception alarms (notifying the administrator via SMS and email) to ensure that no synchronization is missed.

[0109] The model update unit monitors changes to the business model, such as the addition of attributes, modification of mapping relationships, and adjustment of operation rules. It automatically generates a business model update notification and pushes it to all edge nodes that have subscribed to the model through the Tunnel service, triggering the model update process of the nodes (downloading the new model, replacing the old model, and updating the local configuration) to ensure that the models of the central and edge nodes are consistent.

[0110] The data acquisition and encapsulation module 802 collects target data from the central database based on the model, processes it, and encapsulates it into a standard format to ensure data quality and compatibility. Optionally, the query instruction generation unit automatically generates optimized SQL query instructions based on the data source mapping relationship and triggering conditions (period / event) of the business model. It supports multi-table join queries and dynamic filtering conditions, such as filtering by time range and status. After the instructions are generated, they are cached locally to improve execution efficiency and avoid duplicate generation.

[0111] The data acquisition unit executes query commands through the database connection pool to obtain target data from the central database. It supports databases (MySQL, Oracle, SQL Server, PostgreSQL). During the acquisition process, it monitors the database connection status and triggers a reconnection when a connection is abnormal, ensuring the continuity of acquisition and improving system compatibility and stability.

[0112] The data processing unit filters (filters useless fields), cleans (handles null values, outliers, and converts formats), completes (fills in default values), and structures (converts to key-value pairs) the collected data. The processing rules are bound to the business model to ensure that the data processing logic is consistent across different models and nodes, thereby improving data quality.

[0113] The standard encapsulation unit encapsulates the processed data into a unified business model format, including business model identifiers, data content, and change identifiers. It supports data compression and encryption. The encapsulated data adapts to the transmission format requirements of the Tunnel service, is stored in a temporary queue, and awaits publication through the tunnel, ensuring the standardization, efficiency, and security of data transmission.

[0114] The message publishing module 803 publishes standard-format data to target topics via the message bus, manages node subscription relationships, and ensures accurate and efficient data distribution. Optionally, the topic management unit generates target topics according to distribution requirements, maintains the association between topics, models, and nodes, supports topic creation, deletion, and permission configuration (only authorized nodes can subscribe), prevents unauthorized nodes from subscribing to sensitive data, and stores topic information in the central database for easy querying, management, and operation and maintenance monitoring. The message publishing unit publishes standard format data to the target topic, supports QoS level configuration (0 / 1 / 2), and works with the message bus and Tunnel service during the publishing process to obtain the publishing status. If the publishing fails, it triggers a retry (matching retry parameters according to the QoS level) to ensure that messages are not lost and adapt to different reliability requirements.

[0115] The subscription management unit maintains the subscription relationships of edge nodes, records the topics subscribed to by nodes, subscription time, connection status, and authentication information, supports adding, deleting, and querying subscription relationships, monitors the subscription status of nodes (online / offline), and triggers alarms when nodes are abnormally disconnected, so that administrators can handle the situation in a timely manner.

[0116] The status monitoring unit monitors the data publishing status, node receiving status, and command execution status in real time, and generates monitoring reports such as distribution success rate, average latency, and anomaly rate. It also supports anomaly alarms (via SMS, email, and system notifications), making it easy for administrators to grasp the system's operating status in real time and respond quickly to faults.

[0117] Figure 8 The three major modules work together to build an efficient distribution system. The model configuration module lays the foundation for standardization, the data collection and encapsulation module ensures data quality, and the message publishing module achieves accurate transmission. The modules have clear division of labor and smooth interaction, support dynamic expansion and flexible configuration, adapt to different industry scenarios, and reduce the difficulty of operation and maintenance through visual management and status monitoring. It solves the problems of rigid architecture, coupled functions, and complex operation and maintenance of traditional solutions, and improves the overall availability of the system.

[0118] Figure 9 This is a structural diagram of the electronic device provided in the embodiments of this application. Please refer to it. Figure 9 The hardware structure of the electronic device of this application can integrate the data distribution system of this application to execute the above-mentioned data distribution method. The efficient operation of the system is ensured through the collaborative work of hardware components, specifically including: In one embodiment, the electronic device includes a processor 901, a memory 902, an input device 903, an output device 904, and a communication module (integrated into the system). The components are connected via an industrial-grade bus, such as PCIe or USB 3.0, to achieve data transmission and command interaction. The processor 901 is used to run the software programs and modules in the memory 902, coordinate the work of various hardware components, and implement the various functions of the data distribution method.

[0119] The hardware selection adopts high-performance multi-core processors, such as Intel Xeon series and AMD EPYC series, with ≥8 cores, a main frequency of ≥2.4GHz, and support for hyper-threading technology. This meets the needs of message routing and encryption, sharding, and routing calculations for a large number of edge nodes and Tunnel services in handling millions of concurrent data, ensuring stable operation of the system under high load.

[0120] Run software programs for model configuration, data acquisition, message publishing, Tunnel service, and status monitoring. Control the model configuration module to build and synchronize the model, coordinate the data acquisition and encapsulation module to process data, drive the message publishing module and Tunnel service to distribute data collaboratively, and handle interactive information such as model synchronization requests and data synchronization result feedback from edge nodes to ensure that all modules work together.

[0121] It supports hardware acceleration, such as GPU-accelerated data processing, network card offloading of TCP protocol processing, and encryption chip acceleration of Tunnel service encryption / decryption, improving data processing and network transmission efficiency; it adopts a multi-threaded concurrent processing mechanism, allocating independent threads for data distribution to different models and nodes to avoid mutual interference and improve the system's concurrent processing capabilities. The memory 902 is used to store software programs, model data, configuration information, log data, etc., providing data support for the processor 901 and functional modules.

[0122] Hardware specifications include high-speed random access memory (RAM, capacity ≥ 32GB) and non-volatile memory (SSD, capacity ≥ 1TB). RAM is used for data caching during program execution and temporary queue storage (standard format data to be published), with a read / write speed ≥ 2000MB / s to ensure high-speed data processing; SSD is used to store software programs and the central database (model management table, log table, and exception data queue), with a read / write speed ≥ 500MB / s to ensure data storage stability and fast access.

[0123] Storage partitioning management divides SSDs into system areas (storage operating system and software programs), data areas (storage center database), log areas (storage end-to-end status logs, Tunnel transmission logs), and backup areas (storage model and data backups). Partitioning management improves storage orderliness and security, and avoids interference between different types of data. Data security features include encrypted data storage (database encryption, file encryption) to prevent data leakage; regular backups (automatic backup of model and log data, with configurable backup cycles); and off-site or cloud storage for backup data to prevent data loss and ensure data security and integrity. The input device 903 is used to receive configuration inputs and operation commands from the administrator, providing a human-machine interface for system management.

[0124] Hardware options include keyboards, mice, touchscreens, and external input devices (such as barcode scanners), supporting both local and remote input (via remote desktop and web console), and adapting to different management scenarios (local maintenance and remote monitoring). The system receives model configuration instructions (create / edit models), data publishing instructions (select distribution range and QoS level), Tunnel service configuration instructions (set encryption algorithm, adjust retransmission parameters, configure bandwidth limits), and exception handling instructions (manually retry / correct abnormal data) from the administrator. It converts the instructions into electrical signals that the device can recognize and transmits them to the processor 901 for execution, ensuring that the administrator's operations can be responded to quickly.

[0125] The accompanying web management console provides an intuitive user interface, including a command input area, a status display area, a result feedback area, and a Tunnel service configuration area. Administrators can complete operations by clicking buttons, entering parameters, and selecting options. Operation results are fed back in real time, such as configuration success prompts and abnormal alarm pop-ups, reducing the difficulty of operation and improving management efficiency. The output device 904 is used to output the system's operating status, configuration information, and alarm information, providing visual feedback to the administrator.

[0126] The hardware includes a display screen, a printer, and alarm devices (indicator lights and buzzers). The display screen is used to show the operation interface of the Web management console, system monitoring reports, and model configuration information; the printer is used to print log reports and configuration lists; and the alarm devices are used for local alarms (indicator light colors distinguish alarm levels: green for normal, yellow for warning, and red for severe, and a buzzer to provide an audible alert), adapting to different feedback needs. The system outputs corresponding feedback information based on its operational status, such as successful model configuration notifications, data publishing progress bars, node synchronization status lists, Tunnel service connection status statistics, and anomaly alarm information (including anomaly type, occurrence time, impact scope, and handling suggestions). The output information supports export (Excel and PDF formats) for easy offline analysis and reporting, helping administrators quickly grasp the system status. The output delay for status and alarm information is ≤1 second, ensuring administrators can monitor system operation in real time, promptly handle anomalies, and prevent escalation of faults.

[0127] Figure 9 The hardware architecture provides support for the system, with high-performance processors ensuring concurrent processing capabilities, large-capacity high-speed storage meeting data and program needs, partition management and encrypted backup enhancing data security, diverse input / output devices optimizing the operation and maintenance experience, hardware acceleration and multi-threading mechanisms improving operating efficiency, adapting to the high-load requirements of large-scale distributed scenarios, solving the problems of insufficient traditional hardware performance, insecure storage, and inconvenient interaction, and ensuring stable system operation.

[0128] In one embodiment, the computer-readable storage medium provided in this application uses a high-speed SSD or cloud storage medium with a capacity of ≥1TB, supports encrypted storage and off-site backup, and stores computer-readable instructions. The instructions are organized in a modular structure and include the execution code of core functions such as model configuration, data acquisition, message publishing, Tunnel service, and retry exception handling. At the same time, it stores basic data such as model configuration templates, QoS and retry parameter mapping tables, node subscription relationship tables, and Tunnel service configuration parameters (encryption algorithm, retransmission parameters, bandwidth limits).

[0129] When the processor executes the above instructions, it first initializes the various functional modules of the system and the Tunnel service, loads the model configuration information, parameter mapping relationships, and tunnel configuration parameters from the storage medium; it provides a visual interface through the model configuration module to receive the administrator's model configuration instructions, builds and stores the business model, and synchronizes it to the target edge nodes through the Tunnel service; based on the model's data source mapping relationship and triggering conditions, it generates query instructions to collect target data from the central database, and after filtering, cleaning, and structuring, it encapsulates the data into a standard format; it generates target topics according to distribution requirements, and publishes the standard format data to the topics through the message bus and the Tunnel service. After the edge nodes subscribe through the tunnel access, they parse the data based on the local model and generate database operation instructions for execution; it records the entire link status information (including tunnel transmission status), and triggers graded retries (including tunnel retransmission) according to the QoS level when an anomaly is detected. The abnormal data of the retry failure is stored in the anomaly queue, which supports manual intervention.

[0130] This storage medium supports hot-swapping and online expansion, adapting to distributed systems of different sizes; encrypted storage and backup mechanisms ensure data security and prevent leakage and loss; it is compatible with mainstream operating systems such as Windows, Linux, and Unix, and can be directly deployed on various environments such as physical servers, virtual machines, and containers, effectively supporting the stable implementation of data distribution functions based on business models and Tunnel services, and improving the flexibility and reliability of system deployment.

[0131] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments provided herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A data distribution method based on a business model, characterized in that, Applied to a server, the method includes: A business model is built by configuring the platform, and the built business model is sent to the target edge node for storage. Upon receiving the storage confirmation message of the business model returned by the target edge node, the synchronous storage of the business model is completed. Based on the data source mapping relationship of the business model, query instructions are generated periodically. Target business data is collected from the central database based on the query instructions, and data filtering and data completion processing are performed on the target business data. The processed target business data is then encapsulated into business model format data that the business model can recognize. The business model format data is published to the target topic associated with the business model via a message bus, so that the target edge node subscribes to the corresponding target topic and parses the business model format data based on the stored business model to generate local operation instructions.

2. The data distribution method based on a business model according to claim 1, characterized in that, The business model is used to define the attribute characteristics, data source mapping relationship, and data operation rules of the target business data; The process of building a business model through a configuration platform includes: The business model identifier, attribute list, data source table, and field mapping relationship are defined through the configuration interface; the attribute list includes the name, data type, and description information of the target business data, and the field mapping relationship is used to associate the attribute list of the business model with the fields of the data source table; The configuration interface defines data operation rules, which specify the local database operation type when the business data changes.

3. The data distribution method based on a business model according to claim 2, characterized in that, The process of collecting target business data from the central database based on the query command includes: According to a preset period or triggering condition, a query instruction for the target business data is generated based on the data source mapping relationship of the business model; The system executes a query command for the target business data to retrieve the target business data from the central database, and then filters, cleans, and structures the target business data according to the attribute characteristics of the business model. The processed target business data is encapsulated into business model format data in a preset format, wherein the business model format data includes a business model identifier, data content, and data change identifier.

4. The data distribution method based on a business model according to claim 1, characterized in that, The naming rules for the target topic are associated with the business model identifier and the target edge node identifier, and one-to-one and one-to-many distribution are adopted. The step of publishing the business model format data to the target topic associated with the business model via the message bus includes: The target edge node identifier is determined based on the distribution requirements, and the target topic is generated by combining the business model identifier; The business model format data is published to the target topic, and the business model format data is transmitted to the target edge node that subscribes to the target topic through the routing configuration of the message bus.

5. The data distribution method based on a business model according to claim 1, characterized in that, The target edge node subscribes to the corresponding target topic, parses the business model format data based on the stored business model, and generates local operation instructions, including: The target edge node subscribes to the target topic and receives the business model format data; Based on the business model stored in the target edge node, the business model format data is parsed, and operation instructions for the local database of the target edge node are generated and executed to complete the distribution of the target business data; The step of parsing the business model format data based on the business model stored on the target edge node, generating and executing operation instructions for the local database of the target edge node, includes: Parse the business model identifier in the business model format data, and match the corresponding business model pre-stored by the target edge node according to the business model identifier; Based on the attribute features and field mapping relationship of the business model, the formatted data content of the business model is parsed. Based on the data change identifier and the data operation rules defined in the business model, local database operation instructions for the target edge node are generated.

6. The data distribution method based on a business model according to claim 5, characterized in that, After the distribution of the target business data is completed, the following is also included: In the event of a change in the business model, the business model update notification is pushed to all target edge nodes that have subscribed to the target topic associated with the business model via the message bus. The target edge nodes receive the business model update notification, obtain the updated business model, and replace the old business model in the local database.

7. The data distribution method based on a business model according to claim 5, characterized in that, After the distribution of the target business data is completed, the following is also included: Record the transmission status of the business model format data, the reception status of the target edge node, the execution result of the local database operation command, and the QoS level corresponding to the business model format data; The QoS level and retry parameter mapping relationship corresponding to different business model format data scenarios is preset, and the retry parameters include retry number threshold, retry time interval and retry timeout threshold; Based on the QoS level configured in the business model associated with the business model format data, the corresponding retry parameters are matched. If the data transmission failure of the business model format or the abnormal execution of the instruction is detected, a tiered retry is triggered according to the matched retry parameters; For business model format data that fails to complete a tiered retry, an anomaly marker is set and stored in the anomaly data queue of the local database for manual intervention.

8. A data distribution system based on a business model, characterized in that, include: The model configuration module constructs a business model through the configuration platform, sends the constructed business model to the target edge node for storage, and completes the synchronous storage of the business model upon receiving a storage confirmation message for the business model returned by the target edge node. The acquisition and encapsulation module is used to periodically generate query instructions based on the data source mapping relationship of the business model, acquire target business data from the central database based on the query instructions, perform data filtering and data completion processing on the target business data, and encapsulate the processed target business data into business model format data that the business model can recognize. The message publishing module is used to publish the business model format data to the target topic associated with the business model through the message bus, so that the target edge node subscribes to the corresponding target topic, and parses the business model format data based on the stored business model to generate local operation instructions.

9. An electronic device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the data distribution method based on the business model as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the data distribution method based on a business model as described in any one of claims 1-7.

Images