Data distribution method and device, computer device, storage medium and program product

Abstract

The application relates to a data distribution method and device, computer equipment, a storage medium and a computer program product. The method is applied to a content library connector of a content library node of a CDN, the content library connector comprises computing power resources in a virtual environment, the content library node exists corresponding edge nodes of the CDN, and the method comprises the following steps: acquiring a data request, determining a data user to which the data request belongs based on the data request, determining a target edge node suitable for the data request from each edge node, providing an edge connector in the edge node, the edge connector comprising computing power resources of the edge node in a virtual environment, sending the data request to the target edge node to instruct the edge connector of the target edge node to determine a target data product matched with the data request according to the data request, and sending the target data product to the data user. The method can improve the distribution efficiency.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data distribution method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] As the construction of a trusted data space continues to advance, the scale of data product release, sharing, trading and circulation continues to grow, and the demand for data access across regions and multiple entities is rapidly increasing, which puts forward higher requirements for data transmission efficiency, access latency, resource scheduling and trusted management.

[0003] Traditional centralized data transmission architectures are prone to problems such as network congestion, increased access latency, and concentrated node load in large-scale, high-concurrency data flow scenarios, making them difficult to adapt to the needs of real-time processing and localized services at the edge, resulting in low processing efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a data distribution method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve processing efficiency to address the performance bottleneck problem in high-concurrency data flow scenarios, in order to solve the aforementioned technical problems.

[0005] In a first aspect, this application provides a data distribution method applied to a content library connector of a CDN content library node, wherein the content library connector includes computing resources in a virtual environment, and the content library node has a corresponding CDN edge node; the method includes:

[0006] Obtain a data request, and determine the data user to which the data request belongs based on the data request;

[0007] The target edge node for the data request adaptation is determined from each of the edge nodes; the edge node is equipped with an edge connector, and the edge connector includes the computing power resources of the edge node in the virtual environment;

[0008] The data request is sent to the target edge node to instruct the edge connector of the target edge node to determine the target data product that matches the data request, and to send the target data product to the data user.

[0009] In one embodiment, determining the target edge node for the data request adaptation from among the edge nodes includes:

[0010] Based on the data request, determine the identity information of the edge connector, and determine each edge node corresponding to the identity information;

[0011] Based on the data user and the running status of each edge node, the edge nodes are filtered to obtain the target edge node that matches the data request.

[0012] In one embodiment, the step of filtering each edge node based on the data user and the operating status of each edge node to obtain the target edge node for data request adaptation includes:

[0013] Based on the target digital contract indicated by the data request, and the load and health status of each edge node, determine the deliverable nodes among the edge nodes;

[0014] Based on the location of the data user, each deliverable node is filtered to obtain the target edge node that the data request is adapted to.

[0015] In one embodiment, the method further includes:

[0016] Obtain the access increment for each of the aforementioned edge nodes;

[0017] Determine whether the global access volume corresponding to each access increment meets the limit condition;

[0018] If the aforementioned limit conditions are met, then the data consistency of each edge node is strong consistency.

[0019] If the threshold conditions are not met, the data consistency of each edge node is eventually consistent.

[0020] In one embodiment, the method further includes:

[0021] Based on the contract deployment request, obtain the digital contract between the candidate data user and the data provider, and parse the control strategy from the digital contract;

[0022] The edge connector policy in the control strategy is determined, and the edge connector policy is sent to the edge node so that the edge node, based on the edge connector policy, executes the determination step of the target data product when the data request verification is valid.

[0023] This application also provides a data distribution method applied to an edge connector of an edge node in a CDN. The edge connector includes computing resources in a virtual environment, and the edge connector has a corresponding content library node in the CDN. The method includes:

[0024] Obtain the data request sent by the content library node; the data request includes the transparent extended data;

[0025] The interaction semantics are obtained from the extended data, and the target data product matching the data request is determined based on the interaction semantics.

[0026] Send the target data product to the data user.

[0027] In one embodiment, obtaining interaction semantics from the extended data and determining the target data product matching the data request based on the interaction semantics includes:

[0028] Based on the extended data in the data request, determine the target digital contract identifier and the target data product identifier;

[0029] According to the target digital contract identifier, the data product represented by the target data product identifier is adjusted to obtain the target data product that matches the data request;

[0030] The target digital contract identifier indicates the processing method of the data product.

[0031] Secondly, this application also provides a data distribution device for a content library connector applied to a content library node of a CDN. The content library connector includes computing resources in a virtual environment, and the content library node has a corresponding edge node of the CDN. The device includes:

[0032] The acquisition module is used to acquire data requests and determine the data user to which the data request belongs based on the data requests;

[0033] An adaptation module is used to determine the target edge node for the data request adaptation from each of the edge nodes; the edge node is provided with an edge connector, and the edge connector includes the computing power resources of the edge node in the virtual environment;

[0034] The sending module is configured to send the data request to the target edge node, instructing the edge connector of the target edge node to determine the target data product matching the data request based on the data request, and send the target data product to the data user.

[0035] This application also provides a data distribution device applied to an edge connector of an edge node in a CDN. The edge connector includes computing resources in a virtual environment, and the edge connector has a corresponding content library node in the CDN. The device includes:

[0036] The acquisition module is used to acquire data requests sent by the content library node; the data requests include transparent extended data.

[0037] The determination module is used to obtain interactive semantics from the extended data and determine the target data product matching the data request based on the interactive semantics.

[0038] The response module is used to send the target data product to the data user.

[0039] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the data distribution steps in any of the above embodiments.

[0040] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the data distribution steps in any of the above embodiments.

[0041] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the data distribution steps in any of the above embodiments.

[0042] The aforementioned data distribution method, apparatus, computer equipment, storage medium, and computer program products include edge nodes equipped with edge connectors. Each edge connector encompasses the computing resources of the edge node within the virtual environment. A two-layer architecture is formed between the content library connector and the standard caching sublayer of the content library node, and also between the edge connector and the CDN standard caching sublayer. This centralized approach handles data connectivity steps without modifying the CDN standard caching sublayer. Since the connector is no longer a single-point deployed software system, data providers and users do not need to maintain independent connector instances; instead, the CDN directly executes the corresponding processing steps. This supports high-concurrency data access requests, reduces delivery latency of target data products, and ensures processing efficiency. Attached Figure Description

[0043] Figure 1 This is a diagram illustrating the application environment of a data distribution method in one embodiment.

[0044] Figure 2 This is a schematic diagram of a two-tier architecture used in a data distribution method in one embodiment;

[0045] Figure 3 This is a flowchart illustrating a data distribution method executed by the content library connector in one embodiment;

[0046] Figure 4 This is a schematic diagram of the process for determining target edge nodes in one embodiment;

[0047] Figure 5 This is a schematic diagram of the strategy generation process in one embodiment;

[0048] Figure 6This is a flowchart illustrating a data distribution method performed by an edge connector in one embodiment;

[0049] Figure 7 This is a multi-terminal interaction sequence diagram of a data distribution method in one embodiment;

[0050] Figure 8 This is a structural block diagram of the data distribution device of the content library connector in one embodiment;

[0051] Figure 9 This is a structural block diagram of the data distribution device of the edge connector in one embodiment;

[0052] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0054] Therefore, leveraging the distributed advantages and global scheduling capabilities of Content Delivery Networks (CDNs) at the edge to build an edge-trusted transmission system for trusted data spaces has become an important technological direction for improving data circulation efficiency. However, existing solutions still have significant shortcomings. Connectors in trusted data spaces typically adopt a single-point deployment model. When faced with a large number of concurrent user accesses, bandwidth, computing, and storage resources can easily become system bottlenecks, and there is a lack of a unified scheduling mechanism for connector clusters. Some solutions improve performance by building dedicated transmission networks, which not only have high construction costs and long deployment cycles, but also make it difficult to fully utilize existing CDN infrastructure, limiting the system's scalability and large-scale deployment efficiency.

[0055] However, the current use of CDNs to carry and transmit data assets in trusted data spaces still faces the following prominent problems: First, connector performance bottlenecks. Connectors in the standard are designed as single-point deployed software systems, with data providers and users each maintaining independent connector instances. When data products are delivered to a large number of users with high concurrency (e.g., public data openness, government data sharing, cross-enterprise supply chain data collaboration), the bandwidth, computing, and storage resources of a single connector become significant bottlenecks. The standard does not define a scheduling mechanism for large-scale connector clusters. Second, traditional CDN architectures cannot meet the requirements for trusted circulation. Traditional CDNs possess globally distributed nodes and millisecond-level content distribution capabilities, but their design goal is to push content to the nearest node to the user as quickly as possible, lacking the identity verification, digital contract verification, control policy execution, and evidence auditing capabilities required for data circulation. While CDN caching strategies (such as cache time TTL and geo-blocking) functionally correspond to certain digital contract control strategies, there is a lack of a systematic mapping mechanism between the two. Furthermore, data circulation is incompatible with the CDN protocol layer. The Trusted Data Space standard defines a dedicated interaction interface between connectors, but the CDN's control plane and data plane both operate based on the HTTP / HTTPS standard protocol stack, which are incompatible. Existing technologies fail to provide a solution for embedding Trusted Data Space interaction semantics into the HTTP protocol without reconstructing the CDN protocol stack. Furthermore, distributed state management is lacking. When the same data product is cached and delivered on multiple edge nodes, the stateful policies in the Trusted Data Space technical requirements, such as limiting usage times and contract termination, need to be consistent across multiple physical nodes. Existing technologies do not provide a solution for contract state synchronization in distributed scenarios.

[0056] The data distribution method provided in this application embodiment can be applied to, for example, Figure 1The application environment shown includes a Trustworthy Data Space (TDS) and a Content Delivery Network (CDN). The Trustworthy Data Space is a data circulation and utilization infrastructure based on consensus rules, connecting multiple entities to achieve data resource sharing. It is centered on digital contracts and usage control technologies, aiming to ensure the trustworthiness (and compliance with expectations) of data circulation and use across entities. The Trustworthy Data Space is supported by a Trustworthy Data Space service platform. The Trustworthy Data Space operator operates the support platform, providing basic services for data circulation and use to participants, including identity management, connector management, directory management, digital contract management, space management, and evidence storage and auditing. The Trustworthy Data Space involves digital contracts, which describe in digital form the expectations of data providers, data users, data service providers, and other relevant participants regarding data circulation and use, including but not limited to data content, users, usage methods, usage frequency, usage scope, and usage environment.

[0057] A Content Delivery Network (CDN) is a distributed server node network architecture designed to improve the efficiency of internet content transmission and solve network congestion problems by retrieving cached content from the nearest server. The CDN consists of CDN content repository nodes 101 and CDN edge nodes 102.

[0058] like Figure 2 As shown, content library node 101 is the central storage and distribution node in the network, responsible for storing encrypted copies of data products and distributing content to edge nodes 102 to obtain the data products. In this embodiment, content library node 101 also deploys a trusted connector sublayer as a content library connector, serving as the core hub for network connection to the trusted data space service platform, undertaking coordination and management functions such as contract reception and parsing, policy compilation and distribution, and evidence aggregation and reporting. The contract engine module of the trusted connector sublayer of the CDN's content library node 101 includes a contract policy compiler, which receives digital contracts issued by the trusted data space service platform, automatically parses and classifies the control policies in them into two types of outputs: CDN native configuration rules and edge connector policy packages, realizing the automatic conversion of contract semantics to CDN configuration.

[0059] The trusted connector sublayer of edge node 102 is the edge connector. This embodiment proposes a logical sublayer deployed in edge node 102, which runs as a secure container or trusted execution environment (TEE), logically isolated from the CDN standard caching sublayer, and implements the six functions of the trusted data space connector (data resource management, identity management, data product management, digital contract management, data delivery, and data usage control). Division of responsibilities between the content library and the edge: The contract engine module of content library node 101 is responsible for contract policy compilation—after receiving the digital contract issued by the service platform, it parses and classifies the control policy (UsageControl) in the contract, for example, dividing it into edge data processing policy and edge connector policy, to generate CDN native configuration and edge connector policy packages, which are then distributed to relevant CDN nodes through the CDN management plane and the CDN internal trusted channel, respectively. The contract engine module of edge node 102 is only responsible for receiving and caching the issued policies, building contract indexes, and performing contract matching when a data access request is received.

[0060] Use control refers to the use of technology integrated into data applications, algorithms, and operating environments during the transmission, storage, use, and destruction of data. This ensures that relevant participants analyze, calculate, and process data in accordance with the control strategies of digital contracts, thereby controlling factors such as the time, place, subject, behavior, and object of data use.

[0061] In one embodiment, such as Figure 3 As shown, a data distribution method is provided, which can be applied to... Figure 1 The content library connector is applied to the content library node of the CDN. The content library connector includes computing resources in the virtual environment. The content library node has a corresponding CDN edge node. The method includes the following steps:

[0062] Step 302: Obtain the data request and determine the data user to which the data request belongs based on the data request.

[0063] A data request is an access request made by a data user to obtain a specific data product. A data request includes at least an identifier for the data product to identify the target data product. The data user is the data user who sends the data request; multiple data users may be included at any given time. Optionally, the data user can be identified by the data user identifier contained in the request header or request body.

[0064] Optionally, the request header of the data request includes an extension header, the fields of which include, but are not limited to: identifying the logically trusted data space to which the request belongs; identifying the digital contract corresponding to this request; carrying the requester's identity token (JWT / DID format); identifying the data product requested; declaring the operation type of the request (READ / COMPUTE / DOWNLOAD, etc.); and requesting a random number for evidence storage and replay protection.

[0065] In one optional embodiment, the process of acquiring data products is described. The data provider submits a data product registration request to the Trusted Data Space Service Platform, including metadata descriptions, terms of use, pricing strategies, and other information. After approval by the service platform, a unique identifier is assigned to the data product, and registration is completed. The data provider uploads the data product content to the content library node. The content library connector performs integrity verification on the received data content and stores it. Based on the CDN content distribution strategy, the content library node pushes the data product content to relevant edge nodes for pre-caching to support subsequent local delivery, thereby determining the content of each data product and identifying the target data product.

[0066] In some embodiments, the data user initiates an HTTPS request to the content library node, carrying X-TDS series extension headers, including trusted data space identity and authorization information such as the user connector ID, contract ID, and access token; the content library connector checks the X-TDS extension headers in the request to verify the user's identity and the basic validity of the contract; after successful verification, the data user to whom the data request belongs is obtained.

[0067] Step 304: Determine the target edge node for data request adaptation from each edge node; the edge node is equipped with an edge connector, and the edge connector includes the computing resources of the edge node in the virtual environment.

[0068] The target edge node includes at least one edge node invoked by the data request. The target edge node may be an edge node associated with the identifier of the data product contained in the data request, or it may be an edge node associated with the identity information contained in the data request.

[0069] In some embodiments, the content library nodes are weighted and calculated based on factors such as data user factors, edge node factors, and contract delivery constraints to obtain the score of each edge node; the target edge node is determined based on the edge node with the best score.

[0070] Step 306: Send a data request to the target edge node to instruct the edge connector of the target edge node to determine the target data product that matches the data request and send the target data product to the data user.

[0071] The target data product is a data product used to fulfill the requirements corresponding to the data request.

[0072] In some embodiments, content library nodes forward data requests to target edge nodes via the CDN internal network. This forwarding process is transparent to the data user, who does not need to be aware of the actual service node.

[0073] In some embodiments, the edge connector of the target edge node determines the target data product matching the data request based on the data request and sends the target data product to the data user. This includes: the edge node receiving a forwarded HTTPS request, in which the original X-TDS extension header information is retained to facilitate parsing out the corresponding extension data. The edge connector performs policy matching on the request according to locally cached access control policies, verifying whether the user's identity, contract permissions, access frequency, etc., comply with the policy rules.

[0074] Correspondingly, the target data product is sent to the data user. After policy matching is successful, the edge node returns the data product content to the data user. The response header carries unified identity information, making it impossible for the user to distinguish the actual delivery node.

[0075] In an exemplary embodiment, the control strategies are classified to obtain the original CDN edge strategy and the edge connector strategy; the original CDN edge strategy and the edge connector strategy are sent to the edge nodes to configure the data processing rules of the edge nodes in the non-virtual environment according to the original CDN edge strategy, and to configure the data verification rules of the edge nodes in the edge connectors according to the edge connector strategy; the edge connector is the computing power resource deployed by the edge nodes in the virtual environment; when a data request is received, a data request is sent to the edge nodes to instruct the edge nodes to determine the matching result between the data verification rules and the data request, and to determine the target data product corresponding to the data request from the data products of the target data provider according to the matching result and the data processing rules; the target data product is then sent to the data user.

[0076] The aforementioned data distribution method is applied to the content library connector of the CDN content library node. Since the content library connector includes computing resources within the virtual environment, it forms a data processing mechanism isolated from the native CDN. In this case, the content library connector obtains a data request, determines the data user to which the data request belongs based on the data request, making the data transmission process traceable; then, it determines the target edge node suitable for the data request from among the edge nodes; it sends the data request to the target edge node to instruct the edge connector of the target edge node to determine the target data product matching the data request, and sends the target data product to the data user. Thus, the edge node has an edge connector, which includes the edge node's computing resources in the virtual environment; the content library connector and the standard caching sublayer of the content library node form a two-layer architecture, and the edge connector and the CDN standard caching sublayer also form a two-layer architecture, centrally processing the data connectivity steps without modifying the CDN standard caching sublayer.

[0077] Specifically, without modifying the CDN standard caching sublayer, content library connectors are deployed using computing resources within a virtual environment. Therefore, the connectors are no longer single-point deployed software systems; data providers and users no longer need to maintain independent connector instances. Instead, the CDN directly executes the corresponding processing steps. When data products are delivered to a large number of users with high concurrency, such as in scenarios involving public data openness, government data sharing, and cross-enterprise supply chain data collaboration, the bandwidth, computing, and storage resource bottlenecks of distributed connectors are reduced, enabling the execution of large-scale connector cluster scheduling mechanisms. Furthermore, CDN possesses globally distributed nodes and millisecond-level content distribution capabilities, quickly pushing content to the nearest node to the user. It also has the connectivity capabilities required for data circulation, extending data delivery capabilities to distributed cluster delivery, supporting high-concurrency data access requests, and reducing the delivery latency of target data products.

[0078] In some embodiments, because connectors in the existing Trusted Data Space standard are deployed as a single point, one participant corresponds to one connector instance and one connector ID. When data providers utilize CDN for large-scale data delivery, the content library connector actually runs on multiple edge nodes, forming multiple physical instances. These physical instances must be presented externally as a unified logical connector to be compatible with the existing Trusted Data Space standard and to ensure that data users, service platforms, and functional nodes are unaware of the underlying distributed deployment details.

[0079] Therefore, such as Figure 4 As shown, in this embodiment, the identity information of the logical connector corresponds to a mapping management mechanism for multiple physical instances; correspondingly, determining the target edge node for data request adaptation from each edge node includes:

[0080] Step 402: Determine the identity information of the edge connector based on the data request, and determine each edge node corresponding to the identity information.

[0081] Identity information corresponds to logical connector identifiers for multiple edge nodes. Each edge node has its own physical instance, thus identity information forms the intermediate layer data. Optionally, identity information can be a decentralized identifier (DID), which is an identifier generated, owned, and controlled by an identity subject (such as a data provider, data user, or trusted connector). Its standard format is decentralized identifier:<method name>:<method-specific identifier>. In this embodiment, the decentralized identifier is an important identity credential for each participant in the trusted data space. The trusted data space service platform is responsible for the registration of decentralized identifiers and public key distribution for participants. During data circulation, the participants' decentralized identifiers are encoded in identity tokens (JWTs) for verification by edge node content library connectors. These tokens also serve as the fundamental basis for whitelist matching when executing strategies such as limiting data users and data usage connectors in digital contracts, forming the foundation for decentralized and verifiable identity management.

[0082] The identity token (JSONWebToken, JWT) is a compact token based on the JSON format and an open standard, used to securely transmit claim information between parties. In this embodiment, the JWT carries and transmits the requester's identity and authorization information, specifically as the content of the HTTP extension header field X-TDS-Identity-Token. An identity token consists of three parts: a header, a payload, and a signature. The payload contains key claims such as the issuer, subject (i.e., the requester's DID), audience, and associated contract ID. This token is issued by the Trusted Data Space Service Platform using its private key. In the TEE environment, the edge connector uses the public key distributed by the service platform to verify the JWT signature, ensuring the token's integrity and authenticity, and securely extracting information such as the requester's DID for subsequent access control policy evaluation.

[0083] This allows content library connectors to use less data as a registration management hub, maintaining a logical-physical mapping table that records information such as node identifier, node type (content library / edge), geographical region, online status, and capability description for each physical instance. When a CDN node deploys a new trusted connector sublayer or removes it, it automatically initiates registration or deregistration with the content library node. The content library node then synchronizes the updated logical connector information to the connector management module of the service platform. The service platform only registers identity information and its aggregation capability description with regional or industry functional nodes, without exposing physical instance details.

[0084] In some embodiments, at the identity level, identity information is the identity credential shared by all physical instances using the same logical connector, including the connector certificate and signing key. This credential is issued by the service platform, received uniformly by the content library nodes, and then securely distributed to the TEE environment of each physical instance through a trusted channel within the CDN for storage. Each physical instance uses the identity information for identification and signing when performing operations such as identity authentication, contract interaction, and evidence signing. The local instance identifier of the physical instance itself is only used in the delivery node field of CDN internal management, routing decisions, and evidence storage records for operation and maintenance location and audit tracing, and is not exposed externally.

[0085] In some embodiments, the logical-physical mapping table records the correspondence between edge connector identifiers and each edge node, as well as the functional description information of the identity information, so as to determine the identity information of the edge connector and the corresponding edge node based on the data request and the logical-physical mapping table. Optionally, the logical-physical mapping table is used to record information such as the node identifier, node type (content library / edge), geographical region, online status, and capability description of each physical instance.

[0086] In some embodiments, the identity information of an edge connector is generated based on the edge connector identifier, the key corresponding to the edge connector identifier, and the functional description information of the edge connector identifier; and / or, the identity information is stored on at least one of the content library nodes and edge nodes, and is used to interact with functional nodes. The connector identity information includes the connector identifier, key, and capability description. The connector identity information is uniformly registered by the service platform during initial deployment, and the identity credentials are cached locally on the CDN nodes after registration. Only the identity information is exposed when interacting with regional / industry functional nodes.

[0087] Step 404: Based on the data user and the running status of each edge node, filter each edge node to obtain the target edge node that matches the data request.

[0088] The operational status refers to the working condition of an edge node, representing its processing capability in distributing data requests and responding to results. Optionally, the operational status of an edge node can be determined based on information reported periodically by the edge node.

[0089] In some embodiments, the weight of each edge node can be determined based on the data user; the operating status of each edge node is mapped according to its weight to obtain a score for each edge node; and the target edge node for data request adaptation is determined based on the score of each edge node. Thus, the mapping table stored in the content library connector records the weights between different data users and edge nodes. Using these weights to measure the degree of adaptation between data users and edge nodes can improve processing efficiency.

[0090] In some embodiments, the edge nodes are filtered according to the data user and the running status of each edge node to obtain the target edge node that matches the data request, including: determining the deliverable node in each edge node based on the target digital contract indicated by the data request and the load and health status of each edge node; and filtering each deliverable node according to the location of the data user to obtain the target edge node that matches the data request.

[0091] The target digital contract is the digital contract specified by the data request; the digital contract corresponding to this request can be determined by the description contained in the data request. When there is a one-to-one correspondence between digital contracts and data products, the target data contract can be determined by the data product identified by the request.

[0092] A deliverable node is an edge node whose operational status supports the distribution of data requests. The operational status of a deliverable node is assessed based on its load and health status; load represents the amount of distribution work undertaken by the edge node, indicating whether the edge node has sufficient resources to receive new tasks; health status indicates whether the edge node is in a normal operating state, indicating the stability of the edge node's operation.

[0093] Optionally, the load is composed of indicators such as CPU utilization, memory usage, and network bandwidth usage in the virtual environment, while the health status is composed of indicators such as hardware failure rate, number of system anomalies, and storage lifetime of the edge nodes. Through data normalization and weighted fusion, the operating status value of the edge nodes can be obtained; edge nodes with operating status values ​​higher than a threshold are determined to be deliverable nodes. Thus, based on the data relationship between the two, the misjudgment problem of relying solely on factors such as computing resource usage can be avoided, and the operating status of devices in the edge environment can be more accurately assessed to achieve corresponding task allocation.

[0094] The location of the data user refers to the geographical location of the device used by the data user; optionally, the location of the data user can be a region or location information with a preset area precision. By knowing the location of the data user, the nearest edge device can be selected to process relevant events of the edge node, ensuring processing efficiency.

[0095] Therefore, the control strategies contained in digital contracts include the available edge nodes, forming a preset specified strategy. Furthermore, the load and health status of the edge nodes reflect their operational status, allowing for more accurate measurement of operational status. Moreover, further filtering based on the location of the data user ensures processing efficiency.

[0096] In this embodiment, the identity information contained in the data request corresponds to multiple edge nodes. Without modifying the standard interface definition of the trusted data space, the single-point connector is extended into a distributed cluster, realizing the elastic scaling of the connector. When expanding more edge nodes, the logical identity remains consistent externally without modifying the identity information, which helps to ensure processing efficiency.

[0097] In some embodiments, the method further includes: obtaining the access increment of each edge node; determining whether the global access volume corresponding to each access increment meets the quota condition; if the quota condition is met, the data consistency of each edge node is strong consistency; if the quota condition is not met, the data consistency of each edge node is eventual consistency.

[0098] Access increments include the change in access volume for each edge node, which can be an increase or decrease in access volume. Access volume can be the number of times or frequency that a user sends a data request to that edge node. Access increments can be determined based on the number of data requests received by the edge node; for example, access volume information can be determined based on access volume over a period of time.

[0099] Global access count includes the cumulative access count received by each edge node corresponding to the content repository node; it reflects the busy level of the content repository node. Global access count can be the sum of access increments and can be updated periodically.

[0100] Quota conditions are control conditions for data consistency. When the quota condition is met, excessive global access volume can reduce the data consistency requirement; when the quota condition is not met, moderate global access volume can increase the data consistency requirement. Optionally, the quota condition is met when the global access volume exceeds the quota threshold; the quota condition is not met when the global access volume is less than the quota threshold.

[0101] Data consistency refers to the degree to which data resources or data products across multiple edge nodes remain in the same state. Due to the large number of edge nodes, the data synchronization process between each edge node takes a long time, so quota conditions are used for flow control.

[0102] Strong consistency means that after each edge node updates its data, the data of the edge nodes corresponding to the same content library node are all the updated data. Eventual consistency means that when each edge node updates its data and there are no subsequent updates within a preset period, the data of the edge nodes corresponding to the same content library node are synchronized based on the data of the last update operation.

[0103] In one exemplary embodiment, the access increment is a distributed usage count. Each edge node maintains its local access count and periodically reports the increment to the CDN's content repository node via an internal CDN channel. The CDN's content repository node aggregates the global count and pushes it back to each edge node. Under normal mode, this is eventually consistent. When the global count approaches the limit threshold, each edge node switches to a strongly consistent mode that queries the CDN's content repository node in real time to ensure that the usage count does not exceed the limit.

[0104] In this embodiment, the access increment enables the content library node to determine the global access volume more efficiently. By coordinating the data consistency of each edge node through the global access volume, the probability of data anomalies in the CDN is reduced.

[0105] In some embodiments, the method further includes: obtaining a digital contract between a candidate data user and a data provider based on a contract deployment request, and parsing a control policy from the digital contract; determining an edge connector policy in the control policy, and sending the edge connector policy to an edge node, so that the edge node, based on the edge connector policy, determines the target data product determination step when the data request verification is valid.

[0106] A contract deployment request instructs the content library connector to establish a digital contract. The control rules and digital contract identifier within the digital contract can be determined based on the data carried in the contract deployment request. Candidate data users are the end-users to whom the digital contract will be established. After the digital contract is established, the candidate data user becomes a data user, who can then access and use the data provider's data products according to the digital contract. A data provider is the server or terminal used to provide data content and data products.

[0107] Edge connector strategies are used to verify the validity of data requests and to determine target data products. Optionally, data verification rules for edge nodes in edge connectors can be configured, and data requests can be verified based on these rules; data control rules for edge nodes in edge connectors can also be configured, and data requests can be matched and distributed based on these rules.

[0108] In some embodiments, such as limiting usage duration, limiting availability, and destroying data after use, are classified as edge data processing strategies and compiled into CDN native configuration rules; while edge connector strategies that need to be verified in real time in a trusted execution environment include, but are not limited to, limiting user identity, limiting the number of uses, and limiting usage operations; edge connector strategies are compiled into edge connector strategy packages.

[0109] In an optional embodiment, a digital contract for a data product is described, comprising: a data user querying a data product catalog through a trusted data space service platform, selecting a target data product, and submitting a usage application; the data user and the data provider signing a digital contract through the service platform; the contract stipulating terms such as the scope of data use, access frequency, validity period, and delivery area, and confirmed by digital signatures of both parties; and the service platform distributing the signed digital contract to the content library connector. The contract policy compiler in the content library connector parses the digital contract within the TEE environment, classifying and compiling each control policy clause in the contract.

[0110] In one embodiment, such as Figure 5 As shown, it includes: Step 502, the trusted data space generates a data contract and distributes the data contract to the CDN; Step 504, the CDN's content library connector contract policy compiler parses the complete data contract to obtain all control policies; Step 506, each control policy is classified to obtain the edge data processing policy for CDN native capabilities and the edge connector policy for real-time verification at the connection sublayer. The edge data processing policy is Type A, as shown in Table 1; the edge connector policy is Type B, as shown in Table 2. Tables 1 and 2 are as follows:

[0111] Table 1

[0112]

[0113] Table 2

[0114]

[0115] In this embodiment, the contract strategy compilation function is decentralized to the content library node, so that the parsing, classification and distribution of contract strategies are all completed within the CDN domain, which reduces the frequency of interaction with the service platform and improves the efficiency of strategy distribution.

[0116] In some embodiments, such as Figure 6 As shown, this application also provides a data distribution method applied to an edge connector of an edge node in a CDN. The edge connector includes computing resources in a virtual environment, and the edge connector has a corresponding content library node in the CDN. The method includes:

[0117] Step 602: Obtain the data request sent by the content library node; the data request includes the transparent extended data.

[0118] Extended data is unmodified data from the content library nodes, and it includes transparently transmitted data in the extended header. In some embodiments, trusted data space interaction semantics are transparently transmitted in the CDN standard request / response flow. Optionally, extended data is data contained in an extended header prefixed with X-TDS-. CDN intermediate nodes (L1 / L2 cache nodes) transparently forward these header fields without processing them, and they are only parsed and consumed in the final edge connector to form the corresponding response header extended fields.

[0119] In one embodiment, the content library connector acquires a data request; the content library connector determines the data user to which the data request belongs based on the data request; the content library connector determines the target edge node to which the data request is adapted from each edge node; the edge node is equipped with an edge connector, and the edge connector includes the computing power resources of the edge node in the virtual environment; the content library connector sends a data request to the target edge node, at which time the edge connector acquires the data request sent by the content library node and parses the extended data in the data request.

[0120] In one embodiment, the JWT signature in the extended data is verified within the edge node TEE environment, and the public key required for signature verification is uniformly distributed by the service platform and rotated periodically; all extended data does not affect the standard HTTP semantic processing of CDN (such as 304 Not Modified, Range requests, etc.).

[0121] Step 604: Obtain interaction semantics from extended data, and determine the target data product to match the data request based on the interaction semantics.

[0122] Interaction semantics represents the data request requirement, which can be semantics added by the data user. Interaction semantics can be determined based on the fields of the extended data; the target data product matching the data request is determined based on the digital contract and / or identity information in the interaction semantics.

[0123] Optionally, the uses of the extended data and the parsed interactive semantics are shown in Table 3, as follows:

[0124] Table 3

[0125]

[0126] In some embodiments, obtaining interaction semantics from the extension head and determining the target data product matching the data request based on the interaction semantics includes: determining the target digital contract identifier and the target data product identifier based on the extension data in the data request; adjusting the data product represented by the target data product identifier according to the target digital contract identifier to obtain the target data product matching the data request; wherein the target digital contract identifier represents the processing method of the data product.

[0127] In one embodiment, when a request carrying the X-TDS-Contract-ID is matched against the CDN cache, the contract ID needs to be included in the calculation of the cache key. This is to adjust the data product represented by the target data product identifier according to the target digital contract identifier. This ensures that requests for the same data product from different contracts will not hit the same cache copy, and also meets the needs of different contracts that may require different preprocessing methods.

[0128] In one embodiment, the edge connector has a corresponding edge caching layer; the edge caching layer includes computing resources in a non-virtual environment. Adjusting the data product represented by the target data product identifier according to the target digital contract identifier to obtain the target data product matching the data request includes: searching for the ciphertext of the data product represented by the target data product identifier from the ciphertext of the data product stored in the edge caching layer; decoding the ciphertext of the data product represented by the target data product identifier according to the key associated with the target digital contract identifier to obtain the decrypted data product; and processing the decrypted data product according to the processing method corresponding to the target digital contract identifier. For example, within the TEE, ciphertext data is read from the CDN cache, decrypted using the key associated with the contract, preprocessing is performed according to the contract requirements (de-identification, anonymization, aggregation calculation, etc.), and then the processed data is delivered to the standard CDN sublayer for transmission.

[0129] In this embodiment, when performing CDN cache matching based on data requests carrying the aforementioned extended data, different processing methods are adaptively determined through different data contracts. This ensures that requests for the same data product from different contracts do not hit the same cache copy, thereby guaranteeing processing efficiency.

[0130] Step 606: Send the target data product to the data user.

[0131] In one embodiment, extended data in the response header can be determined based on extended data in the data request, and a target data product carrying this extended data can be sent to the data user. The extended fields of the response header when sending the target data product to the data user are shown in Figure 4, and Table 4 is as follows:

[0132] Table 4

[0133]

[0134] In this embodiment, a data request sent by a content library node is obtained; the extended header of the data request includes extended data; interaction semantics are obtained from the extended data, and the target data product matching the data request is determined based on the interaction semantics; the target data product is sent to the data user. Thus, trusted data space interaction semantics are transparently transmitted within the CDN standard protocol stack. CDN intermediate nodes forward the data as is without processing, and it is only parsed and consumed in the edge connectors of the nodes, achieving trusted control without reconstructing the CDN protocol stack.

[0135] In one embodiment, the above method can be implemented by a module, as described below:

[0136] Trusted Data Space Service Platform: Based on existing trusted data space standard technical requirements, it provides identity management, connector management, directory management, digital contract management, space management, and evidence storage and auditing functions. The service platform acts as a business node connecting to regional / industry functional nodes, achieving interconnectivity with data infrastructure.

[0137] CDN Platform and Nodes: The CDN network comprises two types of nodes: content library nodes and edge nodes. Each CDN node is logically divided into a standard CDN sublayer and a trusted connector sublayer. The standard CDN sublayer retains the original functions such as DNS resolution, GSLB global load balancing, cache management, origin server management, and log collection without modification. The trusted connector sublayer is deployed within the CDN node in the form of a secure container or TEE and includes six functional modules: identity proxy module, data gateway module, product management module, contract engine module, policy execution module, and evidence collection module. The trusted connector sublayer of the CDN content library node additionally undertakes coordination and management responsibilities such as contract policy compilation and distribution, physical instance registration management, and evidence aggregation and reporting, serving as a crucial hub for the CDN network to connect to the trusted data space service platform. The edge connector primarily performs runtime functions such as policy evaluation, data delivery control, and evidence collection.

[0138] The detailed design of the six modules of the CDN trusted connector sublayer includes:

[0139] The identity proxy module is used for connector identity management and requester authentication. Connector identity management refers to the unified registration of connector identities (connector identifier, key, capability description) by the service platform during initial deployment, with CDN nodes caching identity credentials locally after registration. When interacting with regional / industry functional nodes, only the edge connector identifier is exposed.

[0140] The Data Resource Gateway module acts as an intermediate layer for CDN origin pulls, connecting to the data provider's data system. Its functions include: Data source access, supporting various data source access protocols (such as HTTPS, FTP, etc.) and maintaining data resource access configurations locally on the CDN node; Encrypted origin pull, initiating a trusted origin pull when the CDN cache fails—connecting to the origin connector via a TLS tunnel, with the origin pull request header carrying the edge connector's identity credentials and associated contract ID. The origin connector verifies the identity and contract validity before delivering the data; and Ciphertext caching, encrypting and encapsulating the data retrieved from the origin pull before storing it in the CDN caching layer, ensuring that data is always stored in encrypted form within the CDN standard caching sublayer and decrypted only according to contract requirements within the content library connector's TEE environment.

[0141] The Data Product Management module manages data product information cached on edge nodes. Specific functions include: a local product catalog, which maintains a local directory of data products cached on this edge node, containing product identifiers, metadata, control policy summaries, etc.; product request matching, which, when a user accesses a specific data product via CDN, parses the product identifier carried in the X-TDS-Product-ID field of the request and matches it with the product configuration and association policies in the local catalog; and a catalog retrieval interface, which provides a local retrieval interface for data products, supporting other edge connectors and user connectors within the same CDN region to query the product catalog.

[0142] The contract engine module is used for local management and state maintenance of digital contracts. Its specific functions include: contract reception and parsing, which receives digital contracts and control policies issued by the service platform through the CDN internal control plane, parses them, and builds contract indexes and policy caches locally on the edge nodes; contract request matching, which, upon receiving a data access request, matches the corresponding set of control policies in the local cache based on the contract identifier carried in the X-TDS-Contract-ID field of the request header, and passes it to the policy execution module; and contract state synchronization, which supports distributed synchronization of contract states (effective, suspended, expired, terminated). When a contract is terminated, the service platform sends a contract termination instruction to the CDN management API. The CDN control plane then distributes the instruction to all relevant edge nodes, and the contract engine module on each node immediately marks the contract as invalid, rejecting subsequent requests carrying that contract ID.

[0143] The policy execution module is used to execute control policies within the TEE environment. It contains three sub-components:

[0144] The policy interpreter is used to parse control policies in digital contracts, supporting all policy types defined in the Trusted Data Space standard. All policy types include: restricted data content, restricted delivery connectors, restricted use connectors, restricted users, restricted use operations, restricted use counts, restricted use duration, restricted visibility, restricted availability, notification upon use, and destruction after use, etc.

[0145] The policy evaluator is used to compare the context information of the current request (requester DID, request time, request geographical location, request operation type, request connector identifier, etc.) with the policy constraints one by one in the virtual environment, and output the evaluation result of PASS / DENY / CONDITIONAL.

[0146] The data controller controls data release based on the evaluation results. If the evaluation passes, the encrypted data is read from the CDN cache within the TEE, decrypted using the contract-associated key, preprocessed according to contract requirements (de-identification, anonymization, aggregation calculation, etc.), and then delivered to the standard CDN sublayer for transmission. If the evaluation fails, a rejection response is returned.

[0147] Distributed usage count: For usage limit policies, the policy execution module adopts a distributed counting scheme: each edge node maintains a local access count and periodically reports the increment to the content library node through the CDN internal channel; the content library node aggregates the global count and pushes it back to each edge node. In normal mode, it achieves eventual consistency. When the global count approaches the limit threshold, each edge node switches to a strong consistency mode that queries the content library node in real time to ensure that the usage count does not exceed the limit.

[0148] The evidence collection module is used for the collection, aggregation, and reporting of evidence throughout the entire process. Its specific functions include: evidence record generation, which generates evidence records for each data delivery and usage behavior, including requester identity hash, contract identifier, data product identifier, operation type, timestamp, geographical location, policy evaluation results, edge connector identifier, and TEE remote verification report; data aggregation, which aggregates multiple evidence records within the same time window (e.g., 1 second) to generate aggregated data information, ensuring the immutability and efficient verification of the evidence; asynchronous batch reporting, which asynchronously uploads the aggregated evidence to the service platform's evidence auditing system in batches, with the upload frequency aligned with the CDN's real-time log stream (second-level), without affecting the main path latency of data delivery; and bidirectional synchronization, which simultaneously synchronizes evidence records to both the data provider connector and the data user connector through the CDN internal channel, supporting independent auditing and traceability by both parties.

[0149] In one exemplary embodiment, such as Figure 7As shown, the data circulation service process of this embodiment is divided into four stages, involving five participating roles: data provider, trusted data space service platform, content library node, edge node, and data user, as detailed below:

[0150] Phase one is the launch of data products, which specifically includes:

[0151] Step 1: The data provider submits a data product registration request to the Trusted Data Space Service Platform, including metadata descriptions, terms of use, pricing strategies, and other information. After approval, the service platform assigns a unique identifier to the data product and completes the registration process.

[0152] Step 2: The data provider uploads the data product content to the content library node. The content library connector performs integrity verification on the received data content and stores it.

[0153] Step 3: The content library node pushes the data product content to relevant edge nodes for pre-caching according to the CDN content distribution strategy to support subsequent local delivery.

[0154] Phase two involves contract signing and strategy dissemination, which specifically includes:

[0155] Step 4: The data user queries the data product catalog through the Trusted Data Space Service Platform, selects the target data product, and submits a usage application.

[0156] Step 5: The data user and the data provider sign a digital contract through the service platform. The contract stipulates the scope of data use, access frequency, validity period, delivery area, and other terms, and is confirmed by the digital signatures of both parties.

[0157] Step 6: The service platform will send the signed digital contract to the content library connector.

[0158] Step 7: The contract strategy compiler in the content library connector parses the digital contract within the TEE environment and categorizes and compiles the control strategies in the contract one by one. Among them, strategies that can be directly mapped to CDN native capabilities (such as limiting usage duration, limiting availability, and destroying data after use) are classified as edge data processing strategies and compiled into CDN native configuration rules; strategies that need to be verified in real time in a trusted execution environment (such as limiting user identity, limiting usage frequency, and limiting usage operations) are classified as edge connector strategies and compiled into edge connector strategy packages.

[0159] Step 8: The content library node distributes the edge data processing strategy to the standard CDN sublayer of the relevant CDN node through the CDN management plane, so that it takes effect as the native CDN configuration; and distributes the edge connector strategy to the relevant edge connector through the trusted channel inside the CDN, so that the edge node has the ability to execute the strategy locally.

[0160] Phase three is data access and trusted delivery, which specifically includes:

[0161] Step 9: The data user initiates an HTTPS request to the content library node, carrying X-TDS series extension headers, including trusted data space identity and authorization information such as the user connector ID, contract ID, and access token.

[0162] Step 10: The content library connector checks the X-TDS extension header in the request to verify the user's identity and the basic validity of the contract.

[0163] Step 11: After successful verification, the content library node forwards the request to the optimal edge node via the CDN internal network, based on factors such as the target data user's geographical location, edge node load, and contract delivery constraints. This forwarding process is transparent to the data user, who does not need to be aware of the actual service node.

[0164] Step 12: The edge node receives the forwarded HTTPS request, which retains the original X-TDS extension header information.

[0165] Step 13: The edge connector performs policy matching on the request based on the locally cached access control policy, and verifies whether the user's identity, contract permissions, access frequency, etc., comply with the policy rules.

[0166] Step 14: After successful policy matching, the edge node returns the data product content to the data user. The response header carries a unified edge connector identifier, making it impossible for the user to distinguish the actual delivery node.

[0167] Phase four involves delivery, evidence storage, and reporting, which specifically includes:

[0168] Step 15: After completing data delivery, the edge connector generates a delivery record, which includes information such as contract ID, user identifier, delivery time, data product identifier, delivery node identifier, and data volume. The record is then signed using the logical connector identity credentials.

[0169] Step 16: Each edge node periodically aggregates and reports its evidence storage records to the content library node. The content library connector then summarizes, deduplicates, and verifies the evidence storage records from each edge node.

[0170] Step 17: The content library node, acting as a logical connector, reports the aggregated evidence records to the Trusted Data Space Service Platform for contract performance auditing, metering and billing, and regulatory evidence storage.

[0171] Based on this, in this embodiment, the dual-sublayer architecture of CDN nodes specifically refers to deploying connectors within CDN nodes (including content library nodes and edge nodes) in the form of secure containers or TEEs without modifying the standard CDN caching sublayer. This includes six functional modules: identity proxy, data resource gateway, data product management, contract engine, policy execution, and evidence collection, fully implementing the six connector functions required by the Trusted Data Space standard. The content library connector additionally undertakes coordination and management responsibilities such as contract policy compilation and distribution, physical instance registration management, and evidence aggregation and reporting. The edge connector performs runtime policy evaluation and data delivery control.

[0172] It features a transparent HTTP protocol extension mechanism. Specifically, it designs X-TDS-series HTTP extension header fields to transparently transmit trusted data space interaction semantics within the CDN standard protocol stack. Intermediate CDN nodes forward the data as is without processing; it is only parsed and consumed in the trusted connector sublayer of the final CDN node. This achieves trusted control without reconstructing the CDN protocol stack. By incorporating the contract ID into the cache key calculation, it ensures differentiated processing of the same data product across different contracts.

[0173] The logical-physical mapping management of the distributed connector cluster specifically refers to proposing a registration management mechanism that assigns one edge connector identifier to multiple physical CDN node instances. With the content library node as the hub, it enables elastic scaling, geographic-aware routing, and automatic fault switching of the connector cluster, always presenting a unified logical connector identity to the outside world.

[0174] Leveraging the globally distributed nodes and scheduling capabilities of CDN, the data delivery capabilities of traditional single-point connectors are extended to distributed cluster delivery, supporting high-concurrency data access requests and reducing delivery latency. There's no need to build dedicated network infrastructure for the trusted data space; deployment can be quickly achieved directly using existing CDN nodes, significantly reducing the construction cost and timeline of national-level data circulation infrastructure. Evidence storage and auditing are integrated with the CDN log pipeline; evidence collection, aggregation, and reporting are executed asynchronously throughout, minimizing latency impact on the main data delivery path. Contract policy compilation functionality is decentralized to content library nodes, enabling contract policy parsing, classification, and distribution to be completed entirely within the CDN domain, reducing the frequency of interaction with the service platform and improving policy distribution efficiency.

[0175] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0176] Based on the same inventive concept, this application also provides a data distribution apparatus for implementing the data distribution method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more data distribution apparatus embodiments provided below can be found in the limitations of the data distribution method described above, and will not be repeated here.

[0177] In one embodiment, such as Figure 8 As shown, a data distribution device is provided, which is applied to a content library connector of a CDN content library node. The content library connector includes computing resources in a virtual environment, and the content library node has a corresponding CDN edge node. The device includes:

[0178] The acquisition module 802 is used to acquire a data request and determine the data user to which the data request belongs based on the data request;

[0179] An adaptation module 804 is used to determine the target edge node for the data request adaptation from each of the edge nodes; the edge node is provided with an edge connector, and the edge connector includes the computing power resources of the edge node in the virtual environment;

[0180] The sending module 806 is used to send the data request to the target edge node, so as to instruct the edge connector of the target edge node to determine the target data product matching the data request according to the data request, and send the target data product to the data user.

[0181] In one embodiment, the adapter module 804 is configured to:

[0182] Based on the data request, determine the identity information of the edge connector, and determine each edge node corresponding to the identity information;

[0183] Based on the data user and the running status of each edge node, the edge nodes are filtered to obtain the target edge node that matches the data request.

[0184] In one embodiment, the adapter module 804 is configured to:

[0185] Based on the target digital contract indicated by the data request, and the load and health status of each edge node, determine the deliverable nodes among the edge nodes;

[0186] Based on the location of the data user, each deliverable node is filtered to obtain the target edge node that the data request is adapted to.

[0187] In one embodiment, the device further includes a coordination module for:

[0188] Obtain the access increment for each of the aforementioned edge nodes;

[0189] Determine whether the global access volume corresponding to each access increment meets the limit condition;

[0190] If the aforementioned limit conditions are met, then the data consistency of each edge node is strong consistency.

[0191] If the threshold conditions are not met, the data consistency of each edge node is eventually consistent.

[0192] In one embodiment, the device further includes a configuration module for:

[0193] Based on the contract deployment request, obtain the digital contract between the candidate data user and the data provider, and parse the control strategy from the digital contract;

[0194] The edge connector policy in the control strategy is determined, and the edge connector policy is sent to the edge node so that the edge node, based on the edge connector policy, executes the determination step of the target data product when the data request verification is valid.

[0195] In one embodiment, such as Figure 9 As shown, a data distribution device is provided, comprising:

[0196] The acquisition module 902 is used to acquire the data request sent by the content library node; the data request includes transparent extended data;

[0197] The determination module 904 is used to obtain interactive semantics from the extended data and determine the target data product matching the data request based on the interactive semantics.

[0198] The response module 906 is used to send the target data product to the data user.

[0199] In one embodiment, the determining module 904 is configured to:

[0200] Based on the extended data in the data request, determine the target digital contract identifier and the target data product identifier;

[0201] According to the target digital contract identifier, the data product represented by the target data product identifier is adjusted to obtain the target data product that matches the data request;

[0202] The target digital contract identifier indicates the processing method of the data product.

[0203] Each module in the aforementioned data distribution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0204] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a data distribution method.

[0205] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0206] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0207] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0208] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0209] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0210] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0211] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0212] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A data distribution method, characterized in that, A content library connector applied to a content library node in a CDN, wherein the content library connector includes computing resources in a virtual environment, and the content library node has a corresponding CDN edge node, the method comprising: Obtain a data request, and determine the data user to which the data request belongs based on the data request; The target edge node for the data request adaptation is determined from each of the edge nodes; the edge node is equipped with an edge connector, and the edge connector includes the computing power resources of the edge node in the virtual environment; The data request is sent to the target edge node to instruct the edge connector of the target edge node to determine the target data product that matches the data request, and to send the target data product to the data user.

2. The method according to claim 1, characterized in that, Determining the target edge node for data request adaptation from among the edge nodes includes: Based on the data request, determine the identity information of the edge connector, and determine each edge node corresponding to the identity information; Based on the data user and the running status of each edge node, the edge nodes are filtered to obtain the target edge node that matches the data request.

3. The method according to claim 2, characterized in that, The step of filtering each edge node based on the data user and the operating status of each edge node to obtain the target edge node for the data request adaptation includes: Based on the target digital contract indicated by the data request, and the load and health status of each edge node, determine the deliverable nodes among the edge nodes; Based on the location of the data user, each deliverable node is filtered to obtain the target edge node that the data request is adapted to.

4. The method according to claim 1, characterized in that, The method further includes: Obtain the access increment for each of the aforementioned edge nodes; Determine whether the global access volume corresponding to each access increment meets the limit condition; If the aforementioned limit conditions are met, then the data consistency of each edge node is strong consistency. If the threshold conditions are not met, the data consistency of each edge node is eventually consistent.

5. The method according to claim 1, characterized in that, The method further includes: Based on the contract deployment request, obtain the digital contract between the candidate data user and the data provider, and parse the control strategy from the digital contract; The edge connector policy in the control strategy is determined, and the edge connector policy is sent to the edge node so that the edge node, based on the edge connector policy, executes the determination step of the target data product when the data request verification is valid.

6. A data distribution method, characterized in that, An edge connector applied to an edge node of a CDN, the edge connector including computing resources in a virtual environment, the edge connector having a corresponding CDN content library node, the method comprising: Obtain the data request sent by the content library node; the data request includes the transparent extended data; The interaction semantics are obtained from the extended data, and the target data product matching the data request is determined based on the interaction semantics. Send the target data product to the data user.

7. The method according to claim 6, characterized in that, The step of obtaining interaction semantics from the extended data and determining the target data product matching the data request based on the interaction semantics includes: Based on the extended data in the data request, determine the target digital contract identifier and the target data product identifier; According to the target digital contract identifier, the data product represented by the target data product identifier is adjusted to obtain the target data product that matches the data request; The target digital contract identifier indicates the processing method of the data product.

8. A data distribution device, characterized in that, A content library connector for CDN content library nodes, wherein the content library connector includes computing resources in a virtual environment, and the content library node has a corresponding CDN edge node, the device comprising: The acquisition module is used to acquire data requests and determine the data user to which the data request belongs based on the data requests; An adaptation module is used to determine the target edge node for the data request adaptation from each of the edge nodes; the edge node is provided with an edge connector, and the edge connector includes the computing power resources of the edge node in the virtual environment; The sending module is configured to send the data request to the target edge node, instructing the edge connector of the target edge node to determine the target data product matching the data request based on the data request, and send the target data product to the data user.

9. A data distribution device, characterized in that, An edge connector applied to an edge node of a CDN, the edge connector including computing resources in a virtual environment, the edge connector having a corresponding CDN content library node, the device comprising: The acquisition module is used to acquire data requests sent by the content library node; the data requests include transparent extended data. The determination module is used to obtain interactive semantics from the extended data and determine the target data product matching the data request based on the interactive semantics. The response module is used to send the target data product to the data user.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images