Request scheduling method and apparatus, storage medium, device, and program product

Abstract

This application discloses a request scheduling method, apparatus, storage medium, device, and program product, applicable to cloud technology, video streaming services, cloud storage, and file sharing scenarios. The method includes: receiving a segmented request from a client for obtaining target data, where the target data is a portion of data in a target file; logically dividing the target file into multiple sub-files; mapping the multiple sub-files to multiple Content Delivery Network (CDN) nodes based on a preset load balancing algorithm, such that each sub-file has a corresponding CDN node, and at least two sub-files correspond to two different CDN nodes; determining the target sub-file corresponding to the target data; and scheduling the segmented request to the target CDN node so that the client obtains the target data from the target CDN node. This application achieves load balancing in large file segmented request scenarios, fully utilizing CDN network node resources and improving the efficiency and stability of content distribution.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a request scheduling method, apparatus, storage medium, device, and program product. Background Technology

[0002] In today's digital age, with the booming development of internet services, Content Delivery Networks (CDNs) play a crucial role in providing efficient and stable content delivery services. Users' needs for data acquisition are becoming increasingly diverse and complex, with segmented requests for large files becoming more common, such as on-demand downloads of videos and large software programs.

[0003] The segmented request scenario in related technologies suffers from problems such as unbalanced load and insufficient utilization of CDN network node resources. Summary of the Invention

[0004] This application provides a request scheduling method, apparatus, storage medium, device, and program product that can allocate different sub-files belonging to the same file to different CDN nodes, avoiding the concentration of multiple segmented requests on a single node, effectively solving the load balancing problem in large file segmented request scenarios, and improving the overall performance and stability of the CDN network.

[0005] On one hand, embodiments of this application provide a request scheduling method, the method comprising:

[0006] Receive a segmented request sent by the client for obtaining target data, wherein the target data is a portion of data in the target file;

[0007] The target file is logically divided into multiple sub-files;

[0008] Based on a preset load balancing algorithm, the multiple sub-files are mapped to multiple content delivery network (CDN) nodes, so that each sub-file has a corresponding CDN node, and at least two sub-files have two different CDN nodes corresponding to them.

[0009] Determine the target sub-file corresponding to the target data;

[0010] The segmented request is scheduled to the target CDN node corresponding to the target sub-file, so that the client can obtain the target data from the target CDN node.

[0011] On the other hand, embodiments of this application provide a request scheduling apparatus, the apparatus comprising:

[0012] The receiving unit is configured to receive a segmented request sent by the client for obtaining target data, wherein the target data is a portion of data in a target file;

[0013] A partitioning unit is used to logically divide the target file into multiple sub-files;

[0014] The mapping unit is used to map the multiple sub-files to multiple content delivery network (CDN) nodes based on a preset load balancing algorithm, so that each sub-file has a corresponding CDN node, and at least two sub-files have two different CDN nodes corresponding to them.

[0015] The determining unit is used to determine the target sub-file corresponding to the target data;

[0016] The scheduling unit is used to schedule the segmented request to the target CDN node corresponding to the target sub-file, so that the client can obtain the target data from the target CDN node.

[0017] In some embodiments, when the mapping unit is used to map the plurality of sub-files to the plurality of CDN nodes based on a preset load balancing algorithm, it is specifically used for:

[0018] For each subfile among the plurality of subfiles, determine a unique subfile identifier corresponding to each subfile;

[0019] Based on a preset load balancing algorithm, the sub-file identifiers corresponding to each sub-file are mapped to a CDN node, so that at least two CDN nodes corresponding to two sub-file identifiers are two different CDN nodes.

[0020] In some embodiments, when the scheduling unit schedules the segmented request to the target CDN node corresponding to the target sub-file, it is specifically used for:

[0021] Based on the sub-file identifier corresponding to the target sub-file, the segmented request is scheduled to the target CDN node corresponding to the target sub-file.

[0022] In some embodiments, when the determining unit determines a unique subfile identifier corresponding to each subfile among the plurality of subfiles, it is specifically used for:

[0023] For each of the multiple subfiles, a unique subfile identifier is determined based on a hash algorithm.

[0024] In some embodiments, when the determining unit determines the unique sub-file identifier corresponding to each sub-file based on a hash algorithm for each sub-file among the plurality of sub-files, it is specifically used for:

[0025] For each of the multiple subfiles, the filename of the target file and the byte range of each subfile in the target file are hashed to obtain a unique subfile identifier corresponding to each subfile.

[0026] In some embodiments, the preset load balancing algorithm is a consistent hashing algorithm.

[0027] In some embodiments, when the partitioning unit is used to logically divide the target file into multiple sub-files, it is specifically used for:

[0028] The target file is logically divided into multiple sub-files based on a preset partition size.

[0029] In some embodiments, the preset partition size is determined based on the file type of the target file.

[0030] On the other hand, an embodiment of this application provides a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the request scheduling method as described in any of the above embodiments.

[0031] On the other hand, an embodiment of this application provides a computer device, which includes a processor and a memory. The memory stores a computer program, and the processor executes the request scheduling method as described in any of the above embodiments by calling the computer program stored in the memory.

[0032] On the other hand, an embodiment of this application provides a computer program product, including computer instructions that, when executed by a processor, implement the request scheduling method as described in any of the above embodiments.

[0033] This application embodiment receives a segmented request from a client to obtain target data, where the target data is a portion of data in a target file; logically divides the target file into multiple sub-files; maps the multiple sub-files to multiple Content Delivery Network (CDN) nodes based on a preset load balancing algorithm, ensuring that each sub-file has a corresponding CDN node, and at least two sub-files correspond to two different CDN nodes; determines the target sub-file corresponding to the target data; and schedules the segmented request to the target CDN node corresponding to the target sub-file, so that the client obtains the target data from the target CDN node. This scheme, upon receiving a segmented request to obtain partial data from a target file, logically divides the target file into multiple sub-files and assigns different sub-files to different CDN nodes, thereby evenly distributing the request across all nodes. This avoids multiple segmented requests concentrating on a single node, effectively solving the load balancing problem in large file segmented request scenarios and improving the overall performance and stability of the CDN network. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a schematic diagram illustrating the first principle of a CDN request scheduling scheme in related technologies.

[0036] Figure 2 This is a second principle diagram of a CDN request scheduling scheme in related technologies.

[0037] Figure 3 This is a schematic diagram illustrating the third principle of CDN request scheduling schemes in related technologies.

[0038] Figure 4 This is a schematic diagram illustrating an application scenario of the request scheduling system provided in an embodiment of this application.

[0039] Figure 5 This is a flowchart illustrating the request scheduling method provided in an embodiment of this application.

[0040] Figure 6 This is a schematic diagram of a first application scenario of the request scheduling method provided in the embodiments of this application.

[0041] Figure 7 This is a schematic diagram of a second application scenario of the request scheduling method provided in the embodiments of this application.

[0042] Figure 8 This is a schematic diagram of a third application scenario for the request scheduling method provided in the embodiments of this application.

[0043] Figure 9 This is a schematic diagram of a fourth application scenario of the request scheduling method provided in the embodiments of this application.

[0044] Figure 10 This is a schematic diagram of the structure of the request scheduling device provided in the embodiments of this application.

[0045] Figure 11 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0046] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0047] This application provides a request scheduling method, apparatus, storage medium, device, and program product. Exemplarily, the request scheduling method of this application can be executed by a computer device, which can be a terminal or a server, etc. The terminal can be a smartphone, tablet, laptop, desktop computer, smart TV, smart speaker, wearable smart device, personal computer (PC), smart vehicle terminal, etc. The terminal can also include a client, which can be a video client, shopping application client, reading application client, browser client, or instant messaging client, etc. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms.

[0048] The embodiments of this application can be applied to scenarios such as cloud technology, video streaming services, cloud storage, and file sharing.

[0049] First, some of the nouns or terms that appear in the description of the embodiments of this application are explained as follows:

[0050] Fragmented Requests: Fragmented requests (byte range requests) are a feature of the HTTP protocol that allows clients to request a portion of a resource from the server instead of the entire resource. This is very useful in scenarios such as large file downloads, video streaming, and implementing resumeable downloads. Fragmented requests are implemented through a byte range header, allowing the client to specify the range of data it wants to retrieve when making the request.

[0051] CDN: A CDN is a distributed network architecture that caches content on nodes closest to users by deploying server nodes across multiple geographical locations. When a user requests content, the system delivers the content to the user from the node closest to the user or with the best network conditions, based on factors such as the user's geographical location. This improves content delivery speed and response performance, reduces latency, and enhances user experience. It is commonly used to accelerate the distribution of various online content such as web pages, images, videos, and scripts.

[0052] Origin pull: In network architectures such as CDNs, when a CDN node receives a user request but does not have the required content cached on that node, the CDN node sends a request to the origin server to retrieve the content. This process is called origin pull. The purpose of origin pull is to retrieve the missing content and cache it on the CDN node so that subsequent identical requests can be served directly from the CDN node, reducing the access pressure on the origin server and improving content distribution efficiency and response speed.

[0053] MD5 (Message-Digest Algorithm 5): The MD5 algorithm is based on iterative processing of data blocks. It takes data of arbitrary length as input, performs a series of complex bit operations, and finally outputs a 128-bit (16-byte) hash value.

[0054] SHA-256 (Secure Hash Algorithm 256-bit): SHA-256 belongs to the SHA-2 series of algorithms. It also takes data of arbitrary length as input and outputs a 256-bit (32-byte) hash value.

[0055] The solutions provided in this application relate to technologies such as request scheduling in CDN systems, and are specifically illustrated through the following embodiments. These embodiments are described in detail below. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0056] Before introducing the request scheduling method provided in the embodiments of this application, we will first introduce the problems existing in CDN request scheduling schemes in related technologies.

[0057] Please see Figures 1 to 3 , Figures 1 to 3These are schematic diagrams illustrating the principles of CDN request scheduling schemes in related technologies.

[0058] When a user needs to download a file, they typically send an HTTP request to the content delivery network (CDN) to request the corresponding file content. In video playback scenarios, the client usually initiates segmented requests one after another, downloading on demand to avoid wasting bandwidth; in file download scenarios, the client typically sends multiple segmented requests concurrently to speed up the download. For example, to download a 50MB file, the client might send five concurrent segmented requests to retrieve byte range 1 (or range1) (0-10MB), byte range 2 (10-20MB), byte range 3 (20-30MB), byte range 4 (30-40MB), and byte range 5 (40-50MB).

[0059] like Figure 1 As shown, for multiple concurrent requests from clients to retrieve different segments of file A, CDN request scheduling schemes in related technologies treat these multiple segment requests equally, scheduling them to the same node (e.g., node a). However, when dealing with segmented requests for large files, if file A is frequently accessed, node a's load will be significantly higher than other nodes, causing node a to bear enormous load pressure. This can easily lead to performance degradation, increased response latency, and even service crashes.

[0060] like Figure 2 As shown, due to the limited bandwidth of node a (e.g., 100Mbps), no matter how many segment requests the client makes concurrently, the maximum download speed of the client for file A can only reach 100Mbps, resulting in a download speed bottleneck.

[0061] like Figure 3 As shown, if file A is popular and multiple clients request it simultaneously, the total bandwidth for these requests could reach 500Mbps. In this case, five 100Mbps nodes would be needed to fulfill these requests. However, since none of the nodes initially cache file A, each node needs to retrieve the complete file A from the origin server, resulting in a total of five origin fetches and a significantly increased origin fetch rate. This not only increases bandwidth costs but also puts a heavy burden on the origin server.

[0062] Therefore, CDN request scheduling schemes in related technologies have the following drawbacks:

[0063] Download speed bottleneck: Although the client makes multiple segmented requests concurrently, these requests may all be scheduled to the same CDN node. Limited by the uplink bandwidth of a single node, the advantages of concurrent requests cannot be fully utilized.

[0064] Uneven load: Multiple segmented requests are scheduled to the same or the same batch of CDN nodes, resulting in uneven node load, with some nodes being overloaded while other nodes are idle.

[0065] High origin pull rate: Multiple CDN nodes need to cache the same file, which increases origin pull traffic, bandwidth costs, and pressure on the origin server.

[0066] Therefore, the request scheduling method provided in this application aims to effectively solve these problems, realize load balancing in large file segmentation request scenarios, make full use of CDN network node resources, improve the efficiency and stability of content distribution, and meet the ever-growing Internet business needs.

[0067] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating an application scenario of the request scheduling system provided in this application embodiment. The system can implement a request scheduling method and includes a client 10, a central scheduler 20, and a target CDN node 30, wherein:

[0068] Client 10 is responsible for initiating segmented requests to the system to obtain target data. When there is a need to obtain partial data of the target file, client 10 generates a corresponding segmented request and sends it to the central scheduler 20. For example, in a video playback scenario, client 10 can calculate the video segment data to be obtained based on the current viewing progress of the object and form a corresponding segmented request.

[0069] The central scheduler 20 serves as the core management and scheduling center of the system. Upon receiving a segmentation request from client 10, the central scheduler 20 parses the request information, determines the target sub-file corresponding to the target data, logically divides the target file into multiple sub-files, and maps these sub-files to multiple CDN nodes based on a preset load balancing algorithm. This ensures that each sub-file has a corresponding CDN node, and at least two sub-files correspond to two different CDN nodes. The central scheduler then determines the target sub-file corresponding to the target data and schedules the segmentation request to the target CDN node corresponding to that sub-file. For example, it informs client 10 of the redirection via status code 302 or other means, enabling client 10 to initiate a segmentation request to the target CDN node to retrieve the target data. It should be noted that the central scheduler 20 in this application can be the same server as the existing control server in the CDN system, meaning the existing control server has added segmentation request scheduling functionality to its original functions; or it can be a different server, i.e., an independent server specifically for segmentation request scheduling. The technical solution of this application does not limit the specific implementation of the control server, as long as it can achieve the request scheduling function based on the logical division of the target file.

[0070] The target CDN node 30 is a specific storage and distribution unit in the content delivery network. Target CDN node 30 caches one or more specific sub-files. These sub-files are the result of logically dividing the target file (such as a complete movie, a large software package, etc.). At least two sub-files within the target file are stored on two different CDN nodes to achieve distributed data storage and load balancing. For example, if the target file is evenly divided into 10 sub-files, each CDN node may be responsible for storing one of the sub-files to ensure data redundancy and efficient access.

[0071] This application provides a request scheduling method, which is described in this application embodiment as a request scheduling method. Figure 4 The following explanation will be based on the execution of the central scheduler 20.

[0072] Please see Figures 5 to 9 , Figure 5 This is a flowchart illustrating the request scheduling method provided in an embodiment of this application. Figures 6 to 9 These are all schematic diagrams illustrating application scenarios of the request scheduling method provided in the embodiments of this application. The method may include the following steps 110 to 150:

[0073] Step 110: Receive a segmentation request sent by the client to obtain target data, wherein the target data is a portion of the data in the target file.

[0074] The central scheduler receives segment requests from clients to retrieve target data. For example, when watching high-definition video through a video client, the client sends segment requests to the central scheduler based on the video playback progress, requesting to retrieve the video segment data required for the current playback. This data is part of the target file, the video file.

[0075] Step 120: Logically divide the target file into multiple sub-files.

[0076] The central scheduler logically (or virtually) divides the target file into multiple sub-files.

[0077] In some embodiments, the central scheduler logically divides the target file into multiple sub-files, including: logically dividing the target file into multiple sub-files based on a preset division size.

[0078] Specifically, after the target file is logically divided based on the preset partition size, each sub-file is the same size.

[0079] In some embodiments, the preset partition size is determined based on the file type of the target file.

[0080] In some embodiments, the file type of the target file may include, but is not limited to, the frequency of request for the target file and / or the file size.

[0081] Specifically, for target files that are requested frequently, they can be divided into smaller sub-files to improve cache hit rate and transmission efficiency. For example, highlights of popular videos are often watched repeatedly by users, so dividing these segments into smaller sub-files facilitates caching by CDN nodes and faster response to requests; for file parts that are requested less frequently, i.e., rarely requested, the sub-file size can be larger.

[0082] You can also set the preset partition size for the target file based on the file size. For example, for a target file with a large file size, you can set the preset partition size to be larger to accommodate the number of CDN nodes in the system. For a target file with a small file size, you can set the preset partition size to be smaller.

[0083] For example, for each sub-file in the target file, there can be a different CDN node corresponding to each sub-file, or some sub-files can correspond to the same CDN node, while the remaining sub-files can correspond to different CDN nodes.

[0084] In some embodiments, the central scheduler may, upon first receiving a segmentation request from a client to obtain partial data of a target file, logically divide the target file into multiple sub-file targets and save the segmentation data or segmentation records; alternatively, it may execute the step of logically dividing the target file into multiple sub-file targets each time it receives a segmentation request to obtain data from a target file.

[0085] Specifically, when the target file is a dynamic file—meaning its characteristics are not fixed and each segmentation request may have different partitioning requirements—the central scheduler needs to logically partition the target file after receiving each segmentation request. For example, some real-time generated files, such as big data analysis report files generated from real-time object operations, have different data volume and data structure each time, making it impossible to pre-set a fixed partitioning method. The central scheduler can only determine a suitable partitioning strategy in real time based on factors such as the specific content and size of the report and the current CDN node load when it receives a segmentation request to retrieve a portion of the report data.

[0086] When the target file is a static file—meaning its characteristics are stable, its size, structure, and other information are fixed, and the previous partitioning strategy has been proven efficient—the central scheduler can reuse the previous partitioning results. For example, a classic movie video file has a fixed duration and resolution. After multiple tests and optimizations, a reasonable partitioning method has been determined. When a client subsequently requests segmented data from that movie, the central scheduler does not need to repartition; it can directly use the existing partitioning scheme for request scheduling. This saves the computational resources and time required for file partitioning.

[0087] like Figure 6 As shown in the specific embodiment provided in this application, assuming the target file is file A, for file A with a size of 50MB, the preset file size corresponding to file A can be set to 10MB. Then file A includes 5 sub-files, each with a size of 10MB, specifically including sub-file 1 (corresponding to a byte range of 0-10MB, denoted as byte range 1), sub-file 2 (corresponding to a byte range of 10-20MB, denoted as byte range 2), sub-file 3 (corresponding to a byte range of 20-30MB, denoted as byte range 3), sub-file 4 (corresponding to a byte range of 30-40MB, denoted as byte range 4), and sub-file 5 (corresponding to a byte range of 40-50MB, denoted as byte range 5). The CDN node corresponding to sub-file 1 is node a, the CDN node corresponding to sub-file 2 is node b, the CDN node corresponding to sub-file 3 is node c, the CDN node corresponding to sub-file 4 is node d, and the CDN node corresponding to sub-file 5 is node e.

[0088] Step 130: Based on a preset load balancing algorithm, map multiple sub-files to multiple Content Delivery Network (CDN) nodes, so that each sub-file has a corresponding CDN node, and at least two sub-files have two different CDN nodes.

[0089] The central scheduler can use a preset load balancing algorithm to map multiple sub-files to multiple content delivery network (CDN) nodes to balance the load on the CDN nodes, so that each sub-file has a corresponding CDN node, and at least two sub-files have two different CDN nodes.

[0090] This application does not limit the type of preset load balancing algorithm. Any load balancing algorithm that can achieve the purpose of this application can be used in the embodiments of this application.

[0091] In some embodiments, mapping multiple sub-files to multiple CDN nodes based on a preset load balancing algorithm may include the following steps 1301 to 1302:

[0092] Step 1301: For each subfile in the multiple subfiles, determine the unique subfile identifier corresponding to each subfile.

[0093] For each subfile within a set of subfiles, the server assigns a unique subfile identifier to each subfile.

[0094] In some embodiments, for each subfile among multiple subfiles, determining a unique subfile identifier corresponding to each subfile includes:

[0095] For each subfile in a set of multiple subfiles, a unique subfile identifier is determined based on a hash algorithm.

[0096] The central scheduler can generate a unique sub-file identifier for each sub-file based on a hash algorithm.

[0097] In some embodiments, for each subfile among multiple subfiles, a unique subfile identifier corresponding to each subfile is determined based on a hash algorithm, including:

[0098] For each subfile in the multiple subfiles, hash the filename of the target file and the byte range of each subfile in the target file to obtain a unique subfile identifier for each subfile.

[0099] For example, for a target file A that includes subfiles 1 to 5, the filenames and byte ranges are hashed to calculate the subfile identifiers of subfiles 1 to 5 as file_hash_1, file_hash_2, file_hash_3, file_hash_4, and file_hash_5, respectively.

[0100] This application does not restrict the specific type of hash algorithm used to generate sub-file identifiers; for example, hash algorithms such as MD5 or SHA-256 can be used.

[0101] In other embodiments, a unique sub-file identifier can be generated for each sub-file based on a timestamp or a random number.

[0102] Specifically, when dividing the target file into subfiles, a unique timestamp is generated for each subfile as its identifier. For example, the creation time can be accurate to the millisecond level. This method generates unique and sequential identifiers, facilitating the management of subfiles according to time order. Alternatively, a cryptographically secure random number generator can be used to generate a unique random number for each subfile as its identifier. During the generation process, the random number is ensured to be of sufficient length (e.g., 128 bits) to reduce the probability of duplication. Random number identifiers increase the unpredictability of subfile identifiers, making them suitable for scenarios with high security requirements.

[0103] Step 1302: Based on a preset load balancing algorithm, map the sub-file identifiers corresponding to each sub-file to CDN nodes respectively, so that at least two CDN nodes corresponding to two sub-file identifiers are two different CDN nodes.

[0104] In some embodiments, the preset load balancing algorithm can be a consistent hashing algorithm. The central scheduler, based on the preset load balancing algorithm, maps the sub-file identifiers corresponding to each sub-file to CDN nodes, including:

[0105] The central scheduler selects the CDN node that is closest to the location of the subfile identifier corresponding to the target subfile on the hash ring as the target CDN node.

[0106] Consistent hashing distributes all possible hash values ​​onto a ring (hash ring), mapping CDN nodes to this ring as well. Based on the position of the sub-file's hash value (sub-file identifier) ​​on the hash ring, the nearest CDN node is found in a clockwise direction, thus determining the storage and access node for the sub-file.

[0107] For example, for file A which includes subfiles 1 to 5, the subfile identifiers of subfiles 1 to 5 are file_hash_1, file_hash_2, file_hash_3, file_hash_4, and file_hash_5, respectively. Using the consistent hashing algorithm, the CDN node corresponding to file_hash_1 is determined to be node a, the CDN node corresponding to file_hash_2 is node b, the CDN node corresponding to file_hash_3 is node c, the CDN node corresponding to file_hash_4 is node d, and the CDN node corresponding to file_hash_5 is node e. That is, the CDN nodes corresponding to subfiles 1 to 5 are CDN node a, CDN node b, CDN node c, CDN node d, and CDN node e, respectively.

[0108] Step 140: Determine the target sub-file corresponding to the target data.

[0109] After receiving a segmentation request, the central scheduler needs to accurately determine the target sub-file corresponding to the target data.

[0110] Specifically, the central scheduler parses the received segmentation request, determines the specific byte range of the target data in the target sub-file, and then finds the target sub-file containing that specific byte range.

[0111] In some embodiments, to improve search efficiency, an index table can be created to associate the characteristics of the target data (such as byte range, data identifier, etc.) with the target sub-file. In this way, when a request is received, the target sub-file can be quickly located directly through the index table.

[0112] Step 150: The segmented request is scheduled to the target CDN node corresponding to the target sub-file so that the client can obtain the target data from the target CDN node.

[0113] After the target sub-file is determined, the central scheduler will schedule the segmented requests to the target CDN node corresponding to the target sub-file, so that the client can obtain the target data from the target CDN node.

[0114] In the request scheduling method provided in this application embodiment, compared with the related technology that schedules and acquires data for a whole target file in a unified manner, the request scheduling method provided in this application embodiment avoids multiple segmented requests being concentrated on a single CDN node by allocating different sub-files to different CDN nodes. This effectively solves the load balancing problem in the scenario of large file segmented requests and improves the overall performance and stability of the CDN network.

[0115] In some embodiments, scheduling segmented requests to the target CDN node corresponding to the target sub-file may include: scheduling segmented requests to the target CDN node corresponding to the target sub-file based on the sub-file identifier corresponding to the target sub-file.

[0116] The central scheduler first determines the sub-file identifier corresponding to the target sub-file, and then schedules the segmented request to the target CDN node corresponding to the sub-file identifier of the target sub-file.

[0117] In some embodiments, scheduling segmented requests to the target CDN node corresponding to the target sub-file based on the sub-file identifier corresponding to the target sub-file further includes: scheduling segmented requests to the target CDN node corresponding to the target sub-file based on the sub-file identifier corresponding to the target sub-file using a round-robin scheduling method. Specifically, firstly, all sub-file identifiers of the target file are sorted, and then different segmented requests for different sub-files are sequentially allocated to different CDN nodes in a round-robin fashion according to the sorted order.

[0118] Then as Figure 7 As shown, when the central scheduler receives a segmentation request to obtain byte range 1 of file A, the central scheduler determines that the sub-file identifier corresponding to byte range 1 of file A is file_hash_1, and the CDN node corresponding to sub-file identifier file_hash_1 is node a. Then, the segmentation request is scheduled to node a. When the central scheduler receives a segmentation request to obtain byte range 2 of file A, the central scheduler determines that the sub-file identifier corresponding to byte range 2 of file A is file_hash_2, and the CDN node corresponding to sub-file identifier file_hash_2 is node b. Then, the segmentation request is scheduled to node b.

[0119] In this embodiment, the impact on existing sub-file mapping relationships is minimized when nodes are added or removed, ensuring system stability and balanced data distribution. For example, when a new CDN node is added, the consistent hashing algorithm only affects local sub-file mapping relationships on the hash ring, rather than all sub-files, avoiding large-scale data migration and redistribution.

[0120] In some embodiments, the request scheduling method may further include the following step 160:

[0121] Step 160: If the target CDN node does not cache the target sub-file, control the target CDN node to send a request to the origin server to obtain the target sub-file.

[0122] If the target CDN node has not cached the target sub-file, the central scheduler will control the target CDN node to send a request to the origin server to obtain the target sub-file. For example, in a scenario of a popular software update, a large number of clients simultaneously request different sub-files of the update package. Some CDN nodes may not have cached these sub-files yet, and the central scheduler will instruct these nodes to obtain the corresponding sub-files from the origin server.

[0123] In some embodiments, controlling the target CDN node to initiate a request to the source server to obtain the target sub-file includes: controlling the target CDN node to initiate a request to the source server to obtain the target sub-file based on a multi-threaded download method and / or a breakpoint resume method.

[0124] Specifically, to improve efficiency during the origin server pull process, optimization strategies such as multi-threaded downloading and breakpoint resumption can be employed to reduce pull time. Simultaneously, to avoid excessive pressure on the origin server from multiple CDN nodes simultaneously pulling origin servers, an origin server pull queue can be set up or the number of concurrent pulls can be limited.

[0125] Specifically, the multi-threaded download method controls the target CDN node to initiate requests to the origin server to obtain the target sub-file. This includes creating multiple threads (e.g., 4 threads) to simultaneously download different parts of the target sub-file when the target CDN node initiates a request to the origin server. The target sub-file is divided into multiple segments according to byte range, and each thread is responsible for downloading one segment. For example, a 10MB target sub-file can be divided into four 2.5MB segments, each downloaded by one of the four threads.

[0126] The breakpoint-based resume method controls the target CDN node to initiate requests to the origin server to retrieve the target sub-file. This includes: before starting to download the target sub-file, the target CDN node sends a request to the origin server with information about the data range of the target sub-file already downloaded (via the Range field in the HTTP request header). Based on this data range information, the origin server starts transmitting the remaining data of the target sub-file from the specified position. During the download process, if network interruptions or other abnormalities occur, the target CDN node records the number of bytes downloaded and their position. When the network recovers, when re-initiating the request, it again carries the downloaded range information and resumes downloading from the breakpoint until the entire target sub-file is retrieved.

[0127] In some embodiments, the request scheduling method may further include the following step 170:

[0128] Step 170: After the target CDN node successfully obtains the target sub-file from the source server, control the target CDN node to cache the target sub-file.

[0129] After the target CDN node successfully retrieves the target sub-file from the origin server, the central scheduler controls the target CDN node to cache the target sub-file. This way, when the same segment request for retrieving target data occurs again, the target CDN node can directly provide the target data from its local cache without having to retrieve it from the origin server again, greatly improving response speed and content distribution efficiency.

[0130] In some embodiments, controlling the target CDN node to cache the target sub-file includes: controlling the target CDN node to cache the target sub-file based on a Least Recently Used (LRU) policy or a Least Frequently Used (LFU) policy.

[0131] During the caching process, various caching strategies can be employed, such as LRU and LFU strategies. These strategies manage cache space rationally based on the access frequency and time of sub-files, ensuring that the most frequently used sub-files are always retained in the cache. For example, when using the LRU strategy, if the target CDN node's cache space is insufficient and sub-files need to be evicted, the least recently accessed sub-files will be evicted first, ensuring that the cache stores sub-files that have been used frequently recently.

[0132] In some embodiments, the request scheduling method may further include: if the target CDN node fails to obtain the target sub-file from the source server, the central scheduler may record the failure of the target CDN node to obtain the target sub-file, and re-control the target CDN node to send a request to the source server to obtain the target sub-file based on a preset number of retries (e.g., 3 times) and a preset retry interval (e.g., 5 seconds).

[0133] To better illustrate the request scheduling method provided in this application, a detailed explanation is given using a large file download application scenario as an example:

[0134] Taking a client downloading a large game installation package file A as an example, file A is 50MB in size. To speed up the download, the client sends multiple segmented requests concurrently, such as requesting data in the ranges of 0-10MB, 10-20MB, 20-30MB, 30-40MB, and 40-50MB respectively.

[0135] After receiving these segmentation requests, the central scheduler logically divides file A into subfiles 1 to 5. It determines that the target subfile for a segmentation request of 0-10MB is subfile 1, the target subfile for a segmentation request of 10-20MB is subfile 2, the target subfile for a segmentation request of 20-30MB is subfile 3, the target subfile for a segmentation request of 30-40MB is subfile 4, and the target subfile for a segmentation request of 40-50MB is subfile 5. Then, based on the subfile identifier and a preset consistent hashing algorithm, it schedules the segmentation requests of 0-10MB to node a, the segmentation requests of 10-20MB to node b, the segmentation requests of 20-30MB to node c, the segmentation requests of 30-40MB to node d, and the segmentation requests of 40-50MB to node e. The five nodes a, b, c, d, and e each respond to the corresponding sub-files with the client, completing the entire request response. This way, multiple concurrent requests are not concentrated on a single CDN node, fully utilizing the resources of multiple nodes in the CDN network and avoiding download speed bottlenecks. For CDN nodes that have not cached the target sub-file, the sub-file will be retrieved and cached according to the origin server access procedure. Subsequent identical requests can directly provide data from the local cache, improving download efficiency and reducing user waiting time.

[0136] like Figure 8 As shown, for example, after node a receives a segmented request to retrieve subfile 1, it does not have subfile 1 cached locally, so it requests a request from the origin server. Since subfile 1 is 10MB in size, the request back to the origin server takes 10MB. After the request is successful, subfile 1 is cached on node a. Similarly, the other four nodes also request their corresponding subfiles from the origin server, and after success, they cache the corresponding subfiles on their respective nodes. When a client requests file A, nodes a, b, c, d, and e each request 10MB from the origin server, for a total of 50MB. Subsequent requests for file A from other clients will directly hit the caches on nodes a, b, c, d, and e, without needing to request the origin server again. Compared to related technologies where each node needs to request the complete file A from the origin server, this significantly reduces the request back to the origin server rate.

[0137] like Figure 9 As shown, assuming the client's downlink bandwidth is large enough without bottlenecks, and the maximum uplink bandwidth of each node is 100Mbps, because the client downloads file A concurrently from 5 nodes, different sub-files, the client's download speed can reach 500Mbps. In contrast, related technologies download the entire file A from a single node, where the download speed is limited to 100Mbps due to the uplink bandwidth of a single node. The request scheduling method provided in this application truly leverages the advantages of concurrent downloading, significantly improving download speed.

[0138] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0139] This application embodiment receives a segmented request from a client to obtain target data, where the target data is a portion of data in a target file; logically divides the target file into multiple sub-files; maps the multiple sub-files to multiple Content Delivery Network (CDN) nodes based on a preset load balancing algorithm, ensuring that each sub-file has a corresponding CDN node, and at least two sub-files correspond to two different CDN nodes; determines the target sub-file corresponding to the target data; and schedules the segmented request to the target CDN node corresponding to the target sub-file, so that the client obtains the target data from the target CDN node. This scheme, upon receiving a segmented request to obtain partial data from a target file, logically divides the target file into multiple sub-files and assigns different sub-files to different CDN nodes, thereby evenly distributing the request across all nodes. This avoids multiple segmented requests concentrating on a single node, effectively solving the load balancing problem in large file segmented request scenarios and improving the overall performance and stability of the CDN network.

[0140] To facilitate better implementation of the request scheduling method of this application, this application also provides a request scheduling apparatus. Please refer to... Figure 10 , Figure 10 A schematic diagram of the structure of a request scheduling device provided in an embodiment of this application. The request scheduling device 200 may include:

[0141] The receiving unit 210 is used to receive a segmented request sent by the client for obtaining target data, wherein the target data is a portion of the data in the target file;

[0142] The partitioning unit 220 is used to logically divide the target file into multiple sub-files;

[0143] The mapping unit 230 is used to map multiple sub-files to multiple content delivery network (CDN) nodes based on a preset load balancing algorithm, so that each sub-file has a corresponding CDN node, and at least two sub-files have two different CDN nodes corresponding to them.

[0144] Determining unit 240 is used to determine the target sub-file corresponding to the target data;

[0145] The scheduling unit 250 is used to schedule segmented requests to the target CDN node corresponding to the target sub-file, so that the client can obtain the target data from the target CDN node.

[0146] In some embodiments, when mapping unit 230 maps multiple sub-files to multiple CDN nodes based on a preset load balancing algorithm, it is specifically used for:

[0147] For each subfile in a set of subfiles, determine a unique subfile identifier for each subfile.

[0148] Based on a preset load balancing algorithm, the sub-file identifiers corresponding to each sub-file are mapped to a CDN node, so that at least two sub-file identifiers correspond to two different CDN nodes.

[0149] In some embodiments, when scheduling a segmented request to a target CDN node corresponding to a target sub-file, the scheduling unit 250 is specifically used for:

[0150] Based on the subfile identifier corresponding to the target subfile, the segmented requests are scheduled to the target CDN node corresponding to the target subfile.

[0151] In some embodiments, when determining a unique subfile identifier for each subfile among multiple subfiles, the determining unit 240 is specifically used for:

[0152] For each subfile in a set of multiple subfiles, a unique subfile identifier is determined based on a hash algorithm.

[0153] In some embodiments, when determining the unique subfile identifier corresponding to each subfile based on a hash algorithm, the determining unit 240 is specifically used for:

[0154] For each subfile in the multiple subfiles, hash the filename of the target file and the byte range of each subfile in the target file to obtain a unique subfile identifier for each subfile.

[0155] In some embodiments, the preset load balancing algorithm is the consistent hashing algorithm.

[0156] In some embodiments, when the partitioning unit 220 is used to logically divide the target file into multiple sub-files, it is specifically used to: logically divide the target file into multiple sub-files based on a preset partitioning size.

[0157] In some embodiments, the preset partition size is determined based on the file type of the target file.

[0158] It should be noted that the functions of each module in the request scheduling device 200 in this application embodiment can be referred to the specific implementation of any embodiment in the above method embodiments, and will not be repeated here.

[0159] Each unit in the above-described device can be implemented entirely or partially through software, hardware, or a combination thereof. Each unit can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each unit.

[0160] For example, the request scheduling device 200 can be integrated into a terminal or server that has storage and a processor and thus computing power, or the request scheduling device 200 can be the terminal or server.

[0161] In some embodiments, this application also provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0162] Figure 9 A schematic structural diagram of the computer device provided in the embodiments of this application, such as Figure 9 As shown, the computer device 300 may include: a communication interface 301, a memory 302, a processor 303, and a communication bus 304. The communication interface 301, memory 302, and processor 303 communicate with each other via the communication bus 304. The communication interface 301 is used for data communication between the device 300 and external devices. The memory 302 can be used to store software programs and modules, and the processor 303 runs the software programs and modules stored in the memory 302, such as the software programs for the corresponding operations in the aforementioned method embodiments.

[0163] In some embodiments, the processor 303 may invoke software programs and modules stored in the memory 302 to perform the following operations: receiving a segmentation request sent by a client for obtaining target data, wherein the target data is a portion of data in a target file; logically dividing the target file into multiple sub-files; mapping the multiple sub-files to multiple Content Delivery Network (CDN) nodes based on a preset load balancing algorithm, so that each sub-file has a corresponding CDN node, and at least two sub-files correspond to two different CDN nodes; determining the target sub-file corresponding to the target data; and scheduling the segmentation request to the target CDN node corresponding to the target sub-file, so that the client obtains the target data from the target CDN node.

[0164] In some embodiments, the computer device 300 may be integrated into a terminal or server that has storage and a processor, thus possessing computing capabilities; or the computer device 300 may be the terminal or server. The terminal may be a smartphone, tablet, laptop, smart TV, smart speaker, wearable smart device, personal computer, or other similar device. The server may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0165] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding processes in the methods described above in the embodiments of this application; for brevity, further details are omitted here.

[0166] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding processes in the methods described above in the embodiments of this application. For brevity, these details will not be elaborated further here.

[0167] This application also provides a computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding processes in the methods described above in the embodiments of this application. For brevity, these details will not be elaborated further here.

[0168] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, 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, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0169] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0170] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0171] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0172] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0173] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

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

[0175] In addition, the functional units in the embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0176] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer or a server) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0177] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A request scheduling method, characterized in that, The method includes: Receive a segmented request sent by the client for obtaining target data, wherein the target data is a portion of data in the target file; The target file is logically divided into multiple sub-files; Based on a preset load balancing algorithm, the multiple sub-files are mapped to multiple content delivery network (CDN) nodes, so that each sub-file has a corresponding CDN node, and at least two sub-files have two different CDN nodes corresponding to them. Determine the target sub-file corresponding to the target data; The segmented request is scheduled to the target CDN node corresponding to the target sub-file, so that the client can obtain the target data from the target CDN node.

2. The request scheduling method as described in claim 1, characterized in that, The process of mapping the multiple sub-files to multiple CDN nodes based on a preset load balancing algorithm includes: For each subfile among the plurality of subfiles, determine a unique subfile identifier corresponding to each subfile; Based on a preset load balancing algorithm, the sub-file identifiers corresponding to each sub-file are mapped to CDN nodes respectively, so that at least two CDN nodes corresponding to two sub-file identifiers are two different CDN nodes; Scheduling the segmented request to the target CDN node corresponding to the target sub-file includes: Based on the sub-file identifier corresponding to the target sub-file, the segmented request is scheduled to the target CDN node corresponding to the target sub-file.

3. The request scheduling method as described in claim 2, characterized in that, For each subfile among the plurality of subfiles, determine a unique subfile identifier corresponding to each subfile, including: For each of the multiple subfiles, a unique subfile identifier is determined based on a hash algorithm.

4. The request scheduling method as described in claim 3, characterized in that, The step of determining a unique sub-file identifier for each sub-file among the plurality of sub-files based on a hash algorithm includes: For each of the multiple subfiles, the filename of the target file and the byte range of each subfile in the target file are hashed to obtain a unique subfile identifier corresponding to each subfile.

5. The request scheduling method as described in claim 1, characterized in that, The preset load balancing algorithm is a consistent hashing algorithm.

6. The request scheduling method as described in claim 1, characterized in that, The step of logically dividing the target file into multiple sub-files includes: The target file is logically divided into multiple sub-files based on a preset partition size.

7. The request scheduling method as described in claim 6, characterized in that, The preset partition size is determined based on the file type of the target file.

8. A request scheduling device, characterized in that, The device includes: The receiving unit is configured to receive a segmented request sent by the client for obtaining target data, wherein the target data is a portion of data in a target file; A partitioning unit is used to logically divide the target file into multiple sub-files; The mapping unit is used to map the multiple sub-files to multiple content delivery network (CDN) nodes based on a preset load balancing algorithm, so that each sub-file has a corresponding CDN node, and at least two sub-files have two different CDN nodes corresponding to two different CDN nodes. The determining unit is used to determine the target sub-file corresponding to the target data; The scheduling unit is used to schedule the segmented request to the target CDN node corresponding to the target sub-file, so that the client can obtain the target data from the target CDN node.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to execute the request scheduling method as described in any one of claims 1-7.

10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, and the processor executing the request scheduling method as described in any one of claims 1-7 by calling the computer program stored in the memory.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the request scheduling method according to any one of claims 1-7.

Images