Data back-to-source system and method, network node and storage medium

By introducing central nodes into the CDN system, the problem of difficulty in real-time perception of the IP address changes of upstream service nodes under the cloud native architecture is solved, and the effect of improving the return-source processing efficiency and hit rate is achieved.

CN119788684AActive Publication Date: 2025-04-08BEIJING QIYI CENTURY SCI & TECH CO LTD
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
CN202411894484.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-20
Publication Date
2025-04-08
Estimated Expiration
2044-12-20

AI Technical Summary

Technical Problem

Under the cloud native architecture, it is difficult for CDN downstream nodes to sense the IP address changes of upstream service nodes in real time, resulting in low hit rate when returning to the source, long return to the source time, and low processing efficiency.

Method used

The central node is introduced, and the upstream service node registers and reports the IP address changes to the central node. The central node stores and updates the corresponding relationship between the identification and IP address of the upstream service node. The downstream CDN node obtains the relationship table from the central node to determine the target IP address for return to the source.

Benefits of technology

Through the medium of the central node, the downstream CDN node can accurately determine the target IP address of the upstream service node, which improves the hit rate and processing efficiency during return to the source, and reduces the return to the source time.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119788684A_ABST
    Figure CN119788684A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides a data back-to-source system and method, a network node and a storage medium, and relates to the technical field of Internet, the system comprises an upstream service node, a center node and a downstream content delivery network CDN node; the upstream service node is used for sending a registration request to the central node in response to the starting operation; reporting to the central node when the IP address is changed; the central node is used for storing the corresponding relationship between the identifier of the upstream service node and the IP address in response to the registration request; updating the IP address reported by the upstream service node to the stored corresponding relation; the downstream CDN node is used for acquiring the corresponding relation from the center node; determining a target node identifier of the target service according to a service request of a user for the target service; determining a target IP address corresponding to the target node identifier based on the obtained corresponding relationship; and performing data back-to-source based on the target IP address. By applying the technical scheme provided by the embodiment of the invention, the back-to-source processing efficiency can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of Internet technology, and in particular to a data return-to-source system, method, network node, and storage medium. Background Art

[0002] With the popularization of cloud computing and microservice architecture, more and more services are migrated to cloud-native architecture. That is, upstream service nodes that can provide various services can be deployed in cloud-native architecture.

[0003] CDN (Content Delivery Network) is an important network content service system that can provide users with efficient content distribution services. In CDN, when a user requests to access content provided by a service, the downstream CDN node obtains the user request and checks whether it has cached the content requested by the user. If the downstream CDN node does not cache the content requested by the user, the downstream CDN node needs to process the user request back to the source and request the content requested by the user from the upstream service node.

[0004] When the CDN bearer network adopts a cloud-native architecture, the IP addresses of various network nodes in the cloud-native architecture will change frequently, that is, the IP addresses of upstream service nodes will change frequently, which makes it difficult for downstream CDN nodes to perceive the actual IP addresses of upstream service nodes in real time. When the downstream CDN node performs back-to-source processing, if the changed IP address is directly used for back-to-source processing, the hit rate of the downstream CDN node hitting the upstream service node will be low during back-to-source processing, which will in turn lead to a longer back-to-source time and lower back-to-source processing efficiency. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a data return source system, method, network node and storage medium to improve the return source processing efficiency. The specific technical solution is as follows:

[0006] In a first aspect of the implementation of the present application, a data back-to-source system is first provided, the system comprising: an upstream service node, a central node and a downstream CDN node; wherein:

[0007] The upstream service node is configured to send a registration request to the central node in response to a start operation, wherein the registration request includes an identifier and an IP address of the upstream service node; and report an updated IP address to the central node in response to a change in the IP address of the upstream service node;

[0008] The central node is configured to store the correspondence between the identifier of the upstream service node and the IP address in the central node in response to the registration request; and update the IP address in the correspondence stored in the central node in response to the upstream service node reporting the IP address;

[0009] The downstream CDN node is used to obtain the corresponding relationship stored in the central node; in response to obtaining a service request from a user for a target service, determine the target node identifier of the upstream service node corresponding to the target service requested by the service request; based on the obtained corresponding relationship, determine the target IP address corresponding to the target node identifier; and based on the target IP address, perform data return to the source.

[0010] In a possible implementation manner, the downstream CDN node is further configured to perform hash calculation on the identifier of each upstream service node in the corresponding relationship stored in the downstream CDN node to obtain multiple first hash values ​​of the identifier.

[0011] In a possible implementation manner, determining the target node identifier of the upstream service node corresponding to the target service requested by the service request includes:

[0012] Generate a second hash value of the request identifier of the user service request;

[0013] Searching, among the first hash values ​​stored in the downstream CDN node, a third hash value that is greater than the second hash value and closest to the second hash value;

[0014] If the third hash value is found, determining the identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request;

[0015] If the third hash value is not found, the recorded minimum first hash value is determined as the third hash value, and the identifier corresponding to the third hash value is determined as the target node identifier.

[0016] In one possible implementation, the central node is also used to monitor the status of the upstream service node; if the monitored status indicates that the upstream service node has joined the CDN network, the identifier and IP address of the upstream service node are obtained from the upstream service node, and the correspondence between the identifier and the IP address of the upstream service node is stored in the central node; if the monitored status indicates that the upstream service node has exited the CDN network, the correspondence between the identifier and the IP address of the upstream service node stored in the central node is deleted; if the monitored status indicates that the IP address of the upstream service node has changed, the IP address in the correspondence between the identifier and the IP address of the upstream service node stored in the central node is updated.

[0017] In a possible implementation manner, the downstream CDN node is further configured to send a subscription request to the central node in response to a start operation, wherein the subscription request is used to subscribe to a corresponding relationship stored in the central node;

[0018] The central node is further configured to synchronize the changed corresponding relationship to the downstream CDN node after detecting that the corresponding relationship stored in the central node changes;

[0019] The downstream CDN node is specifically configured to update the corresponding relationship stored in the downstream CDN node according to the corresponding relationship synchronized by the central node.

[0020] In a possible implementation manner, the identifier of the upstream service node includes: a service name provided by the upstream service node and / or a service version provided by the upstream service node.

[0021] In a second aspect of the implementation of the present application, a data return method is also provided, which is applied to a central node, and the method includes:

[0022] In response to a registration request from an upstream service node, storing a correspondence between an identifier of the upstream service node and an IP address in the central node;

[0023] In response to the upstream service node reporting the updated IP address, updating the IP address in the corresponding relationship stored by the central node;

[0024] The corresponding relationship stored in the central node is sent to the downstream CDN node.

[0025] In a possible implementation manner, the method further includes:

[0026] Monitor the status of the upstream service node;

[0027] If the monitored status indicates that the upstream service node has joined the CDN network, obtaining the identifier and IP address of the upstream service node from the upstream service node, and storing the correspondence between the identifier and IP address of the upstream service node in the central node;

[0028] If the monitored status indicates that the upstream service node has exited the CDN network, deleting the correspondence between the identifier and the IP address of the upstream service node stored in the central node;

[0029] If the monitored status indicates that the IP address of the upstream service node has changed, the IP address in the correspondence between the identifier of the upstream service node and the IP address stored in the central node is updated.

[0030] In a possible implementation manner, the method further includes:

[0031] receiving a subscription request for the corresponding relationship stored in the central node sent by the downstream CDN node, and sending the corresponding relationship stored in the central node to the downstream CDN node in response to the subscription request;

[0032] The sending the corresponding relationship stored in the central node to the downstream CDN node includes:

[0033] After detecting that the corresponding relationship stored in the central node has changed, the changed corresponding relationship is synchronized to the downstream CDN node.

[0034] In a third aspect of the implementation of the present application, a data return method is also provided, which is applied to a downstream CDN node, and the method includes:

[0035] Obtain the correspondence between the identifier and IP address of the upstream service node stored in the central node;

[0036] In response to obtaining a service request for a target service from a user, determining a target node identifier of an upstream service node corresponding to the target service requested by the service request;

[0037] Based on the acquired corresponding relationship, determine the target IP address corresponding to the target node identifier;

[0038] Based on the target IP address, data is returned to the source.

[0039] In a possible implementation manner, the method further includes:

[0040] For each identifier of the upstream service node in the corresponding relationship stored in the downstream CDN node, a hash calculation is performed on the identifier to obtain multiple first hash values ​​of the identifier.

[0041] In a possible implementation manner, determining the target node identifier of the upstream service node corresponding to the target service requested by the service request includes:

[0042] Generate a second hash value of the request identifier of the service request;

[0043] Searching, among the first hash values ​​stored in the downstream CDN node, a third hash value that is greater than the second hash value and closest to the second hash value;

[0044] If the third hash value is found, determining the identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request;

[0045] If the third hash value is not found, the recorded minimum first hash value is determined as the third hash value, and the identifier corresponding to the third hash value is determined as the target node identifier.

[0046] In a possible implementation manner, the method further includes:

[0047] In response to the start operation, sending a subscription request for the corresponding relationship stored in the central node to the central node;

[0048] Obtaining a corresponding relationship stored in the central node that is fed back by the central node in response to the subscription request;

[0049] The obtaining of the correspondence between the identifier of the upstream service node and the IP address stored in the central node includes:

[0050] According to the corresponding relationship synchronized by the central node, the corresponding relationship stored in the downstream CDN node is updated.

[0051] In a fourth aspect of the implementation of the present application, a data return method is also provided, which is applied to an upstream service node, and the method includes:

[0052] In response to the start operation, sending a registration request to the central node, wherein the registration request includes an identifier and an IP address of the upstream service node;

[0053] In response to the IP address change of the upstream service node, an updated IP address is reported to the central node.

[0054] In a possible implementation manner, the identifier of the upstream service node includes: a service name provided by the upstream service node and / or a service version provided by the upstream service node.

[0055] In a fifth aspect of the implementation of the present application, a data return source device is also provided, which is applied to a central node, and the device includes:

[0056] A storage module, configured to store the correspondence between the identifier and the IP address of the upstream service node in the central node in response to a registration request of the upstream service node;

[0057] An updating module, configured to update the IP address in the corresponding relationship stored in the central node in response to the updated IP address reported by the upstream service node;

[0058] The first sending module is used to send the corresponding relationship stored in the central node to the downstream CDN node.

[0059] In a possible implementation manner, the device further includes:

[0060] A monitoring module is used to monitor the status of the upstream service node; if the monitored status indicates that the upstream service node joins the CDN network, the identifier and IP address of the upstream service node are obtained from the upstream service node, and the corresponding relationship between the identifier and the IP address of the upstream service node is stored in the central node; if the monitored status indicates that the upstream service node exits the CDN network, the corresponding relationship between the identifier and the IP address of the upstream service node stored in the central node is deleted; if the monitored status indicates that the IP address of the upstream service node changes, the IP address in the corresponding relationship between the identifier and the IP address of the upstream service node stored in the central node is updated.

[0061] In a possible implementation manner, the device further includes:

[0062] A receiving module, configured to receive a subscription request for the corresponding relationship stored in the central node sent by the downstream CDN node, and send the corresponding relationship stored in the central node to the downstream CDN node in response to the subscription request;

[0063] The first sending module is specifically configured to: after detecting that the corresponding relationship stored in the central node has changed, synchronize the changed corresponding relationship to the downstream CDN node.

[0064] In a sixth aspect of the implementation of the present application, a data return source device is also provided, which is applied to a downstream CDN node, and the device includes:

[0065] An acquisition module, used to acquire the correspondence between the identifier and IP address of the upstream service node stored in the central node;

[0066] A first determination module, configured to determine, in response to obtaining a service request from a user for a target service, a target node identifier of an upstream service node corresponding to the target service requested by the service request;

[0067] A second determination module is used to determine the target IP address corresponding to the target node identifier based on the acquired corresponding relationship;

[0068] The back-to-source module is used to perform data back-to-source based on the target IP address.

[0069] In a possible implementation manner, the device further includes:

[0070] A calculation module, configured to perform hash calculation on the identifier of each upstream service node in the corresponding relationship stored in the downstream CDN node to obtain multiple first hash values ​​of the identifier;

[0071] The second determination module is specifically used to: generate a second hash value of the request identifier of the service request; search for a third hash value that is greater than the second hash value and closest to the second hash value in the first hash value stored in the downstream CDN node; if the third hash value is found, determine the identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request; if the third hash value is not found, determine the recorded minimum first hash value as the third hash value, and determine the identifier corresponding to the third hash value as the target node identifier.

[0072] In a possible implementation manner, the device further includes:

[0073] A subscription module, configured to send a subscription request for the corresponding relationship stored in the central node to the central node in response to a start operation; and obtain the corresponding relationship stored in the central node fed back by the central node in response to the subscription request;

[0074] The acquisition module is specifically used to update the corresponding relationship stored in the downstream CDN node according to the corresponding relationship synchronized by the central node.

[0075] In a seventh aspect of the implementation of the present application, a data return source device is also provided, which is applied to an upstream service node, and the device includes:

[0076] A second sending module, configured to send a registration request to the central node in response to the start operation, wherein the registration request includes an identifier and an IP address of the upstream service node;

[0077] The reporting module is used to report the updated IP address to the central node in response to the IP address change of the upstream service node.

[0078] In a possible implementation manner, the identifier of the upstream service node includes: a service name provided by the upstream service node and / or a service version provided by the upstream service node.

[0079] In an eighth aspect of the implementation of the present application, there is further provided a network node, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0080] Memory, used to store computer programs;

[0081] The processor is used to implement the data return method described in the second aspect, the third aspect or the fourth aspect when executing the program stored in the memory.

[0082] In the ninth aspect of the implementation of the present application, a computer-readable storage medium is further provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the data return method described in the second aspect, the third aspect or the fourth aspect is implemented.

[0083] In the tenth aspect of the implementation of the present application, a computer program product comprising instructions is also provided. When the computer program product is run on a computer, the computer executes the data return method described in the second aspect, the third aspect or the fourth aspect.

[0084] In the technical solution provided by the embodiment of the present application, when the upstream service node is started or the IP address is changed, the real-time IP address will be reported to the central node. Then the central node can obtain the IP address reported by the upstream service node in real time, and store the correspondence between the identifier of the upstream service node that will not change and the IP address of the upstream service node. The downstream CDN node can obtain the correspondence between the identifier and the real-time IP address of each upstream service node from the central node, and then when returning data to the source, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the correspondence obtained from the central node, and return data to the source based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improve the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduce the return time, and also improve the return processing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art are briefly introduced below.

[0086] Figure 1 The figure is a flowchart of the back-to-origin process in a CDN in the prior art;

[0087] Figure 2 It is a structural diagram of CDN in the prior art;

[0088] Figure 3 A schematic diagram of the structure of a data return source system provided in an embodiment of the present application;

[0089] Figure 4 A signaling interaction diagram of the data return process provided in an embodiment of the present application;

[0090] Figure 5 A flowchart of a method for determining a target node identifier provided in an embodiment of the present application;

[0091] Figure 6A flowchart of a data return-to-source process of a data return-to-source system provided by an embodiment of the present application;

[0092] Figure 7 A schematic diagram of a flow chart of a data return method applied to a central node according to an embodiment of the present application;

[0093] Figure 8 A schematic diagram of a flow chart of a data back-to-source method applied to a downstream CDN node provided in an embodiment of the present application;

[0094] Fig. 9 A schematic diagram of a flow chart of a data return-to-source method applied to an upstream service node provided in an embodiment of the present application;

[0095] Fig.10 A schematic diagram of a structure of a data return source device applied to a central node provided in an embodiment of the present application;

[0096] Fig.11 A schematic diagram of a structure of a data return source device applied to a downstream CDN node provided in an embodiment of the present application;

[0097] Fig.12 A schematic diagram of a structure of a data return source device applied to an upstream service node provided in an embodiment of the present application;

[0098] Fig.13 A schematic diagram of the structure of a network node provided in an embodiment of the present application. DETAILED DESCRIPTION

[0099] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0100] With the popularity of cloud computing and microservice architecture, more and more services are migrated to cloud-native architecture, that is, upstream service nodes that can provide various services can be deployed in cloud-native architecture. Networks that adopt cloud-native architecture are usually accompanied by dynamic deployment of Pods (service instances), frequent expansion and contraction of the network, that is, frequent increase or decrease of network nodes, and frequent adjustment of Pod deployment for efficient resource utilization. Frequent increase or decrease of network nodes, as well as the restart and shutdown of each network node caused by the frequent scheduling of Pods deployed in each network node, will cause the IP address of each network node to change frequently.

[0101] CDN is an important network content service system that can provide users with efficient content distribution services. In CDN, back-to-source management is an important part of its content distribution services. Figure 1As shown, when a user requests to access content provided by a certain service, the downstream CDN node obtains the user's service request and checks whether it has cached the content requested by the user. If the downstream CDN node does not hit the content requested by the user, that is, the downstream CDN node does not cache the content requested by the user, the downstream CDN node needs to perform back-to-source processing for the user request, that is, request the upstream service node upstream for the content requested by the user. If the upstream service node caches the content requested by the user, the upstream service node can directly feedback to the downstream CDN node. If the upstream service node does not cache the content requested by the user, the upstream service node can directly request the original content requested by the user from the source station. Among them, the source station stores all the content that the network can provide to users; the downstream CDN node can also be called a cache node or a CDN node; the upstream service node can also be called a back-to-source node or a service node.

[0102] Figure 1 Only one back-to-source process and part of the CDN architecture are shown in FIG. Figure 2 shown. Figure 2 In the CDN, there are multiple downstream CDN nodes, multiple upstream service nodes and an origin site. The downstream CDN node can send a request to any upstream service node, and each upstream service node can request the original content from the origin site.

[0103] When the CDN bearer network adopts a cloud-native architecture, the IP addresses of various network nodes in the cloud-native architecture will change frequently, that is, the IP addresses of upstream service nodes will also change frequently, which makes it difficult for downstream CDN nodes to perceive the actual IP addresses of upstream service nodes in real time. When the downstream CDN node performs back-to-source processing, if the changed IP address is directly used for back-to-source processing, the hit rate of the downstream CDN node hitting the upstream service node will be low during back-to-source processing, which will in turn lead to a longer back-to-source time and lower back-to-source processing efficiency.

[0104] In order to solve the above problems, the present application embodiment provides a data return source system, such as Figure 3 As shown, the system includes: an upstream service node 301, a central node 302, and a downstream CDN node 303. The data back-to-source system may include multiple upstream service nodes 301, and may also include multiple downstream CDN nodes 303. The upstream service node 301, the central node 302, and the downstream CDN node 303 are all network nodes, and the network nodes may be servers, desktop computers, etc.

[0105] The upstream service node 301 is used to send a registration request to the central node in response to a startup operation, wherein the registration request includes the identifier and IP address of the upstream service node; in response to a change in the IP address of the upstream service node, report the updated IP address to the central node.

[0106] The identifier of the upstream service node 301 may include: the service name and / or the service version provided by the upstream service node. The identifier of the upstream service node 301 may also be a unique identifier assigned to it by a control server in the network. The identifiers of each network node in the network are different. The IP addresses of each network node in the network may be assigned by a DHCP (Dynamic Host Configuration Protocol) server. The DHCP server may periodically or conditionally assign new IP addresses to each network node in the network according to actual needs.

[0107] When the upstream service node 301 starts, the upstream service node 301 may send a request to the DHCP server to obtain an IP address assigned by the DHCP server to the upstream service node 301. Afterwards, the upstream service node generates a registration request according to the obtained IP address and its own identifier, and sends the registration request to the central node.

[0108] The IP address change of the upstream service node 301 may be that the upstream service node 301 receives a new IP address allocated by the DHCP server. After receiving the newly allocated IP address, the upstream service node 301 may report the updated IP address to the central node 302.

[0109] The central node 302 is used to store the correspondence between the identifier of the upstream service node and the IP address in the central node in response to the registration request; and update the IP address in the stored correspondence in response to the upstream service node reporting the IP address.

[0110] When the central node 302 receives the registration request from the upstream service node 301, it can parse the identifier and IP address in the registration request. The central node 302 can store the corresponding relationship between the identifier and IP address of the upstream service node 301 in the form of a list.

[0111] For example, the central node 302 obtains an identifier ID_A and an IP address IP_A from the registration request of the upstream service node A; the central node 302 obtains an identifier ID_B and an IP address IP_B from the registration request of the upstream service node B. The central node 302 can store the correspondence between the identifier and the IP address of the upstream service node in the form of a list: ID_A: IP_A, ID_B: IP_B.

[0112] When the IP address of the upstream service node 301 changes, the upstream service node 301 can report the updated IP address to the central node 302. After receiving the updated IP address reported by the upstream service node 301, the central node 302 can search for the identifier corresponding to the upstream service node 301 in the stored correspondence relationship, and update the IP address corresponding to the identifier found in the correspondence relationship. Afterwards, the central node 302 can also send the updated correspondence relationship stored by the central node 302 to the downstream CDN node 303.

[0113] For example, continuing the previous example, the central node 302 stores the corresponding relationship: ID_A: IP_A, ID_B: IP_B. The central node 302 receives the IP address IP_C reported by the upstream service node A. The central node 2 can search for the ID_A of the upstream service node A in the stored corresponding relationship, and update the IP address corresponding to ID_A in the corresponding relationship from IP_A to IP_C. After the update, the corresponding relationship stored in the central node 302 is: ID_A: IP_C, ID_B: IP_B.

[0114] The downstream CDN node 303 is used to obtain the corresponding relationship stored in the central node; in response to obtaining a service request from a user for a target service, determine the target node identifier of the upstream service node corresponding to the target service requested by the service request; based on the obtained corresponding relationship, determine the target IP address corresponding to the target node identifier; and based on the target IP address, perform data return to the source.

[0115] The downstream CDN node 303 may send an acquisition request to the central node 302 to acquire the corresponding relationship stored in the central node 302 . After receiving the request from the downstream CDN node 303 , the central node 302 may send the corresponding relationship stored in the central node 302 to the downstream CDN node 303 .

[0116] When a user needs to obtain a certain service content, that is, a target service, a service request for the content can be sent to the downstream CDN node 303. When the downstream CDN node 303 receives the service request sent by the user, it can first check whether the downstream CDN node 303 has cached the content requested by the user's service request. If the downstream CDN node 303 stores the content requested by the user's service request, the downstream CDN node 303 can feed back the stored content to the user. If the downstream CDN node 303 does not store the content requested by the user's service request, such as the content cached by the downstream CDN node 303 is removed or expired, the downstream CDN node 303 can determine the target node identifier of the upstream service node of the target service requested by the service request, so as to perform subsequent data return to the source and obtain the content stored by the upstream target node. The downstream CDN node 303 may also not search for cached content, but directly determine the target node identifier for data return to the source. This can improve the accuracy of the content fed back to the user.

[0117] The downstream CDN node 303 may store a correspondence between a request identifier and an identifier of an upstream service node. The downstream CDN node 303 may obtain the request identifier carried in the user's service request, and then determine the identifier of the upstream service node corresponding to the obtained request identifier as the target node identifier based on the correspondence between the request identifier stored in the downstream CDN node 303 and the identifier of the upstream service node. The request identifier may be the identifier of the target service requested by the user's service request, such as a URI (Uniform Resource Identifier).

[0118] Then, CND node 303 searches for an identifier that matches the target node identifier in the obtained correspondence between the identifier and the IP address of the upstream service node. After finding the identifier that matches the target node, the IP address corresponding to the identifier that matches the target node in the correspondence is determined as the target IP address.

[0119] Afterwards, the downstream CDN node 303 may use the target IP address as the destination address and forward the user's service request to the target IP address to obtain the content requested by the user.

[0120] If the upstream target node has previously received a service request for the same requested content, that is, the same target service, the target node may cache the content requested by the user. After the target node receives the user's service request forwarded by the downstream CDN node, it can first check whether it has cached the content requested by the user. If the target node stores the content requested by the user, the target node can directly feed back the content stored by itself to the downstream CDN node. If the target node does not store the content requested by the user, the target node can forward the user's service request to the source station to obtain the original content requested by the user.

[0121] In the technical solution provided by the embodiment of the present application, when the upstream service node is started or the IP address is changed, the real-time IP address will be reported to the central node. Then the central node can obtain the IP address reported by the upstream service node in real time, and store the correspondence between the identifier of the upstream service node that will not change and the IP address of the upstream service node. The downstream CDN node can obtain the correspondence between the identifier and the real-time IP address of each upstream service node from the central node, and then when returning data to the source, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the correspondence obtained from the central node, and return data to the source based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improve the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduce the return time, and also improve the return processing efficiency.

[0122] In order to more clearly illustrate the data return process of the above data return system, the present application embodiment also provides the following Figure 4 A signaling interaction diagram is shown.

[0123] Figure 4 In the example, when the upstream service node 301 is started, the upstream service node sends a registration request to the central node 302. The registration request may include the identifier and IP address of the upstream service node. When the IP address of the upstream service node changes, the updated IP address may also be reported to the central node.

[0124] After receiving the registration request from the upstream service node, the central node can store the correspondence between the identifier and the IP address of the upstream service node according to the identifier and the IP address carried in the registration request. After receiving the updated IP address reported by the upstream service node, the central node can also update the IP address in the stored correspondence of the upstream service node in response to the IP address reported by the upstream service node.

[0125] After a new correspondence is stored in the central node or a stored correspondence is updated, the new correspondence can be sent to the downstream CDN node 303 .

[0126] The downstream CDN node can obtain the corresponding relationship stored in the central node sent by the central node.

[0127] When the downstream CDN node receives a service request from a user, it can first determine the target node identifier of the upstream service node corresponding to the target service requested by the service request. Then, based on the corresponding relationship obtained above, the downstream CDN node determines the target IP address corresponding to the target node identifier. After that, the downstream CDN node performs data return based on the target IP address, that is, requests the target service requested by the user from the upstream service node corresponding to the target node identifier.

[0128] Afterwards, the downstream CDN node can feed back the service content of the target service obtained from the upstream service node to the user.

[0129] In a possible implementation, the downstream CDN node 303 may store a first hash value having an identifier, and may subsequently use the first hash value to determine the target node identifier of the target service requested by the service request.

[0130] Specifically, the downstream CDN node 303 may perform hash calculation on the identifier of each upstream service node in the corresponding relationship stored in the downstream CDN node to obtain multiple first hash values ​​of the identifier.

[0131] The first hash value may be an unsigned integer. For example, the first hash value may be 0 to 2. 32 For each identifier of the upstream service node in the corresponding relationship stored by the downstream CDN node 303, the downstream CDN node 303 can calculate 100 to 200 first hash values ​​of the identifier.

[0132] The downstream CDN node 303 may use a preset first hash function to use the identifiers of each upstream service node in the corresponding relationship stored in the downstream CDN node 303 as key values ​​to generate multiple first hash values ​​for each identifier. For example, the downstream CDN node may generate multiple corresponding virtual identifiers for each identifier, and perform hash mapping on the multiple virtual identifiers using the first hash function, thereby generating multiple first hash values ​​for the identifier of the same upstream service node.

[0133] After the downstream CDN node 303 generates multiple first hash values, it can store the first hash value corresponding to each upstream service node identifier. The downstream CDN node 303 can also store the generated first hash value on a consistent hash ring so that the target node identifier can be determined later based on the first hash value on the consistent hash ring.

[0134] After generating the first hash value, Figure 5As shown, the downstream CDN node 303 may determine the target node identifier of the upstream service node corresponding to the target service requested by the service request in the following manner, which comprises steps S501-S504.

[0135] Step S501: Generate a second hash value of a request identifier of a service request.

[0136] The downstream CDN node 303 may use a preset second hash function to generate a second hash value of the request identifier of the service request. The request identifiers for the same request content are also the same, that is, for service requests with the same request content, the second hash values ​​generated by the downstream CDN node 303 are also the same.

[0137] Step S502, searching the first hash value stored in the downstream CDN node for a third hash value that is greater than the second hash value and closest to the second hash value; if the third hash value is found, executing step S503; if the third hash value is not found, executing step S504.

[0138] The downstream CDN node 303 may search for the third hash value in all stored first hash values ​​by sequential search, binary search, etc. For service requests with the same request content, since the second hash values ​​generated by the downstream CDN node 303 are the same, the third hash values ​​determined based on the same second hash values ​​are also the same.

[0139] Step S503: determine the identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request.

[0140] After the downstream CDN node 303 finds the third hash value, it can find the identifier of the upstream service node corresponding to the third hash value, and use the identifier of the upstream service node as the target node identifier of the target service requested by the service request. For service requests with the same request content, since the determined third hash values ​​are the same, the target node identifiers determined according to the third hash values ​​are also the same.

[0141] Step S504: determine the recorded minimum first hash value as the third hash value, and determine the identifier corresponding to the third hash value as the target node identifier.

[0142] If the downstream CDN node 303 fails to find the third hash value, the recorded minimum first hash value can be determined as the third hash value. Then, the downstream CDN node can find the identifier of the upstream service node corresponding to the third hash value and use the identifier as the target node identifier of the target service requested by the service request.

[0143] In the technical solution provided by the embodiment of the present application, the identifier of the upstream service node is used as the key value of the hash mapping instead of the IP address, which can ensure the stability of the above-mentioned method of determining the target node identifier using the hash mapping. When the IP address changes frequently, the downstream CDN node can still determine the target node identifier of the upstream service node of the target service requested by the user's service request according to the above-mentioned hash mapping. Then, the downstream CDN node determines the target IP address of the upstream service node of the target service requested by the user's service request according to the corresponding relationship to return the data to the source. In this way, the downstream CDN node can perform a hash calculation based on the stable identifier of the upstream service node to obtain a first hash value, and can subsequently determine the target node identifier of the target service requested by the service request more accurately based on the first hash value, and then more accurately determine the target IP address of the upstream service node, further improving the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reducing the return time, and further improving the return processing efficiency.

[0144] In addition, in the technical solution provided by the embodiment of the present application, a fixed second hash function is used to determine the second hash value of the request identifier of the service request, and then the third hash value is determined according to the second hash value in the same manner, so that the third hash value determined by the downstream CDN node for the service request with the same request content is the same, and then the target node identifier determined according to the third hash value is also the same. In other words, for service requests with the same request content, the downstream CDN node can return to the same upstream service node. After requesting the request content from the source station once, the upstream service node can cache the request content, and then when the downstream CDN node requests the request content multiple times, it can directly feedback the request content to the downstream CDN node without requesting the original request content from the source station each time. In this way, the request content requested by the user can be fed back to the user more quickly, further improving the efficiency of the return-to-source processing and further improving the user experience.

[0145] In a possible implementation manner, the central node 302 may also monitor the status of the upstream service node, and when different statuses of the upstream service node are monitored, update the corresponding relationship stored in the central node in the following three ways respectively.

[0146] 1. If the monitored status indicates that the upstream service node has joined the CDN network, the identifier and IP address of the upstream service node are obtained from the upstream service node, and the corresponding relationship between the identifier and IP address of the upstream service node is stored in the central node.

[0147] The central node 302 can obtain the network status of each node in the network by sending a status information request to the DHCP server. When the central node 302 receives feedback from the DHCP server that a new upstream service node 301 has joined the CDN network, it can send a request to the DHCP server or the upstream service node 301 to obtain the identifier and IP address of the upstream service node 301. Then the central node 302 can store the corresponding relationship between the identifier and IP address of the upstream service node 301 obtained.

[0148] Second, if the monitored status indicates that the upstream service node has exited the CDN network, the correspondence between the identifier and the IP address of the upstream service node stored in the central node is deleted.

[0149] When the central node 302 receives feedback from the DHCP server that the upstream service node 301 has exited the CDN network, the central node 302 may delete the correspondence between the identifier of the upstream service node and the IP address stored in the central node.

[0150] 3. If the monitored status indicates that the IP address of the upstream service node has changed, the IP address in the correspondence between the identifier of the upstream service node and the IP address stored in the central node is updated.

[0151] When the central node 302 receives feedback from the DHCP server that the IP address of the upstream service node 301 has changed, the central node 302 can send a request to the DHCP server or the upstream service node 301 to obtain the IP address of the upstream service node 301. Then the central node 302 can update the IP address in the correspondence between the identifier of the upstream service node and the IP address stored in the central node.

[0152] In the technical solution provided by the embodiment of the present application, the central node can actively monitor the network status of the upstream service node in the network. When the status of the upstream service node changes but is not reported to the central node, the central node can still perceive the status change of the upstream service node. The central node can thus update the corresponding relationship stored by the central node, further improving the real-time and accuracy of the IP addresses of each upstream service node stored by the central node. As a result, the IP address of the upstream service node obtained by the subsequent downstream CDN node from the central node is more accurate, further improving the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reducing the return time, and further improving the return processing efficiency.

[0153] In a possible implementation, the downstream CDN node 303 may also send a subscription request to the central node when it is started, wherein the subscription request is used to subscribe to the corresponding relationship stored in the central node. After the central node receives the subscription request from the downstream CDN node, during the subscription period of the downstream CDN node, if the central node detects that the corresponding relationship stored in the central node has changed, the central node may synchronize the changed corresponding relationship to the downstream CDN node; the downstream CDN node updates the corresponding relationship stored in the downstream CDN node according to the corresponding relationship synchronized by the central node.

[0154] When the downstream CDN node 303 is started, the downstream CDN node 303 may send a subscription request for the corresponding relationship stored in the central node 302 to the central node 302. After receiving the subscription request sent by the downstream CDN node 303, the central node 302 may send the corresponding relationship stored in the central node to the downstream CDN node 303. The downstream CDN node 303 obtains and stores the corresponding relationship fed back by the central node 302 for the subscription request.

[0155] After detecting that the correspondence stored in the central node 302 has changed, the central node 302 synchronizes the changed correspondence to the downstream CDN node 303, that is, sends the changed correspondence to the downstream CDN node 303. The downstream CDN node 303 updates the correspondence stored in the downstream CDN node according to the correspondence sent by the central node.

[0156] In the technical solution provided by the embodiment of the present application, when the downstream CDN node is started, it can actively subscribe to the corresponding relationship stored in the central node. When the central node does not perceive that the downstream CDN node has joined the network, the downstream CDN node can also obtain the corresponding relationship stored in the central node, and after subscribing to the corresponding relationship stored in the central node, when the corresponding relationship stored in the central node is updated, the central node will synchronize to the downstream CDN node. The real-time and accuracy of the IP addresses of each upstream service node obtained by the downstream CDN node are further improved, which further improves the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduces the return time, and further improves the return processing efficiency.

[0157] In order to more clearly illustrate the data return source system provided in the embodiment of the present application, the embodiment of the present application also provides the following Figure 6 The process diagram is shown.

[0158] Figure 6When the upstream service node A and the upstream service node B are started, they send a registration request to the service registration and discovery center, that is, the above-mentioned central node. After receiving the registration request from the upstream service node, the service discovery and update interface of the service registration and discovery center stores the source node list of the identifier and IP address of the upstream service node A and the upstream service node B, that is, the corresponding relationship. After storing the source node list, the service registration and discovery center notifies the downstream service node, that is, the downstream CDN node, of the updated source node list.

[0159] The downstream service node includes a back-to-source management module. After receiving the notification from the service registration and discovery center, the back-to-source management module updates the back-to-source node list stored in the downstream service node according to the back-to-source node list included in the notification, that is, the corresponding relationship. The IP address in the back-to-source node list of the downstream service node is updated to a real-time IP address. The downstream service node performs a hash calculation on the identifier of each upstream service node in the updated back-to-source node list to obtain multiple first hash values ​​of the identifier, and stores these first hash values ​​in a consistent hash ring to construct a consistent hash ring.

[0160] When the downstream service node subsequently receives the user's service request, the downstream service node generates a second hash value based on the request identifier in the service request, and searches the first hash value stored in the consistent hash ring for a third hash value that is greater than the second hash value and closest to the second hash value. After obtaining the third hash value, the downstream service node determines the identifier corresponding to the third hash value as the target node identifier of the target service requested by the service request. Then, based on the acquired back-to-source node list, the downstream service node determines the back-to-source IP address corresponding to the target node identifier in the back-to-source node list, that is, the target IP address, and performs data back-to-source based on the back-to-source IP address, that is, according to the back-to-source processing mechanism, forwards the user's service request to the back-to-source IP address.

[0161] By applying the technical solution provided in the embodiment of the present application, CDN back-to-source management based on the cloud native architecture is optimized, which can effectively improve the back-to-source processing efficiency and response speed of the CDN under the cloud native architecture, reduce the back-to-source delay, and improve the user experience. In addition, since the accuracy of obtaining the IP address during the back-to-source processing is high, the number of times the downstream CDN node forwards the request is reduced, which also reduces the bandwidth consumption and reduces the operating cost of the CDN.

[0162] In addition, after combining CDN with cloud-native structure, the network has both the advantages of cloud-native structure such as high availability, elastic scaling, and automatic disaster recovery, as well as the advantages of CDN such as accelerated network feedback speed, allowing users to receive feedback faster after sending a request.

[0163] Corresponding to the above data return source system, the embodiment of the present application also provides a data return source method, such as Figure 7 As shown, applied to the central node 302, the method includes the following steps S701-S703.

[0164] Step S701, in response to a registration request from an upstream service node, storing a correspondence between an identifier of the upstream service node and an IP address in a central node;

[0165] Step S702, in response to the upstream service node reporting the updated IP address, updating the IP address in the corresponding relationship stored in the central node;

[0166] Step S703: Send the corresponding relationship stored in the central node to the downstream CDN node.

[0167] In the technical solution provided by the embodiment of the present application, when the upstream service node is started or the IP address is changed, the real-time IP address will be reported to the central node. Then the central node can obtain the IP address reported by the upstream service node in real time, and store the correspondence between the identifier of the upstream service node that will not change and the IP address of the upstream service node. The downstream CDN node can obtain the correspondence between the identifier and the real-time IP address of each upstream service node from the central node, and then when returning data to the source, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the correspondence obtained from the central node, and return data to the source based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improve the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduce the return time, and also improve the return processing efficiency.

[0168] In a possible implementation, the central node 302 may monitor the status of the upstream service node 301, and the data return method applied to the central node 302 may further include the following steps: monitoring the status of the upstream service node; if the monitored status indicates that the upstream service node has joined the CDN network, obtaining the identifier and IP address of the upstream service node from the upstream service node, and storing the correspondence between the identifier and the IP address of the upstream service node in the central node; if the monitored status indicates that the upstream service node has exited the CDN network, deleting the correspondence between the identifier and the IP address of the upstream service node stored in the central node; if the monitored status indicates that the IP address of the upstream service node has changed, updating the IP address in the correspondence between the identifier and the IP address of the upstream service node stored in the central node.

[0169] In a possible implementation, the downstream CDN node 303 may subscribe to the corresponding relationship stored in the central node. The data return method applied to the central node 302 may also include the following steps: receiving a subscription request for the corresponding relationship stored in the central node sent by the downstream CDN node, and sending the corresponding relationship stored in the central node to the downstream CDN node in response to the subscription request.

[0170] In this case, the above step S703 can be implemented in the following manner: after detecting that the corresponding relationship stored in the central node has changed, the changed corresponding relationship is synchronized to the downstream CDN node.

[0171] Corresponding to the above data return source system, the embodiment of the present application also provides a data return source method, such as Figure 8 As shown, applied to the downstream CDN node 303, the method includes the following steps S801-S804.

[0172] Step S801, obtaining the correspondence between the identifier and IP address of the upstream service node stored in the central node;

[0173] Step S802, in response to obtaining a service request for a target service from a user, determining a target node identifier of an upstream service node corresponding to the target service requested by the service request;

[0174] Step S803, determining the target IP address corresponding to the target node identifier based on the acquired corresponding relationship;

[0175] Step S804: Based on the target IP address, data is returned to the source.

[0176] In the technical solution provided by the embodiment of the present application, when the upstream service node is started or the IP address is changed, the real-time IP address will be reported to the central node. Then the central node can obtain the IP address reported by the upstream service node in real time, and store the correspondence between the identifier of the upstream service node that will not change and the IP address of the upstream service node. The downstream CDN node can obtain the correspondence between the identifier and the real-time IP address of each upstream service node from the central node, and then when returning data to the source, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the correspondence obtained from the central node, and return data to the source based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improve the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduce the return time, and also improve the return processing efficiency.

[0177] In a possible implementation, the data return method applied to the downstream CDN node 303 may further include the following steps: performing a hash calculation on the identifier of each upstream service node in the corresponding relationship stored in the downstream CDN node to obtain multiple first hash values ​​of the identifier.

[0178] In this case, the above-mentioned step S803 can be implemented in the following manner: generate a second hash value of the request identifier of the service request; search for a third hash value that is greater than the second hash value and closest to the second hash value in the first hash value stored in the downstream CDN node; if the third hash value is found, the identifier corresponding to the third hash value is determined as the target node identifier of the upstream service node corresponding to the target service requested by the service request; if the third hash value is not found, the recorded minimum first hash value is determined as the third hash value, and the identifier corresponding to the third hash value is determined as the target node identifier.

[0179] In one possible implementation, the downstream CDN node 303 may subscribe to the corresponding relationship stored in the central node from the central node. The data return-to-source method applied to the downstream CDN node 303 may also include the following steps: in response to a startup operation, sending a subscription request for the corresponding relationship stored in the central node to the central node; and obtaining the corresponding relationship stored in the central node fed back by the central node in response to the subscription request.

[0180] In this case, the above step S801 can be implemented in the following manner: according to the corresponding relationship synchronized by the central node, the corresponding relationship stored in the downstream CDN node is updated.

[0181] Corresponding to the above data return source system, the embodiment of the present application also provides a data return source method, such as Fig. 9 As shown, applied to the upstream service node 301, the method includes the following steps S901-S902.

[0182] Step S901, in response to a start operation, sending a registration request to a central node.

[0183] The registration request includes the identifier and IP address of the service node.

[0184] Step S902: In response to the IP address change of the upstream service node, report the updated IP address to the central node.

[0185] In the technical solution provided by the embodiment of the present application, when the upstream service node is started or the IP address is changed, the real-time IP address will be reported to the central node. Then the central node can obtain the IP address reported by the upstream service node in real time, and store the correspondence between the identifier of the upstream service node that will not change and the IP address of the upstream service node. The downstream CDN node can obtain the correspondence between the identifier and the real-time IP address of each upstream service node from the central node, and then when returning data to the source, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the correspondence obtained from the central node, and return data to the source based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improve the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduce the return time, and also improve the return processing efficiency.

[0186] In a possible implementation manner, the identifier of the upstream service node may include: a service name provided by the service node and / or a service version provided by the service node.

[0187] Corresponding to the above-mentioned data return method applied to the central node, the embodiment of the present application also provides a data return device, such as Fig.10 As shown, applied to the central node 302, the device includes:

[0188] The storage module 1001 is used to store the correspondence between the identifier and the IP address of the upstream service node in the central node in response to the registration request of the upstream service node;

[0189] An updating module 1002, configured to update the IP address in the corresponding relationship stored in the central node in response to the upstream service node reporting the updated IP address;

[0190] The first sending module 1003 is used to send the corresponding relationship stored in the central node to the downstream CDN node.

[0191] In the technical solution provided by the embodiment of the present application, when the upstream service node is started or the IP address is changed, the real-time IP address will be reported to the central node. Then the central node can obtain the IP address reported by the upstream service node in real time, and store the correspondence between the identifier of the upstream service node that will not change and the IP address of the upstream service node. The downstream CDN node can obtain the correspondence between the identifier and the real-time IP address of each upstream service node from the central node, and then when returning data to the source, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the correspondence obtained from the central node, and return data to the source based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improve the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduce the return time, and also improve the return processing efficiency.

[0192] In a possible implementation, the central node 302 may monitor the status of the upstream service node 301. The data return source device applied to the central node 302 may further include: a monitoring module, used to monitor the status of the upstream service node; if the monitored status indicates that the upstream service node joins the CDN network, the identifier and IP address of the upstream service node are obtained from the upstream service node, and the correspondence between the identifier and the IP address of the upstream service node is stored in the central node; if the monitored status indicates that the upstream service node exits the CDN network, the correspondence between the identifier and the IP address of the upstream service node stored in the central node is deleted; if the monitored status indicates that the IP address of the upstream service node has changed, the IP address in the correspondence between the identifier and the IP address of the upstream service node stored in the central node is updated.

[0193] In a possible implementation, the downstream CDN node 303 may subscribe to the corresponding relationship stored in the central node. The data return source device applied to the central node 302 may also include: a receiving module, which is used to receive a subscription request for the corresponding relationship stored in the central node sent by the downstream CDN node, and send the corresponding relationship stored in the central node to the downstream CDN node in response to the subscription request.

[0194] The first sending module 1003 may be specifically used to: after detecting that the corresponding relationship stored in the central node has changed, synchronize the changed corresponding relationship to the downstream CDN node.

[0195] Corresponding to the above-mentioned data return method applied to the downstream CDN node, the embodiment of the present application also provides a data return device, such as Fig.11 As shown, applied to the downstream CDN node 303, the device includes:

[0196] The acquisition module 1101 is used to acquire the correspondence between the identifier and the IP address of the upstream service node stored in the central node;

[0197] A first determining module 1102 is configured to determine, in response to obtaining a service request from a user for a target service, a target node identifier of an upstream service node corresponding to the target service requested by the service request;

[0198] A second determination module 1103 is used to determine a target IP address corresponding to the target node identifier based on the acquired corresponding relationship;

[0199] The back-to-source module 1104 is used to perform data back-to-source based on the target IP address.

[0200] In the technical solution provided by the embodiment of the present application, when the upstream service node is started or the IP address is changed, the real-time IP address will be reported to the central node. Then the central node can obtain the IP address reported by the upstream service node in real time, and store the correspondence between the identifier of the upstream service node that will not change and the IP address of the upstream service node. The downstream CDN node can obtain the correspondence between the identifier and the real-time IP address of each upstream service node from the central node, and then when returning data to the source, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the correspondence obtained from the central node, and return data to the source based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improve the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduce the return time, and also improve the return processing efficiency.

[0201] In a possible implementation, the data return source device applied to the downstream CDN node 303 may further include: a calculation module, which is used to perform hash calculation on the identifier of each upstream service node in the corresponding relationship stored in the downstream CDN node to obtain multiple first hash values ​​of the identifier.

[0202] The above-mentioned second determination module 1103 can be specifically used to: generate a second hash value of the request identifier of the service request; search for a third hash value that is greater than the second hash value and closest to the second hash value in the first hash value stored in the downstream CDN node; if the third hash value is found, the identifier corresponding to the third hash value is determined as the target node identifier of the upstream service node corresponding to the target service requested by the service request; if the third hash value is not found, the recorded minimum first hash value is determined as the third hash value, and the identifier corresponding to the third hash value is determined as the target node identifier.

[0203] In a possible implementation, the downstream CDN node 303 may send a subscription request to the central node to subscribe to the corresponding relationship stored in the central node. The data return source device applied to the downstream CDN node 303 may also include: a subscription module, which is used to send a subscription request for the corresponding relationship stored in the central node to the central node in response to a startup operation; and obtain the corresponding relationship stored in the central node that is fed back by the central node in response to the subscription request.

[0204] The acquisition module 1101 may be specifically used to update the corresponding relationship stored in the downstream CDN node according to the corresponding relationship synchronized by the central node.

[0205] Corresponding to the above-mentioned data return method applied to the service node, the embodiment of the present application also provides a data return device, such as Fig.12 As shown, applied to an upstream service node 301, the device includes:

[0206] The second sending module 1201 is used to send a registration request to the central node in response to the start operation, wherein the registration request includes the identifier and IP address of the upstream service node;

[0207] The reporting module 1202 is used to report the updated IP address to the central node in response to the IP address change of the upstream service node.

[0208] In the technical solution provided by the embodiment of the present application, when the upstream service node is started or the IP address is changed, the real-time IP address will be reported to the central node. Then the central node can obtain the IP address reported by the upstream service node in real time, and store the correspondence between the identifier of the upstream service node that will not change and the IP address of the upstream service node. The downstream CDN node can obtain the correspondence between the identifier and the real-time IP address of each upstream service node from the central node, and then when returning data to the source, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the correspondence obtained from the central node, and return data to the source based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improve the hit rate of the downstream CDN node hitting the accurate upstream service node when returning to the source, reduce the return time, and also improve the return processing efficiency.

[0209] In a possible implementation manner, the identifier of the upstream service node may include: a service name provided by the upstream service node and / or a service version provided by the upstream service node.

[0210] The present application also provides a network node, such as the upstream service node, central node or downstream CDN node, such as Fig.13As shown, it includes a processor 1301, a communication interface 1302, a memory 1303 and a communication bus 1304, wherein the processor 1301, the communication interface 1302, and the memory 1303 communicate with each other through the communication bus 1304.

[0211] Memory 1303, used for storing computer programs;

[0212] The processor 1301 is used to implement any data return method in the above embodiments when executing the program stored in the memory 1303.

[0213] The communication bus mentioned in the above network node can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0214] The communication interface is used for communication between the above network nodes and other devices.

[0215] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0216] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0217] In another embodiment provided in the present application, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, any data return method in the above embodiments is implemented.

[0218] In another embodiment provided in the present application, a computer program product including instructions is also provided, which, when executed on a computer, enables the computer to execute any of the data return methods in the above embodiments.

[0219] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive Solid State Disk (SSD)), etc.

[0220] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0221] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the method, device, network node, storage medium, and computer program product embodiments, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0222] The above description is only a preferred embodiment of the present application and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims

1. A data back-to-source system, characterized in that: The system includes: an upstream service node, a central node and a downstream content distribution network CDN node; wherein, The upstream service node is configured to send a registration request to the central node in response to a start operation, wherein the registration request includes an identifier and an IP address of the upstream service node; and report an updated IP address to the central node in response to a change in the IP address of the upstream service node; The central node is configured to store, in response to the registration request, a correspondence between the identifier of the upstream service node and the IP address in the central node; and, in response to the updated IP address reported by the upstream service node, update the IP address in the correspondence stored in the central node; The downstream CDN node is used to obtain the corresponding relationship stored in the central node; in response to obtaining a service request from a user for a target service, determine the target node identifier of the upstream service node corresponding to the target service requested by the service request; based on the obtained corresponding relationship, determine the target IP address corresponding to the target node identifier; and based on the target IP address, perform data return to the source.

2. The system according to claim 1, characterized in that The downstream CDN node is further configured to perform hash calculation on the identifier of each upstream service node in the corresponding relationship stored in the downstream CDN node to obtain multiple first hash values ​​of the identifier.

3. The system according to claim 2, characterized in that The determining of the target node identifier of the upstream service node corresponding to the target service requested by the service request includes: Generate a second hash value of the request identifier of the service request; Searching, among the first hash values ​​stored in the downstream CDN node, a third hash value that is greater than the second hash value and closest to the second hash value; If the third hash value is found, determining the identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request; If the third hash value is not found, the recorded minimum first hash value is determined as the third hash value, and the identifier corresponding to the third hash value is determined as the target node identifier.

4. The system according to claim 1, characterized in that The central node is further configured to monitor the status of the upstream service node; if the monitored status indicates that the upstream service node has joined the CDN network, the identifier and IP address of the upstream service node are obtained from the upstream service node, and the corresponding relationship between the identifier and the IP address of the upstream service node is stored in the central node; If the monitored status indicates that the upstream service node has exited the CDN network, deleting the correspondence between the identifier and the IP address of the upstream service node stored in the central node; If the monitored status indicates that the IP address of the upstream service node has changed, the IP address in the correspondence between the identifier of the upstream service node and the IP address stored in the central node is updated.

5. The system according to claim 1, characterized in that The downstream CDN node is further configured to send a subscription request to the central node in response to a start operation, wherein the subscription request is used to subscribe to the corresponding relationship stored in the central node; The central node is further configured to synchronize the changed corresponding relationship to the downstream CDN node after detecting that the corresponding relationship stored in the central node changes; The downstream CDN node is specifically configured to update the corresponding relationship stored in the downstream CDN node according to the corresponding relationship synchronized by the central node.

6. The system according to any one of claims 1 to 5, characterized in that: The identifier of the upstream service node includes: a service name provided by the upstream service node and / or a service version provided by the upstream service node.

7. A data return method, characterized in that: Applied to the central node, the method includes: In response to a registration request from an upstream service node, storing a correspondence between an identifier of the upstream service node and an IP address in the central node; In response to the upstream service node reporting the updated IP address, updating the IP address in the corresponding relationship stored by the central node; The corresponding relationship stored in the central node is sent to the downstream CDN node.

8. A data return method, characterized in that: Applied to a downstream content distribution network CDN node, the method comprises: Obtain the correspondence between the identifier and IP address of the upstream service node stored in the central node; In response to obtaining a service request for a target service from a user, determining a target node identifier of an upstream service node corresponding to the target service requested by the service request; Based on the acquired corresponding relationship, determine the target IP address corresponding to the target node identifier; Based on the target IP address, data is returned to the source.

9. A data source return method, characterized in that: Applied to an upstream service node, the method comprises: In response to the start operation, sending a registration request to the central node, wherein the registration request includes an identifier and an IP address of the upstream service node; In response to the IP address change of the upstream service node, an updated IP address is reported to the central node.

10. A network node, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method described in any one of claims 7 to 9 when executing a program stored in a memory.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 7 to 9 is implemented.

Citation Information

Patent Citations

  • CDN back-to-source method, first server and system thereof

    CN103747112A

  • Transit method and device for back-to-source request, and back-to-source system

    CN106101183A

  • Data back-to-source method and device

    CN108566370A

  • Method and device for collecting object identifier, electronic equipment and storage medium

    CN113282941A

  • CDN (Content Delivery Network) request scheduling method for reducing back-to-source rate

    CN117201618A