Domain Name Resource Data Distribution Method, Device, Computer Equipment and Storage Medium

Abstract

An embodiment of the present application provides a domain name resource data distribution method, device, computer device, and storage medium. The method includes: receiving multiple performance test data sent by each measurement service node; determining the historical performance score of each edge node at each historical time point according to the performance test data at each historical time point; for each historical time point, constructing a corresponding sub-feature vector by combining the historical performance score and the attribute parameters of the domain name resource data; splicing multiple sub-feature vectors in chronological order to obtain a target feature vector, and outputting the scheduling weight of each edge node based on the target feature vector through a target model; when receiving a domain name resource data acquisition request, allocating at least one domain name resource data acquisition request to at least one of the multiple edge nodes according to the scheduling weight of each edge node for domain name resource distribution. In this way, the efficiency and stability of the domain name resource data distribution process can be improved.

Description

Technical Field

[0001] This application relates to the field of network communication technologies, and particularly to a method, apparatus, computer device, and storage medium for distributing domain name resource data. Background Art

[0002] Domain name resolution is the process of converting an easy-to-remember domain name into an Internet Protocol (IP) address that can be recognized by a computer. When a user enters a domain name in a browser, the browser sends a query request to the local Domain Name System (DNS) server. The DNS server then queries the root server, top-level domain server, authoritative server, etc., and finally obtains the IP address corresponding to the input domain name and returns it to the user's device. This process enables users to conveniently and quickly access various resources on the Internet without directly memorizing complex IP addresses.

[0003] In related technologies, domain name resolution is usually implemented by a single site obtaining it independently. Specifically, in the scenario of distributing domain name resource data in a specific area, all clients (such as root server instances, authoritative servers, etc.) directly send requests to a designated centralized server and download data. The centralized server provides the latest domain name resource data (such as root zone files, top-level domain information) through a fixed IP address or a single domain name, and the clients pull data from this node in a periodic polling or event-triggered manner to complete the process of distributing domain name resource data. However, on the one hand, this solution completely depends on the stability and network connectivity of a single node. When accessing across regions, the network latency is large, resulting in low efficiency of distributing domain name resource data; on the other hand, once the node experiences hardware failures, network interruptions, or is attacked, all clients in this area will be unable to obtain domain name resource data, and the domain name resource data distribution service will be completely paralyzed, and the stability of the distribution process is poor. Summary of the Invention

[0004] This application proposes a method, apparatus, computer device, and storage medium for distributing domain name resource data, which can improve the efficiency and stability of the process of distributing domain name resource data.

[0005] To achieve the above object, in the first aspect of the embodiments of this application, a method for distributing domain name resource data is proposed, which is applied to a domain name resource server, and the domain name resource server stores corresponding domain name resource data. The method includes:

[0006] Receiving multiple performance test data sent by each measurement service node, where each performance test data is obtained by the measurement service node testing the managed edge nodes at different historical time points, and the edge nodes synchronously store the domain name resource data;

[0007] Determine the historical performance scores of the edge nodes corresponding to each measurement service node at each historical time point according to the performance test data at each historical time point;

[0008] For each historical time point, combine the historical performance scores of each edge node and the attribute parameters for the stored domain name resource data to construct a sub-feature vector corresponding to each historical time point;

[0009] Concatenate the sub-feature vectors corresponding to multiple historical time points in chronological order to obtain a target feature vector, and output the scheduling weights of each edge node based on the target feature vector through a pre-trained target model;

[0010] When receiving at least one domain name resource data acquisition request, allocate the at least one domain name resource data acquisition request to at least one of the multiple edge nodes according to the scheduling weights of each edge node, so that the at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request.

[0011] Correspondingly, a second aspect of the embodiments of the present application proposes a domain name resource data distribution device, which is applied to a domain name resource server, and the domain name resource server stores corresponding domain name resource data. The device includes:

[0012] A receiving module, configured to receive multiple performance test data sent by each measurement service node, and each performance test data is obtained by the measurement service node testing the managed edge node at different historical time points, and the edge node synchronously stores the domain name resource data;

[0013] A determining module, configured to determine the historical performance scores of the edge nodes corresponding to each measurement service node at each historical time point according to the performance test data at each historical time point;

[0014] A constructing module, configured to, for each historical time point, combine the historical performance scores of each edge node and the attribute parameters for the stored domain name resource data to construct a sub-feature vector corresponding to each historical time point;

[0015] A concatenating module, configured to concatenate the sub-feature vectors corresponding to multiple historical time points in chronological order to obtain a target feature vector, and output the scheduling weights of each edge node based on the target feature vector through a pre-trained target model;

[0016] An analysis module, configured to, when receiving at least one domain name resource data acquisition request, allocate the at least one domain name resource data acquisition request to at least one of multiple edge nodes according to the scheduling weight of each edge node, so that the at least one edge node distributes domain name resource data based on the at least one domain name resource data acquisition request.

[0017] In some embodiments, the domain name resource data distribution device further includes a calculation module, configured to:

[0018] At the same historical time point, determine the domain name resource test data of each edge node from multiple performance test data returned by the multiple edge nodes;

[0019] For the domain name resource test data corresponding to each edge node, calculate the corresponding domain name resource hash value;

[0020] Based on the comparison of multiple domain name resource hash values, when the comparison result indicates that the domain name resource hash value of at least one edge node is inconsistent with the domain name resource hash values of other edge nodes, adjust the scheduling weight of the at least one edge node through a preset penalty factor to obtain the corresponding first scheduling weight;

[0021] Based on the first scheduling weight, adjust the scheduling weights of the other edge nodes to obtain the second scheduling weights of the other edge nodes;

[0022] Then the allocating the at least one domain name resource data acquisition request to at least one of multiple edge nodes according to the scheduling weight of each edge node, so that the at least one edge node distributes domain name resource data based on the at least one domain name resource data acquisition request includes:

[0023] Allocate the at least one domain name resource data acquisition request to at least one of multiple edge nodes according to the first scheduling weight or the second scheduling weight of each edge node, so that the at least one edge node distributes domain name resource data based on the at least one domain name resource data acquisition request.

[0024] In some embodiments, the determination module is further configured to:

[0025] According to the performance test data of each historical time point, obtain the time delay data, packet loss rate data, and transmission jitter data of the edge node corresponding to each measurement service node at each historical time point;

[0026] Obtain the first weight corresponding to the time delay data, the second weight corresponding to the packet loss rate data, and the third weight corresponding to the transmission jitter data, and respectively adjust the time delay data, the packet loss rate data, and the transmission jitter data according to the first weight, the second weight, and the third weight to obtain the corresponding target time delay data, target packet loss rate data, and target transmission jitter data;

[0027] Based on the target time delay data, the target packet loss rate data, and the target transmission jitter data, obtain the historical performance scores of the corresponding edge nodes at each historical time point.

[0028] In some embodiments, the domain name resource data distribution device further includes an acquisition module for:

[0029] Obtain historical time periods corresponding to multiple historical time points, and determine the data occupancy of the domain name resource data, the update frequency within the historical time period, and the data type during the historical time period;

[0030] Based on the data occupancy, the update frequency, and the data type, determine the attribute parameters corresponding to the stored domain name resource data.

[0031] In some embodiments, the domain name resource data distribution device further includes a training module for:

[0032] Receive multiple sample performance test data sent by each measurement service node. Each sample performance test data is obtained by the measurement service node testing the managed edge node at different sample time nodes, and the sample domain name resource data is synchronously stored in the edge node;

[0033] According to the sample performance test data at each sample time point, determine the sample historical performance scores of the edge nodes corresponding to each measurement service node at each sample time point;

[0034] For each sample time point, combine the sample historical performance scores of each edge node and the sample attribute parameters for the stored sample domain name resource data to construct a sample sub-feature vector corresponding to each sample time point;

[0035] Concatenate the sample sub-feature vectors corresponding to multiple sample time points in chronological order to obtain a sample target feature vector, and output the predicted scheduling weight of each edge node based on the sample target feature vector through a preset model;

[0036] For each edge node, obtain the sample scheduling weight of each edge node, and construct a target loss based on the difference between the predicted scheduling weight and the sample scheduling weight corresponding to each edge node;

[0037] Adjust the parameters of the preset model based on the target loss to obtain a target model.

[0038] In some embodiments, the domain name resource data distribution device further includes a processing module for:

[0039] Input the target feature vector into the target model, and perform high-dimensional feature extraction on the target feature vector through the initial convolutional layer of the target model to obtain a first feature vector;

[0040] Process the time dependence relationship of the first feature vector through the first residual block of the target model to obtain a second feature vector, and fuse the first feature vector and the second feature vector to obtain a third feature vector output by the first residual block. Each residual block includes a plurality of dilated convolutional layers, and the number of dilation factors included in the plurality of dilated convolutional layers is configured according to the position of the corresponding residual block. The dilation factor is used to determine the time series analysis range of the first feature vector;

[0041] Process the time dependence relationship of the third feature vector through the intermediate residual blocks of the target model to obtain an updated second feature vector, and fuse the third feature vector and the updated second feature vector to obtain an updated third feature vector output by the intermediate residual block;

[0042] When the updated third feature vector is output by the last intermediate residual block, perform feature compression processing on the third feature vector through the global pooling layer of the target model to obtain a fourth feature vector;

[0043] Perform output mapping on the fourth feature vector through the fully connected layer of the target model to obtain the scheduling weight of each edge node.

[0044] Correspondingly, a third aspect of the embodiments of the present application proposes a domain name resource data distribution method, which is applied to a measurement service node. The method includes:

[0045] Test the managed edge nodes at different historical time points to obtain corresponding performance test data. The edge nodes synchronously store the domain name resource data stored by the domain name resource server;

[0046] Send multiple performance test data to the domain name resource server, so that after the domain name resource server receives the multiple performance test data sent by each measurement service node, it determines the historical performance scores of the edge nodes corresponding to each measurement service node at each historical time point according to the performance test data at each historical time point, and for each historical time point, combines the historical performance scores of each edge node and the attribute parameters of the stored domain name resource data to construct a sub-feature vector corresponding to each historical time point, and splices the sub-feature vectors corresponding to the multiple historical time points in chronological order to obtain a target feature vector, and outputs the scheduling weights of each edge node based on the target feature vector through a pre-trained target model. When receiving at least one domain name resource data acquisition request, allocate the at least one domain name resource data acquisition request to at least one of the multiple edge nodes according to the scheduling weights of each edge node, so that the at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request.

[0047] Correspondingly, a fourth aspect of the embodiments of the present application proposes a computer device, which includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the domain name resource data distribution method according to any one of the embodiments of the first aspect or the second aspect of the present application.

[0048] Correspondingly, a fifth aspect of the embodiments of the present application proposes a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, it implements the domain name resource data distribution method according to any one of the embodiments of the first aspect or the second aspect of the present application.

[0049] In an embodiment of the present application, multiple performance test data sent by each measurement service node are received. Each performance test data is obtained by the measurement service node testing the managed edge nodes at different historical time points, and the edge nodes synchronously store domain name resource data. According to the performance test data at each historical time point, the historical performance score of the edge node corresponding to each measurement service node at each historical time point is determined. For each historical time point, a sub-feature vector corresponding to each historical time point is constructed by combining the historical performance score of each edge node and the attribute parameters for the stored domain name resource data. The sub-feature vectors corresponding to multiple historical time points are concatenated in chronological order to obtain a target feature vector, and the scheduling weight of each edge node is output by a pre-trained target model based on the target feature vector. When at least one domain name resource data acquisition request is received, the at least one domain name resource data acquisition request is allocated to at least one of the multiple edge nodes according to the scheduling weight of each edge node, so that at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request. In this way, the performance test data of each edge node can be collected by the measurement service node and converted into historical performance scores, enabling the system to grasp the network status of each edge node at different historical time points in real time. Then, the historical performance scores and the attribute parameters of the domain name resource data are fused to construct sub-feature vectors, and the sub-feature vectors corresponding to multiple historical time points are concatenated in chronological order and input into the target model, enabling the target model to fully learn the time-dependent features of the target feature vector and capture the performance changes of each edge node at different historical time points, and then predicting the scheduling weights of each edge node at the current moment. Thus, when a domain name resource data acquisition request is received subsequently, the request can be dynamically allocated according to the scheduling weight of each edge node, which not only realizes the reasonable distribution of traffic, avoids the performance bottleneck of a single node, but also enhances the fault tolerance and stability of the system through the collaborative work of the edge nodes, thereby ensuring the efficient and reliable operation of the resolution service even in a cross-regional scenario. In summary, the present application can improve the efficiency and stability of the domain name resource data distribution process. Description of the Drawings

[0050] Figure 1 is a schematic architecture diagram of the domain name resource data distribution system provided by an embodiment of the present application;

[0051] Figure 2 is a flowchart of the domain name resource data distribution method provided by an embodiment of the present application;

[0052] Figure 3 is a model structure diagram provided by an embodiment of the present application;

[0053] Figure 4 is a flowchart of data verification provided by an embodiment of the present application;

[0054] Figure 5 It is a schematic diagram of the functional modules of the domain name resource data distribution device provided by an embodiment of the present application;

[0055] Figure 6 It is a schematic diagram of the hardware structure of the computer device provided by an embodiment of the present application. Detailed implementation manners

[0056] In order to make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0057] It should be noted that although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order from the module division in the device or the order in the flowchart. Terms such as "first" and "second" in the specification, claims and the above-mentioned drawings are used to distinguish similar objects and do not necessarily need to describe a specific order or sequence.

[0058] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0059] Domain name resolution is the process of converting an easily memorable domain name into an Internet Protocol (IP) address that can be recognized by a computer. When a user enters a domain name in a browser, the browser sends a query request to the local Domain Name System (DNS) server. The DNS server then queries the root server, top-level domain server, authoritative server, etc., and finally obtains the IP address corresponding to the entered domain name and returns it to the user's device. This process enables users to access various resources on the Internet conveniently and quickly without directly memorizing complex IP addresses.

[0060] In the related art, domain name resolution is usually implemented by a single site independently obtaining data. Specifically, in the scenario of distributing domain name resource data in a specific region, all clients (such as root server instances, authoritative servers, etc.) directly send requests to a designated centralized server and download data. This centralized server provides the latest domain name resource data (such as root zone files, top-level domain information) through a fixed IP address or a single domain name. The clients then pull data from this node in a periodic polling or event-triggered manner to complete the process of distributing domain name resource data. However, on the one hand, this solution completely relies on the stability and network connectivity of a single node. When accessing across regions, the network latency is large, resulting in low efficiency of distributing domain name resource data. On the other hand, once the node experiences hardware failures, network outages, or is attacked, all clients in this region will be unable to obtain domain name resource data, and the distribution service of domain name resource data will completely collapse, with poor stability in the distribution process.

[0061] Based on this, the embodiments of the present application provide a method, device, computer device, and storage medium for distributing domain name resource data, which can improve the efficiency and stability of the process of distributing domain name resource data.

[0062] The method, device, computer device, and storage medium for distributing domain name resource data provided by the embodiments of the present application are specifically described through the following embodiments. First, the domain name resource data distribution system in the embodiments of the present application is described.

[0063] Please refer to Figure 1 , in some embodiments, the embodiments of the present application provide a domain name resource data distribution system, including a domain name resource server, edge nodes, measurement service nodes, and clients.

[0064] Exemplarily, the domain name resource server can be the original release and storage location of domain name resource data. It is the core data source in the entire domain name resource data distribution system, responsible for generating, storing, and providing data for distribution to edge nodes. For example, it can generate and store root zone files, top-level domain resource data, and important domain name resource data, etc., and provide them to edge nodes for distribution. For example, the domain name resource server can be a data center server, a content management system, a database server, an application server, a cloud storage server, and so on.

[0065] Further, a multi-cloud fusion optimization scheduling module can be set inside the domain name resource server. It can determine the corresponding historical performance scores based on the performance test data at each historical time point, and then determine the corresponding time series features (i.e., sub-feature vectors) at each historical time point and perform fusion processing to obtain the target feature vector. The target feature vector is input into the target model for prediction to obtain the scheduling weights of each edge node. In this way, when a domain name resource data acquisition request is received subsequently, multi-cloud traffic scheduling and distribution can be performed among multiple edge nodes, and then domain name resource distribution can be carried out.

[0066] Exemplarily, an edge node can be a content delivery network (CDN) node of a cloud service provider, which can be a server or data center deployed globally by different cloud service providers for caching and distributing domain name resource data. By reasonably deploying and scheduling edge nodes, fast and reliable distribution of domain name resource data globally can be achieved to meet the needs of clients in different regions. As Figure 1 shown, the domain name resource data of the domain name resource server can be synchronized to multiple edge nodes in multiple cloud service providers.

[0067] Further, a measurement service node (also called a probing point) can be a specific device for periodically detecting and evaluating the service quality of edge nodes (i.e., CDN nodes of cloud service providers). There is at least one measurement service node in each region, which can collect and feedback the performance data of edge nodes, such as response time, packet loss rate, bandwidth, etc., by simulating the access behavior of clients. Exemplarily, a measurement service node can be a physical server, a virtual machine, an Internet of Things device, etc.

[0068] It can be understood that by periodically detecting the managed edge nodes through the measurement service node, it can be ensured that when any edge node fails or has a poor ability to process domain name resource data acquisition requests, the domain name resource data acquisition requests can be allocated by adjusting the scheduling weights of each edge node to ensure the efficiency and stability of domain name resource data distribution.

[0069] Exemplarily, a client can be a terminal user device or system located in a specific geographical area, which is the entity that finally receives and uses the domain name resource data distribution service. There is a corresponding client set in each region. A client can be any device or system such as a personal computer, a mobile device, an Internet of Things device, a smart TV, a vehicle-mounted system, etc. that can be connected to the network and needs to access domain name resource data.

[0070] The domain name resource data distribution method in the embodiments of this application can be illustrated by the following embodiments.

[0071] It should be noted that in each specific embodiment of the present application, when it comes to the need to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first. Moreover, the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0072] In the embodiment of the present application, the domain name resource data distribution device will be described from the perspective of the domain name resource data distribution device, which can be integrated into a computer device. Figure 2 , Figure 2 This is a flowchart of the steps of the domain name resource data distribution method provided in an embodiment of the present application. The domain name resource data distribution method can be applied to a domain name resource server, which stores the corresponding domain name resource data. In this embodiment of the present application, the domain name resource data distribution device is specifically integrated into a terminal or server as an example. When the processor on the terminal or server executes the program instructions corresponding to the domain name resource data distribution method, the specific process is as follows:

[0073] Step 101: Receive multiple performance test data sent by each measurement service node. Each performance test data is obtained by the measurement service node by testing the managed edge node at different historical time points. The edge node synchronously stores domain name resource data.

[0074] In some implementations, to accurately evaluate the service quality of each edge node, data obtained by a measurement service node performing performance tests on edge nodes at different historical time points may be collected to provide basic data support for subsequent historical performance score calculations of edge nodes.

[0075] The measurement service node can be a detection point or device located at a specific geographical location. Each area is configured with at least one measurement service node, which is used to send test requests to different edge nodes at regular intervals and determine performance test data based on the data returned by the corresponding edge nodes.

[0076] The performance test data may be data collected by the measurement service node from the corresponding edge node, including but not limited to time delay data, packet loss rate data and transmission jitter data, which is used to reflect the service quality of the edge node at a specific historical time point.

[0077] Among them, the historical time point can be the specific time when the measurement service node performs a performance test, and can be any past moment relative to the current time point.

[0078] Among them, the edge node can be a content delivery network node, which can be a multi-cloud service provider (such as CDN cache nodes of cloud service providers such as Amazon Web Services (AWS), Microsoft Cloud Platform, etc.), responsible for caching and providing stored domain name resource data to clients.

[0079] Among them, the domain name resource data can include root zone files, top-level domain resource data (such as.com / .cn, etc.), important domain name resource data (such as financial institution domain names), etc.

[0080] Exemplarily, the measurement service node can periodically test the performance of each edge node at each historical time point, send a test request for obtaining data to the edge node. After receiving the test request, the edge node will return corresponding response data to the measurement service node. The measurement service node can obtain the time delay data, packet loss rate data, and transmission jitter data of the edge node according to the response data. Alternatively, the measurement service node can also directly transmit the response data to the domain name resource server, and the domain name resource server calculates the performance test data of the corresponding edge node according to the response data.

[0081] In some embodiments, when it is necessary to calculate the scheduling weights of each edge node at the current time point according to the time period, the performance test data of the N (N can be set according to the actual situation, for example, it can be set to 8, 10, etc.) historical time points before the current time point can be obtained, so that the target model can learn the law of the performance test data changing with time, and then predict the scheduling weights.

[0082] In some embodiments, after the domain name resource server updates the domain name resource data, the edge nodes of all cloud service providers (such as Alibaba Cloud, Tencent Cloud, etc.) need to synchronize the latest version of the data to avoid parsing conflicts caused by data version differences between edge nodes (for example, when a certain edge node is not updated, the client may obtain expired authoritative information, leading to the risk of domain name hijacking).

[0083] By systematically collecting the performance test data from each measurement service node, the service quality situation of the edge nodes in the past time period can be comprehensively understood, thereby providing an accurate data basis for the optimization scheduling decision based on the target model.

[0084] Step 102, according to the performance test data of each historical time point, determine the historical performance scores of the edge nodes corresponding to each measurement service node at each historical time point.

[0085] In some embodiments, in order to provide the target model with structured input features having temporal relevance, the original performance test data can be converted into standardized historical performance scores to accurately quantify and evaluate the change trend of the service quality of different edge nodes in a historical period.

[0086] Among them, the historical performance score can be used to characterize the service ability of the corresponding edge node to the clients in a specific region at a historical time point.

[0087] In some embodiments, the time delay data, packet loss rate data, and transmission jitter data corresponding to the edge node can be determined through the response data returned by the edge node to the measurement service node, and the historical performance score of the corresponding edge node at each historical time point can be calculated by comprehensively combining the time delay data, packet loss rate data, and transmission jitter data.

[0088] Exemplarily, the historical performance score can be calculated by the following formula:

[0089] ;

[0090] Among them, 、 、 are the importance coefficients set for the time delay data, packet loss rate data, and transmission jitter data respectively. 、 、 The sum of 、 、 is 1, which is used to adjust the contribution degree of each index in the comprehensive evaluation. Specifically, the values of 、 、 can be adjusted according to the actual situation.

[0091] It can be understood that at all historical time points, the historical performance scores corresponding to each edge node can be calculated by the above formula, and will not be elaborated here one by one.

[0092] By calculating the historical performance scores of each edge node at each historical time point through the above method, it can be ensured that the scores can comprehensively reflect the historical performance of the edge nodes. Thereby, not only provides a scientific basis for traffic scheduling, but also improves the overall efficiency and reliability of the system, ensures that the domain name resource data can be distributed to users in each region more quickly and stably, and at the same time enhances the ability to respond to emergencies and security threats.

[0093] In some embodiments, in order to quantitatively evaluate the quality of service of edge nodes, the corresponding historical performance scores can be calculated by analyzing the performance test data collected by each measurement service node at different historical time points, so as to provide accurate data support for subsequent optimization of scheduling strategies. Exemplarily, step 102 may include:

[0094] (102.1) According to the performance test data of each historical time point, obtain the time delay data, packet loss rate data, and transmission jitter data of the corresponding edge nodes of each measurement service node at each historical time point;

[0095] (102.2) Obtain the first weight corresponding to the time delay data, the second weight corresponding to the packet loss rate data, and the third weight corresponding to the transmission jitter data, and respectively adjust the time delay data, packet loss rate data, and transmission jitter data according to the first weight, the second weight, and the third weight to obtain the corresponding target time delay data, target packet loss rate data, and target transmission jitter data;

[0096] (102.3) Based on the target time delay data, target packet loss rate data, and target transmission jitter data, obtain the historical performance scores of the corresponding edge nodes at each historical time point.

[0097] Among them, the time delay data may be the time required for a response data packet to be transmitted from an edge node to a measurement service node, and its unit may be milliseconds (ms), which is used to reflect the network transmission speed.

[0098] Among them, the packet loss rate data may be the proportion of response data packets lost during data transmission to the total number of sent response data packets, which is used to measure the reliability of network transmission.

[0099] Among them, the transmission jitter data may be the standard deviation measuring the fluctuation of the arrival time of response data packets, which is used to characterize the stability of network transmission.

[0100] Among them, the first weight may be the adjustment coefficient of the time delay data in the historical performance score, and its value range is [0, 1], which is used to amplify or suppress the influence of the time delay data on the historical performance score.

[0101] Among them, the second weight may be the adjustment coefficient of the packet loss rate data in the historical performance score, and its value range is [0, 1], which is used to amplify or suppress the influence of the packet loss rate data on the historical performance score.

[0102] Among them, the third weight may be the adjustment coefficient of the transmission jitter data in the historical performance score, and its value range is [0, 1], which is used to amplify or suppress the influence of the transmission jitter data on the historical performance score.

[0103] Among them, the target time delay data can be the normalized value of the time delay data (such as Min-Max scaled to the interval [0, 1]) and the first weight adjustment.

[0104] Among them, the target packet loss rate data can be the value directly applying the second weight adjustment to the packet loss rate data.

[0105] Among them, the target transmission jitter data can be the normalized value of the transmission jitter data (such as Z-Score normalization) and the third weight adjustment.

[0106] Exemplarily, the packet transmission time from the edge node to the measurement service node in the response data returned by the edge node can be recorded as the time delay data. Suppose at historical time point 1, 10 packets were sent in the response data returned by the edge node, and the measured delay time (unit: millisecond) of each packet is respectively: 50, 52, 48, 51, 49, 53, 47, 50, 52, 51. Calculate the average of these delay data to obtain the time delay data at this historical time point. (50 + 52 + 48 + 51 + 49 + 53 + 47 + 50 + 52 + 51) / 10 = 50.2 milliseconds.

[0107] Furthermore, the corresponding packet loss rate data can be determined by the proportion of the lost packets in the total number of packets included in the response data during the data transmission process. For example, if the response data contains 100 packets and 1 is lost, the packet loss rate is 1 / 100 = 1%.

[0108] Furthermore, the time interval of each packet from the edge node to the measurement service node in the response data can be recorded, and the difference between the arrival time intervals of adjacent packets can be calculated. Suppose the differences between the arrival time intervals of adjacent packets (unit: millisecond) are respectively: 3, 2, 4, 1, 3, 5, 2, 3, 4. Calculate the standard deviation of these differences to obtain the transmission jitter data at this historical time point.

[0109] In some embodiments, the historical performance score can be calculated by the following formula:

[0110] ;

[0111] Among them, is the first weight, is the second weight, is the third weight, 、 、 The sum of is 1, which is used to adjust the contribution degree of each index in the comprehensive evaluation, represents the time delay data, Indicates the packet loss rate data, Indicates the transmission jitter data.

[0112] Specifically, 、 、 The values of can be adjusted according to the actual situation. For example, can be 0.5, can be 0.3, can be 0.2, which indicates that the time delay data has the greatest impact on the quality of service.

[0113] By collecting, weight adjusting and comprehensively calculating the historical performance test data of the corresponding edge nodes of each measurement service node, the performance of the edge nodes at different times can be comprehensively and accurately quantified and evaluated. The obtained historical performance scores can effectively reflect their service quality, providing a key basis for subsequent operations such as traffic scheduling and performance optimization, helping to achieve reasonable allocation and efficient utilization of network resources, and improving the stability and reliability of the entire system.

[0114] Step 103, for each historical time point, combine the historical performance scores of each edge node and the attribute parameters for the stored domain name resource data to construct a sub-feature vector corresponding to each historical time point.

[0115] In some embodiments, in order to provide rich input information for the subsequent target model to more accurately predict and evaluate the service capabilities of different edge nodes, a sub-feature vector that can reflect the service quality of the edge nodes and the characteristics of the resources they carry at a specific historical time point can be constructed for each historical time point, so as to achieve more efficient traffic scheduling and domain name resource data distribution.

[0116] Among them, the attribute parameters can be a set of features describing the characteristics of the domain name resource data, including but not limited to data size, update frequency, data type (such as root zone file, top-level domain data or important domain name data), etc., used to quantitatively represent the characteristics of different types of domain name resource data.

[0117] Among them, the sub-feature vector can be a vector jointly composed of the historical performance scores of the edge nodes at a specific historical time point, the attribute parameters of the domain name resource data that needs to be allocated and resolved, and the corresponding historical time point, used to capture the service quality status of each edge node and the specific characteristics of the resources it carries at this historical time point.

[0118] Exemplarily, for the domain name resource data that needs to be allocated and resolved, its attribute parameters can be expressed as:

[0119] ;

[0120] Among them, represents the data occupancy of the domain name resource data, represents the update frequency of the domain name resource data, represents the data type of the domain name resource data. For example, when it is 1, it means that the domain name resource data that needs to be allocated and resolved after scheduling weight calculation is the root zone file, when it is 2, it means the top-level domain data, when it is 3, it means important domain name data.

[0121] Furthermore, the sub-feature vectors corresponding to each historical time point can be expressed as follows:

[0122] ;

[0123] Among them, represents the historical performance score set of k edge nodes at the historical time point t, represents the attribute parameters of the domain name resource data, represents the hour of the current historical time point. For example, when it is 14, it means 2 pm, is the week number of the current historical time point. For example, when it is 3, it means Wednesday, and jointly represent the corresponding historical time point.

[0124] By obtaining the sub-feature vectors corresponding to each historical time point, the target model can learn the complex relationship between "data characteristics - network status - time period" simultaneously (for example: important domain name data (type = 3) has a higher demand for CDN bandwidth during the working hours in region A), so as to dynamically predict the optimal scheduling weights of each edge node under different types of domain name resource data, achieve adaptive scheduling based on data characteristics and spatio-temporal rules, and significantly improve the distribution real-time performance of domain name resource data (reduce the synchronization delay caused by large data volume or network congestion) and cross-regional consistency (avoid parsing errors caused by ignoring data type differences).

[0125] In some embodiments, in order to provide necessary inputs for constructing sub-feature vectors and data fusion processing based on temporal features, the attribute parameters of the domain name resource data can be determined by analyzing the data occupancy, update frequency, and data type of the domain name resource data within the historical time periods corresponding to multiple historical time points, so as to more accurately evaluate the service capabilities of edge nodes and optimize traffic scheduling. Exemplarily, before step 103, that is, before constructing the sub-feature vector corresponding to each historical time point in combination with the historical performance scores of each edge node and the attribute parameters of the stored domain name resource data for each historical time point, the following may further be included:

[0126] (A.1) Obtain the historical time periods corresponding to multiple historical time points, and determine the data occupancy of the domain name resource data, the update frequency within the historical time period, and the data type in the historical time period;

[0127] (A.2) Determine the attribute parameters corresponding to the stored domain name resource data based on the data occupancy, update frequency, and data type.

[0128] Among them, the historical time period can be a time interval including multiple historical time points, during which the domain name resource data is analyzed to predict the scheduling weights for dispatching the domain name resource data acquisition requests to each edge node when performing domain name resource distribution next.

[0129] Among them, the data occupancy can be the size of the storage space occupied by the domain name resource data, reflecting the scale of the data. If the data occupancy of the domain name resource data changes within the historical time period, the final data occupancy can be obtained by calculating the average value.

[0130] Among them, the update frequency can be the number of times the domain name resource data is updated within a specific historical time period, used to measure the frequency of data changes.

[0131] Among them, the data type can be the specific type describing the domain name resource data, such as root zone file, top-level domain data, or important domain name data, etc. Different types of data may have different management and distribution requirements.

[0132] Exemplarily, when the data type corresponding to the domain name resource data is a root zone file, it can contain the authoritative information of all top-level domain names and is the starting point for domain name server queries. For example, it can contain domain name server records of top-level domain names such as ".com", ".net", ".org", etc., and these records specify the authoritative DNS servers responsible for each top-level domain name. If the data type corresponding to the domain name resource data is top-level domain data, it can include the authoritative information of generic top-level domain names (such as ".com", ".org", ".net", etc.) and country-code top-level domain names. When the data type corresponding to the domain name resource data is important domain name data, it can include the authoritative information of domain names registered overseas or with high popularity. For example, domain name resource data with high traffic and high popularity such as "baidu.com" and "taobao.com".

[0133] Exemplarily, for the domain name resource data that needs to be allocated for resolution, its attribute parameters can be expressed as:

[0134] ;

[0135] Among them, represents the data occupancy of this domain name resource data, represents the update frequency of this domain name resource data, represents the data type of this domain name resource data. For example, when it is 1, it means that the domain name resource data that needs to be allocated for resolution after calculating the scheduling weight is a root zone file, when it is 2, it means top-level domain data, when it is 3, it means important domain name data.

[0136] Exemplarily, if the data occupancy of domain name resource data A is 50MB, the update frequency in the historical time period (such as in the recent week) is 3, and it is a root zone file, then the attribute parameter of domain name resource data A can be expressed as .

[0137] By obtaining the attribute parameters corresponding to the domain name resource data, a detailed feature profile can be established for each type of domain name resource data, which also provides a solid foundation for further analyzing the service capabilities of edge nodes. At the same time, this meticulous data processing method can make the prediction of the scheduling weight by the target model more accurate.

[0138] Step 104, splice the sub-feature vectors corresponding to multiple historical time points in chronological order to obtain a target feature vector, and output the scheduling weight of each edge node based on the target feature vector through a pre-trained target model.

[0139] In some embodiments, in order to form a vector that can comprehensively reflect the performance and quality of service of an edge node over a period of time, sub-feature vectors corresponding to multiple historical time points can be concatenated in chronological order, so that the model can comprehensively capture the dynamic change trend of the edge node performance, and then output more accurate scheduling weights.

[0140] Among them, the target feature vector can be a vector formed by concatenating sub-feature vectors corresponding to multiple historical time points in chronological order, which comprehensively reflects the performance and service characteristics of the edge node over a period of time.

[0141] Among them, the target model can be a machine learning model based on temporal feature learning, which can predict the scheduling weights of each edge node by fusing multi-dimensional temporal data. The target model organizes the input features in the form of a time series, adopts a neural network structure with the ability to extract temporal features, automatically learns the change rules in historical data, and finally outputs the scheduling weights of each edge node (which can also be called service capacity prediction values).

[0142] Among them, the scheduling weight can be the proportion of tasks or traffic allocated to the corresponding edge node according to the service capacity and resource status of the edge node, and is used to guide the traffic scheduling and load balancing between each edge node.

[0143] In some embodiments, the target model can be a Temporal Convolutional Network (TCN) model, a Long Short-Term Memory (LSTM)-attention hybrid model, a Transformer temporal model, etc.

[0144] In some embodiments, in order to facilitate the subsequent target model to fully extract temporal features and make predictions, the input matrix can be set in the form of a two-dimensional matrix of time steps × feature dimensions. Among them, the number of time steps T included in the historical time period is 24, indicating that data of 24 historical time points are formed by measuring once every hour in the recent 24 hours. The feature dimensions include the historical performance scores of k edge nodes (k dimensions), the attribute parameters of domain name resource data (3 dimensions), and time features (2 dimensions). Among them, the time feature can be a historical time point or other time data different from the historical time point. Then, therefore, the target feature vector has an input shape of a two-dimensional matrix of (24, k + 3 + 2), and can be expressed in the following form:

[0145] ;

[0146] By inputting the target feature vector into a pre-trained target model, the scheduling weight corresponding to each edge node can be obtained. By normalizing the scheduling weights and adjusting all scheduling weights to the same scale, the final scheduling weights can be obtained. Exemplarily, through the target model f, the scheduling weights (which can also be referred to as service capacity scores) of each edge node can be predicted. :

[0147] ;

[0148] For to be normalized, that is, divide the scheduling weight of the current i-th edge node by the sum of the scheduling weights of all edge nodes, and the scheduling weights of different edge nodes can be updated. :

[0149] ;

[0150] In some embodiments, for different types of domain name resource data, the edge nodes can correspond to different scheduling weights. That is to say, the target model outputs the scheduling weights corresponding to a single type of domain name resource data. For example, if the data type corresponding to the domain name resource data is a root zone file, then, according to the attribute parameters of the domain name resource data corresponding to the root zone file, and data such as historical performance scores, a corresponding target feature vector can be constructed. Multiple edge nodes can correspond to scheduling weights. For example, there are 3 edge nodes in total. Edge node 1 can correspond to a scheduling weight of 0.5, edge node 2 can correspond to a scheduling weight of 0.4, and edge node 3 can correspond to a scheduling weight of 0.1. And if the data type corresponding to the domain name resource data is top-level domain data, then, multiple edge nodes can correspond to different scheduling weights from those of the root zone file. For example, there are 3 edge nodes in total. Edge node 1 can correspond to a scheduling weight of 0.2, edge node 2 can correspond to a scheduling weight of 0.6, and edge node 3 can correspond to a scheduling weight of 0.2, etc. Depending on the actual situation, the specific scheduling weights may also vary. In this way, the target model can output differentiated edge node scheduling weights according to the type of domain name resource data, thereby achieving precise traffic scheduling for different types of data (such as root zone files, top-level domain data, etc.), improving the efficiency and reliability of the distribution of domain name resource data, and optimizing resource utilization and user experience.

[0151] Through the above method, an accurate quantitative evaluation of the service quality of each edge node can be achieved. This method not only considers the historical performance data of the edge nodes but also combines the specific attributes of the domain name resource data, making the scheduling decision more scientific and reasonable.

[0152] In some embodiments, in order to accurately evaluate the service capabilities of each edge node, a deep learning architecture with temporal awareness of the target model can be used to map the target feature vector into dynamic scheduling weights, thereby improving the efficiency and accuracy of request distribution. Exemplarily, "outputting the scheduling weight of each edge node based on the target feature vector through the pre-trained target model" in step 104 may include:

[0153] (104.1) Input the target feature vector into the target model, and through the initial convolutional layer of the target model, perform high-dimensional feature extraction on the target feature vector to obtain a first feature vector;

[0154] (104.2) Through the first residual block of the target model, process the time dependence of the first feature vector to obtain a second feature vector, and fuse the first feature vector and the second feature vector to obtain a third feature vector output by the first residual block. Each residual block includes multiple dilated convolutional layers, and the number of dilation factors included in the multiple dilated convolutional layers is configured according to the position of the corresponding residual block. The dilation factor is used to determine the temporal analysis range of the first feature vector;

[0155] (104.3) Through the intermediate residual blocks of the target model, process the time dependence of the third feature vector to obtain an updated second feature vector, and fuse the third feature vector and the updated second feature vector to obtain an updated third feature vector output by the intermediate residual block;

[0156] (104.4) When the updated third feature vector is output by the last intermediate residual block, through the global pooling layer of the target model, perform feature compression processing on the third feature vector to obtain a fourth feature vector;

[0157] (104.5) Through the fully connected layer of the target model, perform output mapping on the fourth feature vector to obtain the scheduling weight of each edge node.

[0158] Among them, the initial convolutional layer can be the first layer of the target model, responsible for performing preliminary high-dimensional feature extraction on the input target feature vector to generate a first feature vector.

[0159] Among them, the first feature vector can be the feature representation after being processed by the initial convolutional layer and serves as the input to the first residual block.

[0160] Among them, the first residual block can be a module containing multiple dilated convolutional layers, used to process the time dependence of the first feature vector to generate a second feature vector. The output of each residual block is fused with the input to obtain a third feature vector.

[0161] Among them, the second feature vector can be the feature representation obtained after processing within the residual block, reflecting the temporal dependence in the input data.

[0162] Among them, the third feature vector can be formed by fusing the first feature vector and the second feature vector, serving as the input for the next processing stage. In this way, the original information can be retained and the feature expression can be enhanced.

[0163] Among them, the dilated convolutional layer can be a special convolutional layer that allows expanding the receptive field (the range of temporal analysis) without increasing the number of parameters or computational complexity, and the receptive field range is controlled by the dilation factor.

[0164] Among them, the dilation factor can be used to determine the size of the receptive field of the dilated convolutional layer, affecting the range of temporal analysis of the input data.

[0165] Among them, the range of temporal analysis can be the time span that the dilated convolutional layer can cover, which is determined by the number of dilation factors.

[0166] Among them, the intermediate residual block can be a residual block similar to or the same as the first residual block, and it only differs from the first residual block in name and position.

[0167] Among them, the global pooling layer can be used to compress the feature dimension to retain the most important information while reducing the data volume, generating the fourth feature vector.

[0168] Among them, the fourth feature vector can be the feature representation processed by the global pooling layer, ready to enter the final output mapping stage.

[0169] Among them, the fully connected layer can be the final output layer, mapping the fourth feature vector to the specific scheduling weights.

[0170] In some embodiments, the target feature vector can be subjected to high-dimensional mapping (such as 64 channels) through the initial convolutional layer to extract the basic temporal features and enhance the model's expressive ability. Then, the dilated convolutional layers with increasing dilation factors in the residual blocks are used to gradually expand the temporal receptive field. For example, the convolutional layer with dilation = 8 can cover the data trends in the past 8 hours, capturing long-term dependencies (such as the daily traffic peak pattern). At the same time, the residual connection structure in each residual block can enable the fused third feature vector to retain the original information and avoid gradient vanishing. Then, the target feature vectors corresponding to multiple historical time points (such as 24 historical time points, and the number of historical time points can be different in different cases) can be compressed into a global state vector (i.e., the fourth feature vector) through the global pooling layer of the target model, eliminating the redundancy in the time dimension. Finally, the compressed fourth feature vector is decoded into the scheduling weights of k edge nodes through the fully connected layer, completing the end-to-end mapping from temporal features to scheduling decisions.

[0171] Please refer to Figure 3 , in some embodiments, the number of dilation factors included in multiple dilated convolutional layers can be configured according to the position of the corresponding residual block. For example, if there are 4 residual blocks for dilated convolutional stacking to capture long-term dependencies in the time series, the dilation factor of the first residual block can be set to 1, the dilation factor of the second residual block can be set to 2, the dilation factor of the third residual block can be set to 4, and the dilation factor of the fourth residual block can be set to 8, and so on. Each residual block can include two dilated convolutional layers and a residual connection, and the time series analysis range is controlled by the dilation factor.

[0172] Exemplarily, if the root zone file (type = 1) needs to be distributed currently, the input target feature vector includes the historical performance scores, data attributes (size = 5MB, frequency = 1 time / day, type = 1), and time features (hour = 14, week = 3) of 3 edge nodes (such as Alibaba Cloud, AWS, Azure, etc.) at each historical time point (each hour corresponds to one historical time point) within the past 24 hours. Further, after the target feature vector is input into the target model, the initial convolutional layer of the target model can map the 24×5-dimensional input into a 24×64 first feature vector to capture the initial time series pattern.

[0173] Further, the relationship between adjacent historical time points can be analyzed through the first residual block (dilation = 1) of the target model, such as finding that the latency of Alibaba Cloud suddenly increases from t - 1 to t hours (from 30ms → 80ms), etc., and a second feature vector is generated. The first feature vector and the second feature vector are fused through a residual connection to obtain a third feature vector.

[0174] Further, the third feature vector can be input into the next residual block of the first residual block, that is, the middle residual block. The dilation factor of the middle residual block can be set to 2, that is, dilation = 2, and the covered time analysis range is the data within 2 hours from the current historical time point. An updated second feature vector is obtained. Similarly, the updated second feature vector and the third feature vector output by the first residual block can be fused to obtain the third feature vector output by the middle residual block.

[0175] In some embodiments, the subsequent intermediate residual module processes the feature vector in the same way as described above, except that the number of dilation factors is different. For example, if the first residual block contains 1 dilation factor, then the second intermediate residual block can contain 2 dilation factors, the third intermediate residual block can contain 4 dilation factors, the fourth intermediate residual block can contain 8 dilation factors, and so on. This design enables each residual block to achieve cross-cycle pattern mining when identifying the temporal dependence relationship between feature vectors, thereby improving the accuracy and comprehensiveness of feature recognition and enhancing the accuracy of the output scheduling weights.

[0176] Furthermore, when the last intermediate residual block outputs the updated third feature vector, the global pooling layer of the target model can be used to perform global pooling integration on the third feature vector, compress the time dimension to 1, retain the feature dimension, and generate a global vector, that is, the fourth feature vector. Subsequently, the output layer can use a fully connected layer to map the fourth feature vector to the scheduling weights of k edge nodes, and normalize the scheduling weights to obtain the final scheduling weights of each edge node.

[0177] By performing deep time series feature extraction and processing on the target feature vector using the target model, the patterns of domain name resource data and historical performance scores changing over time can be accurately captured. Thereby, not only the accuracy of the service capacity evaluation of edge nodes is improved, but also the effectiveness and flexibility of request scheduling decisions are enhanced, effectively ensuring that globally geographically dispersed clients can quickly and stably access the latest domain name resource data, while improving the response speed and reliability of the entire system.

[0178] In some embodiments, in order to obtain a target model that can more accurately predict and optimize traffic scheduling, a preset model can be trained so that the model can learn the changing rules of the service capabilities of edge nodes based on sample data, and then make more accurate predictions. Exemplarily, the target model can be trained through the following steps:

[0179] (B.1) Receive multiple sample performance test data sent by each measurement service node. Each sample performance test data is obtained by the measurement service node testing the managed edge nodes at different sample time nodes, and the sample domain name resource data is synchronously stored in the edge nodes;

[0180] (B.2) Determine the sample historical performance scores of the edge nodes corresponding to each measurement service node at each sample time point according to the sample performance test data at each sample time point;

[0181] (B.3) For each sample time point, combine the sample historical performance scores of each edge node and the sample attribute parameters for the stored sample domain name resource data to construct a sample sub-feature vector corresponding to each sample time point;

[0182] (B.4)Concatenate the sample sub-feature vectors corresponding to multiple sample time points in chronological order to obtain a sample target feature vector, and output the predicted scheduling weight of each edge node based on the sample target feature vector through a preset model;

[0183] (B.5)For each edge node, obtain the sample scheduling weight of each edge node, and construct a target loss based on the difference between the predicted scheduling weight and the sample scheduling weight corresponding to each edge node;

[0184] (B.6)Based on the target loss, adjust the parameters of the preset model to obtain a target model.

[0185] Among them, the sample performance test data can be data collected by the measurement service node from the corresponding edge node, including but not limited to time delay data, packet loss rate data, and transmission jitter data, which are used to reflect the service quality of the edge node at a specific sample time point. The sample time point can be any historical time point in the actual scenario.

[0186] Among them, the sample time node can be the specific time when the measurement service node performs the performance test, and can be any past moment relative to the current sample time point.

[0187] Among them, the sample domain name resource data can include root zone files, top-level domain resource data (such as.com / .cn, etc.), important domain name resource data (such as financial institution domain names), etc.

[0188] Among them, the sample historical performance score can be used to characterize the service ability quality of the corresponding edge node for clients in a specific region at the sample time point.

[0189] Among them, the sample attribute parameters can be a set of features describing the characteristics of the sample domain name resource data, including but not limited to data size, update frequency, data type (such as root zone file, top-level domain data, or important domain name data), etc., which are used to quantitatively represent the characteristics of different types of sample domain name resource data.

[0190] Among them, the sample sub-feature vector can be a vector jointly composed of the sample historical performance score of the edge node at a specific sample time point, the sample attribute parameters of the sample domain name resource data that needs to be allocated and resolved, and the corresponding sample time point, which is used to capture the service quality status of each edge node and the specific characteristics of the resources it bears at this sample time point.

[0191] Among them, the sample target feature vector can be a vector formed by concatenating the sample sub-feature vectors corresponding to multiple sample time points in chronological order, which comprehensively reflects the performance performance and service characteristics of the edge node over a period of time.

[0192] Among them, the preset model can be a trained machine learning model based on temporal feature learning, which can predict the scheduling weights of each edge node by fusing multi-dimensional temporal data.

[0193] Among them, the predicted scheduling weight can be an estimated value of the scheduling weight of each edge node obtained by processing the sample target feature vector according to the preset model.

[0194] Among them, the sample scheduling weight can be the accurately set scheduling weight of the edge node in actual application, serving as a reference standard.

[0195] Among them, the target loss can be a measure to evaluate the difference between the predicted scheduling weight and the sample scheduling weight, and is used to guide the parameter optimization of the preset model.

[0196] In some embodiments, the entire implementation steps of generating the sample scheduling weights of each edge node in (B.1) to (B.4) are basically the same as the implementation steps of finally generating the predicted scheduling weights of each edge node in steps 101 to 104 introduced above. The differences lie in the data (training data and actual data) and the model state (preset model and target model). Therefore, the embodiments of this application do not elaborate on the processing process of generating the predicted scheduling weights, and specifically, reference can be made to the aforementioned processing process of generating the scheduling weights.

[0197] Furthermore, for each edge node, the corresponding sample scheduling weight can be obtained, that is, the true label can be obtained. The sample scheduling weight can be set by technicians based on actual business requirements and professional experience, or calculated by other means, and it is a standard reference.

[0198] In some embodiments, the target loss can be constructed using the mean square error according to the difference between the predicted scheduling weight and the sample scheduling weight corresponding to each edge node , and the specific formula is as follows:

[0199] ;

[0200] Among them, N represents the total number of all edge nodes, represents the predicted scheduling weight corresponding to the i-th edge node, represents the sample scheduling weight corresponding to the i-th edge node.

[0201] Furthermore, the target loss reflects the difference degree between the predicted adjustment weight and the sample adjustment weight of the preset model. Therefore, through an optimization algorithm (such as the gradient descent method), according to the magnitude of the target loss, the parameters of the preset model can be automatically adjusted to make the preset model iteratively optimize in the direction of minimizing the target loss, and finally obtain an optimal target model with the best performance.

[0202] Taking the gradient descent method as an example, first calculate the objective loss under the current model parameters. Then, calculate the gradients of the loss function with respect to each model parameter. The gradient represents the rate of change and direction of the loss function in the parameter space. According to this gradient information, update the parameters of the preset model at a certain learning rate (step size), so that the parameters move in the direction that can reduce the loss. This process will be repeated continuously until the value of the loss function converges to a minimum value or reaches the set stopping conditions such as the number of training epochs.

[0203] By adjusting the parameters of the preset model based on the objective loss and obtaining the target model, the model can accurately learn the complex patterns and rules in the data, ensuring that the model has excellent prediction ability when facing new data, can effectively capture data features and make accurate responses. At the same time, the optimized model shows good adaptability and stability in different scenarios, greatly improving the automation level and intelligent decision-making ability of the system.

[0204] In some embodiments, to ensure the consistency and reliability of data distribution, the data consistency can be verified by comparing the hash values calculated from the domain name resource test data returned by multiple edge nodes, so as to ensure that the client can always receive the correct data. Exemplarily, after the pre-trained target model outputs the scheduling weights of each edge node based on the target feature vector, it may further include:

[0205] (C.1) At the same historical time point, among the multiple performance test data returned by multiple edge nodes, determine the domain name resource test data of each edge node;

[0206] (C.2) For the domain name resource test data corresponding to each edge node, calculate the corresponding domain name resource hash value;

[0207] (C.3) Based on the comparison of multiple domain name resource hash values, when the comparison result indicates that the domain name resource hash value of at least one edge node is inconsistent with the domain name resource hash values of other edge nodes, adjust the scheduling weight of at least one edge node through a preset penalty factor to obtain the corresponding first scheduling weight;

[0208] (C.4) Based on the first scheduling weight, adjust the scheduling weights of other edge nodes to obtain the second scheduling weights of other edge nodes;

[0209] Then, according to the scheduling weight of each edge node, allocate at least one domain name resource data acquisition request to at least one edge node among the multiple edge nodes, so that at least one edge node distributes domain name resource data based on at least one domain name resource data acquisition request, including:

[0210] At least one domain name resource data acquisition request is assigned to at least one of the multiple edge nodes according to the first scheduling weight or the second scheduling weight of each edge node, so that at least one edge node distributes domain name resource data based on at least one domain name resource data acquisition request.

[0211] Among them, the domain name resource test data can be the domain name resource data for verifying consistency obtained by the measurement service node from the edge node at a specific historical time point.

[0212] Among them, the domain name resource hash value can be a unique identifier generated by applying a hash algorithm (such as MD5 algorithm, SHA256 algorithm) to the domain name resource test data, and is used to compare whether the domain name resource data between different edge nodes is consistent.

[0213] Among them, the penalty factor can be a preset adjustment coefficient, which is used to adjust the scheduling weight of the edge node marked due to data inconsistency, so as to reduce its proportion in traffic allocation.

[0214] Among them, the first scheduling weight can be the new scheduling weight of the edge node adjusted by the penalty factor, which reflects the decrease in trust due to data inconsistency.

[0215] Among them, the second scheduling weight can be the updated scheduling weight of other edge nodes after being adjusted based on the first scheduling weight, aiming to maintain the load balance and efficiency of the entire system.

[0216] In some embodiments, the corresponding first domain name resource data can also be determined from the domain name resource server, the corresponding first hash value is calculated, and the corresponding second domain name resource data is determined from multiple edge nodes, and the corresponding second hash value is calculated. Based on the comparison between the first hash value and the second hash value, when the comparison result indicates that among the multiple second hash values, there is at least one target second hash value of an edge node that is inconsistent with the first hash value, the scheduling weight of at least one edge node is adjusted by a preset penalty factor to obtain the corresponding first scheduling weight.

[0217] In some embodiments, at least one domain name resource data acquisition request can also be assigned to at least one of multiple edge nodes for distributing domain name resource data. After the edge node returns the corresponding domain name resource data, the hash value of the domain name resource data of this edge node is compared with the hash values of the corresponding domain name resource data in other edge nodes. When the comparison result indicates that the hash values of at least one edge node are inconsistent with the hash values of other edge nodes, the scheduling weights of at least one edge node are adjusted through a preset penalty factor to obtain the corresponding first scheduling weights. Alternatively, the hash value of the domain name resource data distributed by each edge node can also be compared with the hash value of the domain name resource data in the corresponding data in the domain name resource server. When the comparison result indicates that the hash values are inconsistent, the scheduling weight of this edge node is adjusted through a preset penalty factor to obtain the corresponding first scheduling weights.

[0218] Please refer to Figure 4 , for example, in combination with Figure 4 to illustrate the process of adjusting the scheduling weights. Suppose there are three edge nodes for distributing domain name resource data (such as root zone files). At the same historical time point, the measurement service node will send measurement data to the edge nodes to be managed. From the performance test data returned by each edge node, the domain name resource test data of each edge node can be determined. Suppose the hash value of edge node 1 is "abc123", the hash value of edge node 2 is "def456", and the hash value of edge node 3 is also "abc123". Based on the comparison of these three domain name resource hash values, it is found that the hash value of edge node 2 is inconsistent with the hash values of the other two edge nodes, indicating that there are problems in the data synchronization process of edge node 2, and it has not been updated to the latest version of the domain name resource data in a timely manner, or errors or damages have occurred during data transmission and storage, resulting in its data content being inconsistent with other nodes. At this time, the scheduling weight of edge node 2 can be adjusted through a preset penalty factor (assumed to be 0.5) to reduce its weight and obtain the corresponding first scheduling weight (assuming the original weight is 0.4 and it becomes 0.2 after adjustment). Then, based on this first scheduling weight, the scheduling weights of edge node 1 and edge node 3 are adjusted. Suppose the original weight of edge node 1 is 0.3 and it becomes 0.4 after adjustment; the original weight of edge node 3 is 0.3 and it becomes 0.4 after adjustment, so as to obtain the second scheduling weights of other edge nodes, thereby ensuring the consistency of the domain name resource data provided by the edge nodes.

[0219] Further, in the case where the hash value comparison is inconsistent, a new scheduling weight is directly generated based on the penalty factor, and the domain name resource data acquisition request is allocated to ensure the consistency of the domain name resource data provided by the edge node; while if the hash value comparison is consistent, the scheduling weight output by the target model is directly used to allocate the domain name resource data acquisition request, so that the corresponding edge node distributes the domain name resource data according to the domain name resource data acquisition request, and thus the entire process ends.

[0220] Further, the value of the penalty factor can be set according to the actual situation, and the embodiments of the present application do not make specific limitations on this. Specifically, the formula for adjusting the scheduling weight by the penalty factor is as follows:

[0221] ;

[0222] Where is the penalty factor, is the scheduling weight before adjustment, is the first scheduling weight after adjustment.

[0223] Further, the adjusted scheduling weight can be normalized to ensure that the sum of all weights is 1. The specific formula is as follows:

[0224] ;

[0225] In this way, an optimized CDN traffic ratio (scheduling weight) for different edge nodes can be obtained.

[0226] By checking the data consistency of each edge node, the scheduling weight of the edge node that provides inconsistent data can be timely discovered and reduced, effectively improving the stability and reliability of the resolution, and ensuring that the client can obtain correct information.

[0227] Step 105, when receiving at least one domain name resource data acquisition request, allocate at least one domain name resource data acquisition request to at least one of the multiple edge nodes according to the scheduling weight of each edge node, so that at least one edge node distributes the domain name resource data based on at least one domain name resource data acquisition request.

[0228] In some embodiments, in order to ensure that the domain name resource data acquisition request can be processed efficiently and reliably, the domain name resource data acquisition request can be intelligently allocated to one or more edge nodes for processing according to the scheduling weight of each edge node, so as to optimize the load balancing in the multi-cloud CDN environment, ensure that the domain name resource data acquisition request is more routed to the edge nodes with better performance and higher availability, and improve the data distribution efficiency and reliability.

[0229] Among them, the domain name resource data acquisition request can be a query request initiated by a client, aiming to obtain the Internet protocol address corresponding to a specific domain name, so as to establish a network connection and access the required resources.

[0230] Exemplarily, assume that there are currently three edge nodes (Edge Node A, Edge Node B, and Edge Node C), and their scheduling weights are 0.4, 0.3, and 0.3 respectively. At this time, the system receives multiple domain name resource data acquisition requests. According to the scheduling weights, the system allocates 40% of the requests to Edge Node A, 30% of the requests to Edge Node B, and the other 30% of the requests to Edge Node C. For example, if there are 100 domain name resource data acquisition requests, then Edge Node A will process 40 requests, Edge Node B will process 30 requests, and Edge Node C will process 30 requests.

[0231] This application can uniformly distribute domain name resource data by making full use of different CDN nodes (i.e., edge nodes) of cloud service providers, without the need to spend a large amount of resources to build resource distribution nodes by itself. It can make full use of the service capacity advantages of different edge nodes facing different regions and select more suitable nodes to quickly implement the distribution of domain name resource data. At the same time, this application can make full use of multi-cloud redundancy, with higher availability, and can utilize the security protection capabilities integrated by cloud service providers themselves to respond to sudden traffic more flexibly.

[0232] In the embodiments of the present application, by receiving multiple performance test data sent by each measurement service node, each performance test data is obtained by the measurement service node testing the managed edge nodes at different historical time points, and the edge nodes synchronously store domain name resource data; according to the performance test data at each historical time point, determine the historical performance scores of the edge nodes corresponding to each measurement service node at each historical time point; for each historical time point, combine the historical performance scores of each edge node and the attribute parameters for the stored domain name resource data to construct a sub-feature vector corresponding to each historical time point; splice the sub-feature vectors corresponding to multiple historical time points in chronological order to obtain a target feature vector, and output the scheduling weights of each edge node based on the target feature vector through a pre-trained target model; when receiving at least one domain name resource data acquisition request, allocate the at least one domain name resource data acquisition request to at least one of the multiple edge nodes according to the scheduling weights of each edge node, so that at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request. In this way, it is possible to use the measurement service node to collect the performance test data of each edge node and convert it into historical performance scores, so that the system can grasp the network status of each edge node at different historical time points in real time. Then, by fusing the historical performance scores and the attribute parameters of the domain name resource data to construct a sub-feature vector, and splicing the sub-feature vectors corresponding to multiple historical time points in chronological order and inputting them into the target model, it is possible to enable the target model to fully learn the time-dependent features of the target feature vector, capture the performance changes of each edge node at different historical time points, and then predict the scheduling weights of each edge node at the current moment. Therefore, when receiving a domain name resource data acquisition request, the request can be dynamically allocated according to the scheduling weights of each edge node, which not only realizes the reasonable distribution of traffic, avoids the performance bottleneck of a single node, but also enhances the fault tolerance and stability of the system with the collaborative work of the edge nodes, thus ensuring the efficient and reliable operation of the resolution service even in a cross-regional scenario. In summary, the present application can improve the efficiency and stability of the domain name resource data distribution process.

[0233] In some embodiments, the present application also proposes a method for distributing domain name resource data, which is applied to a measurement service node. The method includes:

[0234] Test the managed edge nodes at different historical time points to obtain corresponding performance test data. The edge nodes synchronously store the domain name resource data stored on the domain name resource server;

[0235] Send multiple performance test data to the domain name resource server, so that after the domain name resource server receives the multiple performance test data sent by each measurement service node, according to the performance test data at each historical time point, determine the historical performance scores of the edge nodes corresponding to each measurement service node at each historical time point, and for each historical time point, combine the historical performance scores of each edge node and the attribute parameters for the stored domain name resource data to construct a sub-feature vector corresponding to each historical time point, and splice the sub-feature vectors corresponding to multiple historical time points in chronological order to obtain a target feature vector, and output the scheduling weight of each edge node based on the target feature vector through a pre-trained target model. When receiving at least one domain name resource data acquisition request, allocate the at least one domain name resource data acquisition request to at least one of the multiple edge nodes according to the scheduling weight of each edge node, so that at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request.

[0236] The specific implementation of this domain name resolution method applied to the measurement service node is basically the same as the specific embodiment of the above domain name resource data distribution method applied to the domain name resource server, and will not be elaborated here.

[0237] Please refer to Figure 5 , this application embodiment also provides a domain name resource data distribution device, which is applied to the domain name resource server. The domain name resource server stores corresponding domain name resource data. The domain name resource data distribution device can implement the above domain name resource data distribution method. The domain name resource data distribution device includes:

[0238] A receiving module 51, configured to receive multiple performance test data sent by each measurement service node. Each performance test data is obtained by the measurement service node testing the managed edge node at different historical time points, and the edge node synchronously stores the domain name resource data;

[0239] A determining module 52, configured to determine the historical performance scores of the edge nodes corresponding to each measurement service node at each historical time point according to the performance test data at each historical time point;

[0240] A constructing module 53, configured to construct a sub-feature vector corresponding to each historical time point by combining the historical performance scores of each edge node and the attribute parameters for the stored domain name resource data for each historical time point;

[0241] A splicing module 54, configured to splice the sub-feature vectors corresponding to multiple historical time points in chronological order to obtain a target feature vector, and output the scheduling weight of each edge node based on the target feature vector through a pre-trained target model;

[0242] The parsing module 55 is used to distribute the at least one domain name resource data acquisition request to at least one edge node among the multiple edge nodes according to the scheduling weight of each edge node when receiving at least one domain name resource data acquisition request, so that the at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request.

[0243] The specific implementation of the domain name resource data distribution device is basically the same as the specific embodiment of the domain name resource data distribution method described above, and will not be repeated here. Under the premise of meeting the requirements of the embodiment of this application, the domain name resource data distribution device can also be provided with other functional modules to implement the domain name resource data distribution method in the above embodiment.

[0244] The present application also provides a computer device comprising a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned domain name resource data distribution method. The computer device can be any intelligent terminal, including a tablet computer and an in-vehicle computer.

[0245] See also Figure 6 , Figure 6 The hardware structure of a computer device according to another embodiment is shown. The computer device includes:

[0246] The processor 61 may be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0247] The memory 62 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 62 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 62 and is called by the processor 61 to execute the domain name resource data distribution method of the embodiments of this application.

[0248] Input / output interface 63, used to implement information input and output;

[0249] Communication interface 64, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0250] A bus 65 transmits information among various components of the device (such as a processor 61, a memory 62, an input / output interface 63, and a communication interface 64).

[0251] Among them, the processor 61, the memory 62, the input / output interface 63, and the communication interface 64 are communicatively connected to each other inside the device through the bus 65.

[0252] The embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above domain name resource data distribution method is implemented.

[0253] As a non-transitory computer-readable storage medium, the memory can be used to store non-transitory software programs and non-transitory computer-executable programs. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory may optionally include a memory remotely provided relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0254] The embodiments described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art can know that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0255] Those skilled in the art can understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than those shown in the figures, or combine certain steps, or different steps.

[0256] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0257] Those of ordinary skill in the art can understand that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices can be implemented as software, firmware, hardware, and appropriate combinations thereof.

[0258] In the description of the present application and the above-mentioned drawings, terms such as "first", "second", "third", "fourth", etc. (if any) are used to distinguish similar objects and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments of the present application described herein can be implemented in an order different from those illustrated or described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0259] It should be understood that in the present application, "at least one (item)" and "several" mean one or more, and "multiple" means two or more. "And / or" is used to describe the relationship between associated objects and indicates that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Here, A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. "At least one (one) of the following" or its similar expressions refer to any combination of these items, including any combination of single items (one) or plural items (ones). For example, at least one (one) of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0260] In several embodiments provided by the present application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the above-mentioned division of units is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be an indirect coupling or communication connection through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0261] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0262] In addition, in each embodiment of the present application, each functional unit may be integrated into one processing unit, may exist physically alone for each unit, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of a software functional unit.

[0263] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes multiple instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in each embodiment of the present application. The aforementioned storage medium includes: various media that can store programs such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs.

[0264] The preferred embodiments of the embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the rights of the embodiments of the present application. Any modification, equivalent replacement, and improvement made by those skilled in the art without departing from the scope and essence of the embodiments of the present application shall be within the scope of the rights of the embodiments of the present application.

Claims

1. A method for distributing domain name resource data, characterized in that: Applied to a domain name resource server, the domain name resource server stores corresponding domain name resource data, and the method includes: Receiving multiple performance test data sent by each measurement service node, each performance test data is obtained by the measurement service node testing the managed edge node at different historical time points, and the edge node synchronously stores the domain name resource data; Determine the historical performance score of the edge node corresponding to each measurement service node at each historical time point based on the performance test data at each historical time point; For each historical time point, the sub-feature vector corresponding to each historical time point is constructed by combining the historical performance score of each edge node and the attribute parameters of the stored domain name resource data; Concatenate the sub-feature vectors corresponding to the multiple historical time points in chronological order to obtain a target feature vector, and output the scheduling weight of each edge node based on the target feature vector through a pre-trained target model; At the same historical time point, domain name resource test data of each edge node is determined from multiple performance test data returned by the multiple edge nodes; a corresponding domain name resource hash value is calculated for the domain name resource test data corresponding to each edge node; a comparison is performed based on the multiple domain name resource hash values, and when the comparison result indicates that the domain name resource hash value of at least one edge node is inconsistent with the domain name resource hash values of other edge nodes, a scheduling weight of the at least one edge node is adjusted by a preset penalty factor to obtain a corresponding first scheduling weight; and based on the first scheduling weight, the scheduling weights of the other edge nodes are adjusted to obtain second scheduling weights of the other edge nodes; When at least one domain name resource data acquisition request is received, the at least one domain name resource data acquisition request is distributed to at least one edge node among the multiple edge nodes according to the first scheduling weight or the second scheduling weight of each edge node, so that the at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request.

2. The domain name resource data distribution method according to claim 1, characterized in that: Determining the historical performance score of the edge node corresponding to each measurement service node at each historical time point based on the performance test data at each historical time point includes: Based on the performance test data at each historical time point, the time delay data, packet loss rate data and transmission jitter data of the edge node corresponding to each measurement service node at each historical time point are obtained; Obtaining a first weight corresponding to the time delay data, a second weight corresponding to the packet loss rate data, and a third weight corresponding to the transmission jitter data, and adjusting the time delay data, the packet loss rate data, and the transmission jitter data according to the first weight, the second weight, and the third weight, respectively, to obtain corresponding target time delay data, target packet loss rate data, and target transmission jitter data; Based on the target time delay data, the target packet loss rate data, and the target transmission jitter data, a historical performance score of the corresponding edge node at each historical time point is obtained.

3. The domain name resource data distribution method according to claim 1, characterized in that: Before constructing the sub-feature vector corresponding to each historical time point by combining the historical performance score of each edge node and the attribute parameters of the stored domain name resource data, the method further includes: Obtaining historical time periods corresponding to multiple historical time points, and determining the data usage of the domain name resource data in the historical time period, the update frequency in the historical time period, and the data type; Based on the data occupancy, the update frequency and the data type, attribute parameters corresponding to the stored domain name resource data are determined.

4. The domain name resource data distribution method according to claim 1, characterized in that: The target model is trained in the following way: Receiving multiple sample performance test data sent by each measurement service node, each sample performance test data is obtained by the measurement service node testing the managed edge node at different sample time nodes, and the edge node synchronously stores sample domain name resource data; Determine the sample historical performance score of the edge node corresponding to each measurement service node at each sample time point based on the sample performance test data at each sample time point; For each sample time point, the sample sub-feature vector corresponding to each sample time point is constructed by combining the sample historical performance score of each edge node and the sample attribute parameters of the stored sample domain name resource data; Concatenate the sample sub-feature vectors corresponding to the plurality of sample time points in chronological order to obtain a sample target feature vector, and output a predicted scheduling weight for each edge node based on the sample target feature vector using a preset model; For each edge node, obtain a sample scheduling weight of each edge node, and construct a target loss based on a difference between the predicted scheduling weight and the sample scheduling weight corresponding to each edge node; Based on the target loss, the parameters of the preset model are adjusted to obtain a target model.

5. The domain name resource data distribution method according to claim 1, characterized in that: Outputting a scheduling weight of each edge node based on the target feature vector through the pre-trained target model includes: Inputting the target feature vector into a target model, performing high-dimensional feature extraction on the target feature vector through an initial convolutional layer of the target model to obtain a first feature vector; Performing time-dependent processing on the first eigenvector through a first residual block of the target model to obtain a second eigenvector, and fusing the first eigenvector and the second eigenvector to obtain a third eigenvector output by the first residual block, wherein each residual block includes a plurality of dilated convolutional layers, the number of dilation factors included in the plurality of dilated convolutional layers is configured according to the position of the corresponding residual block, and the dilation factor is used to determine the range of temporal analysis of the first eigenvector; Performing time-dependent processing on the third eigenvector through the intermediate residual block of the target model to obtain an updated second eigenvector, and fusing the third eigenvector with the updated second eigenvector to obtain an updated third eigenvector output by the intermediate residual block; When the last intermediate residual block outputs an updated third eigenvector, performing feature compression processing on the third eigenvector through the global pooling layer of the target model to obtain a fourth eigenvector; The fourth eigenvector is output mapped through the fully connected layer of the target model to obtain the scheduling weight of each edge node.

6. A method for distributing domain name resource data, characterized in that: Applied to a measurement service node, the method includes: Testing the managed edge nodes at different historical time points to obtain corresponding performance test data, wherein the edge nodes synchronously store the domain name resource data stored by the domain name resource server; Send multiple performance test data to the domain name resource server, so that after receiving the multiple performance test data sent by each measurement service node, the domain name resource server determines the historical performance score of the edge node corresponding to each measurement service node at each historical time point according to the performance test data at each historical time point, and for each historical time point, combines the historical performance score of each edge node and the attribute parameters of the stored domain name resource data to construct a sub-feature vector corresponding to each historical time point, and splices the sub-feature vectors corresponding to the multiple historical time points in chronological order to obtain a target feature vector, and outputs the scheduling weight of each edge node based on the target feature vector through a pre-trained target model, and at the same historical time point, determines the domain name resource test data of each edge node from the multiple performance test data returned by the multiple edge nodes, and for each edge node The domain name resource test data corresponding to the point is calculated, the corresponding domain name resource hash value is calculated, and a comparison is performed based on multiple domain name resource hash values. When the comparison result indicates that the domain name resource hash value of at least one edge node is inconsistent with the domain name resource hash values of other edge nodes, the scheduling weight of the at least one edge node is adjusted by a preset penalty factor to obtain a corresponding first scheduling weight. Based on the first scheduling weight, the scheduling weights of the other edge nodes are adjusted to obtain the second scheduling weights of the other edge nodes. When at least one domain name resource data acquisition request is received, the at least one domain name resource data acquisition request is distributed to at least one edge node among the multiple edge nodes according to the first scheduling weight or the second scheduling weight of each edge node, so that the at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request.

7. A domain name resource data distribution device, characterized in that: Applied to a domain name resource server, the domain name resource server stores corresponding domain name resource data, and the device includes: a receiving module, configured to receive a plurality of performance test data sent by each measurement service node, each performance test data being obtained by the measurement service node through testing an edge node managed by the measurement service node at different historical time points, the edge node synchronously storing the domain name resource data; A determination module, configured to determine a historical performance score of an edge node corresponding to each measurement service node at each historical time point based on performance test data at each historical time point; A construction module is used to construct a sub-feature vector corresponding to each historical time point by combining the historical performance score of each edge node and the attribute parameters of the stored domain name resource data; A splicing module is used to splice the sub-feature vectors corresponding to the multiple historical time points in chronological order to obtain a target feature vector, and output the scheduling weight of each edge node based on the target feature vector through a pre-trained target model, and at the same historical time point, determine the domain name resource test data of each edge node from the multiple performance test data returned by the multiple edge nodes; calculate the corresponding domain name resource hash value for the domain name resource test data corresponding to each edge node; compare based on the multiple domain name resource hash values, and when the comparison result indicates that the domain name resource hash value of at least one edge node is inconsistent with the domain name resource hash value of other edge nodes, adjust the scheduling weight of the at least one edge node by a preset penalty factor to obtain a corresponding first scheduling weight; based on the first scheduling weight, adjust the scheduling weights of the other edge nodes to obtain second scheduling weights of the other edge nodes; The parsing module is used to, when receiving at least one domain name resource data acquisition request, distribute the at least one domain name resource data acquisition request to at least one edge node among multiple edge nodes according to the first scheduling weight or the second scheduling weight of each edge node, so that the at least one edge node distributes the domain name resource data based on the at least one domain name resource data acquisition request.

8. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the domain name resource data distribution method according to any one of claims 1 to 6 when executing the computer program.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the domain name resource data distribution method according to any one of claims 1 to 6 is implemented.

Images