A resource downloading method, related apparatuses, devices, and a storage medium

Abstract

This application discloses a resource download method for the cloud technology field. The method includes: dividing a target business resource package into multiple independent resource blocks according to preset rules, and storing these resource blocks completely across multiple widely distributed edge servers; when a terminal initiates a download request, the system dynamically selects the optimal edge servers based on the terminal's geographical location, network status, and real-time performance parameters of the edge servers, and assigns a corresponding resource block to each server for sending tasks. By distributing resources to nearby edge nodes, physical distances are shortened, reducing cross-border latency and backbone network congestion risks; low-performance nodes are dynamically eliminated, and tasks are distributed to high-quality nodes to avoid single-point overload; downloading blocks on demand instead of complete files reduces redundant data; and the multi-node redundant storage method ensures that single-point failures do not affect downloads, significantly improving system fault tolerance.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a resource download method, related apparatus, device, and storage medium. Background Technology

[0002] With the deepening integration of the global gaming market, cross-border gaming services have become a mainstream trend in the industry. However, existing update mechanisms still have significant limitations in addressing differences in network environments, user experience needs, and operational cost control. Traditional cross-border data transmission suffers from transmission efficiency issues due to geographical distance, resulting in long waiting times for players during version iterations. This technical predicament not only affects the user's immediate experience but also, to some extent, hinders the globalization of the gaming industry.

[0003] In existing technologies, the core drawback of direct connection solutions to a central server lies in its complete reliance on a single origin server for data distribution. When players are distributed across a wide geographical area, the complexity of data transmission paths leads to low network resource utilization efficiency and makes it difficult to effectively address backbone network congestion. Although CDN static distribution technology improves service coverage by deploying regional edge nodes, its operation mechanism based on full file caching is still insufficient when facing high-frequency, fragmented update demands. Especially in scenarios with frequent version iterations, users are often forced to download the entire update package, resulting in redundant consumption of bandwidth resources. Furthermore, the shortcomings of traditional solutions in load balancing are particularly prominent: popular nodes are prone to service quality fluctuations due to concurrent access pressure. Therefore, an effective method is urgently needed to solve these problems. Summary of the Invention

[0004] This application provides a resource download method, related apparatus, equipment, and storage medium, which solves the problems of low transmission efficiency, bandwidth redundancy, and uneven load caused by reliance on a single server in traditional cross-border data transmission.

[0005] This application provides a method for downloading resources, including:

[0006] In the case that each of the P edge servers stores M resource blocks corresponding to the target service, a resource package download request sent by the terminal is received; wherein, the M resource blocks are obtained by dividing the resource package of the target service into blocks, the resource package is a data file for running the target service, the M resource blocks correspond to M resource block identifiers, and the resource package download request carries the address information of the terminal, P≥1, M>1;

[0007] Based on the address information of the terminal and the P performance parameters corresponding to the P edge servers, Q target edge servers are determined from the P edge servers, and Q sending tasks corresponding to the Q target edge servers are determined. The Q sending tasks carry the M resource block identifiers, and each sending task carries at least one resource block identifier. The sending task is used to instruct the target edge server to send the corresponding resource block to the terminal according to the resource block identifier, where P≥Q≥1.

[0008] Based on the Q sending tasks, control the Q target edge servers to send the M resource blocks to the terminal.

[0009] This application also provides a resource downloading device, comprising:

[0010] The receiving module is configured to receive a resource package download request sent by a terminal when each of the P edge servers stores M resource blocks corresponding to the target service; wherein the M resource blocks are obtained by dividing the resource package of the target service into blocks, the resource package is a data file for running the target service, the M resource blocks correspond to M resource block identifiers, and the resource package download request carries the address information of the terminal, where P≥1 and M>1;

[0011] The determining module is configured to determine Q target edge servers from the P edge servers based on the address information of the terminal and the P performance parameters corresponding to the P edge servers, and to determine Q sending tasks corresponding to the Q target edge servers. The Q sending tasks carry the M resource block identifiers, and each sending task carries at least one resource block identifier. The sending task is used to instruct the target edge server to send the corresponding resource block to the terminal according to the resource block identifier, where P≥Q≥1.

[0012] The control module is used to control the Q target edge servers to send the M resource blocks to the terminal according to the Q sending tasks.

[0013] In another aspect, this application 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 methods described above.

[0014] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods described above.

[0015] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods described above.

[0016] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0017] This application provides a resource download method. A target service resource package is divided into multiple independent resource blocks according to preset rules, and these resource blocks are stored completely on P widely distributed edge servers. When a terminal initiates a download request, the system dynamically selects the optimal Q edge servers based on the terminal's geographical location, network status, and real-time performance parameters of the edge servers, and assigns a corresponding resource block sending task to each server. By distributing resource blocks from the nearest edge server, the physical distance between the terminal and the server is significantly shortened, reducing cross-border transmission latency and backbone network congestion risks. Simultaneously, dynamically selecting high-performance nodes (such as servers with low latency and sufficient bandwidth) ensures the stability of the download speed, avoiding lag or download failures caused by node performance bottlenecks. After the resource package is divided into blocks, the user only needs to download the necessary blocks instead of the complete file, significantly reducing redundant data transmission, especially in scenarios with frequent version iterations (such as game hot updates), saving considerable bandwidth consumption. By dynamically eliminating low-performance nodes and distributing download tasks to multiple high-quality nodes, the system avoids overloading popular nodes. In addition, each resource block is redundantly stored in multiple edge servers, so even if some nodes fail, the terminal can still complete the download through other nodes, significantly improving the system's fault tolerance. Attached Figure Description

[0018] Figure 1 This application provides an example of an interface diagram for downloading game update resource packages.

[0019] Figure 2 An architecture diagram of the method provided in the embodiments of this application in a cross-border game update scenario;

[0020] Figure 3 An architecture diagram of the method provided in the embodiments of this application in a cross-border education scenario;

[0021] Figure 4 An architecture diagram of the resource download method provided in this application embodiment applied to a cross-border game update scenario;

[0022] Figure 5 A flowchart of a resource download method provided in an embodiment of this application;

[0023] Figure 6 A timing diagram for resource downloading provided in the embodiments of this application;

[0024] Figure 7 A timing diagram of resource distribution provided for embodiments of this application;

[0025] Figure 8A schematic diagram of resource packet segmentation provided in an embodiment of this application;

[0026] Figure 9 Timing diagram of priority tag transmission provided for embodiments of this application;

[0027] Figure 10 A schematic diagram illustrating the target edge node filtering process provided in this application embodiment;

[0028] Figure 11 A timing diagram for verifying resource block hash values ​​provided in an embodiment of this application;

[0029] Figure 12 A timing diagram for sending terminal hash verification results provided in the embodiments of this application;

[0030] Figure 13 A timing diagram for sending another terminal hash verification result provided in an embodiment of this application;

[0031] Figure 14 Timing diagram for retransmission of resource blocks provided in embodiments of this application;

[0032] Figure 15 This is a schematic diagram of resource block exception handling provided in an embodiment of this application;

[0033] Figure 16 A schematic diagram illustrating resource block consistency verification provided in an embodiment of this application;

[0034] Figure 17 A timing diagram for resource block consistency verification provided in an embodiment of this application;

[0035] Figure 18 An architectural diagram of the method provided in the embodiments of this application;

[0036] Figure 19 This is a structural diagram of the resource download device provided in an embodiment of this application. Detailed Implementation

[0037] This application provides a resource download method that solves the problems of low transmission efficiency, bandwidth redundancy, and uneven load caused by relying on a single source station in traditional cross-border data transmission by storing the target service resource package in blocks on multiple edge servers and dynamically selecting the optimal node for parallel download task allocation based on the terminal network status.

[0038] 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 of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0039] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0040] 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.

[0041] Before introducing the specific methods of this application, we will first provide an illustrative example of the application scenarios for the resource download method in this application. It should be understood that the following application scenarios are merely examples and are not limited to these.

[0042] In one possible implementation, the method provided in this application embodiment is applied in a cross-border game update scenario. Please refer to... Figure 1 , Figure 1 This image shows the interface during a game update resource package download. In cross-border game update scenarios, the method described in this application significantly optimizes the game update experience for global players through distributed block storage and dynamic load balancing technology. Suppose a multinational game company needs to push new version content to millions of players distributed across the United States, Europe, Southeast Asia, and other regions. Traditional solutions, relying on a single origin server or static CDN nodes, require players in Europe and America to cross intercontinental backbones to download the complete update package, resulting in an average latency exceeding 2000 milliseconds, and frequent version iterations causing peak bandwidth consumption.

[0043] Please see Figure 2 , Figure 2 An architecture diagram of the method provided in this application in a cross-border game update scenario.

[0044] The method provided in this application first involves the central server 201 dividing the game resource package (including core code, art resources, sound effect files, etc.) into blocks according to functional modules and file types: code segments are split into logical modules to ensure that key functional blocks have the highest priority; media files are divided into independent resource blocks of fixed size, each marked with a unique identifier. All blocks are completely copied to P edge servers, and each node (edge ​​server) stores all M resource blocks, forming a redundant overlay network.

[0045] As in step S211, when a player in location A initiates an update request through terminal 200, the system collects the player's IP address location (location A) in real time, and obtains the local network latency, available bandwidth, and load status of edge server 202 in location A; simultaneously, it calculates the geographical matching degree between the player and P edge servers, including edge server 203 in location B, edge server 204 in location C, and edge server 205 in location D. Using a weighted scoring model (network latency weight 40%, bandwidth weight 30%, load weight 20%, geographical matching degree 10%), edge servers 202 in location A, 203 in location B, 204 in location C, and 205 in location D are selected as target edge servers (Q=4). In priority task allocation, the core code chunk is marked as the highest priority, as in step S212, and is transmitted in parallel by edge server 202 in location A and edge server 203 in location B, utilizing two independent paths to accelerate downloading; as in step S213, while the art resource chunk and sound effect file chunk are sent in batches by edge server 204 in location C and edge server 205 in location D, in descending order of priority. During the download process, the system continuously monitors the transmission quality of each node: if edge server 203 in location B experiences a sudden surge in traffic load to 90%, the system immediately removes it from the task queue and reassigns the remaining undownloaded chunks to edge server 202 in location A and edge server 204 in location C.

[0046] As in step S214, if after all chunks have been transmitted, the client compares the locally calculated MD5 hash value with the hash list sent by the server and finds that a certain texture resource chunk (number 17) has failed verification (this texture resource chunk was sent by edge server 204 in location C), the retransmission process is automatically triggered. At this time, the texture resource chunk in the neighboring edge server 205 in location D is sent to terminal 200. Ultimately, the player in location A completes the download of all M resource chunks in a short time, resulting in lower latency, reduced bandwidth consumption, and a lower update failure rate compared to the traditional solution.

[0047] Furthermore, since each resource block is redundantly stored on at least three edge nodes, even if one node goes offline for some reason, players can still successfully complete the download through other nodes.

[0048] The method provided in this application offers a highly reliable and low-cost real-time update solution for the multinational game industry through block-level scheduling, intelligent node selection, and global redundancy verification. It is particularly suitable for latency-sensitive game types such as massively multiplayer online role-playing games and competitive games.

[0049] In another possible implementation, the method provided in this application is applied to the scenario of global content distribution on an online education platform. In this application scenario, the method effectively solves the performance bottleneck and cost problems when cross-border users access large-capacity teaching resources. Please refer to... Figure 3 , Figure 3 An architecture diagram of the method provided in this application in a cross-border education scenario.

[0050] Suppose an international educational institution needs to simultaneously push high-definition course videos and accompanying teaching materials such as PPTs and exercise banks to millions of users in locations A, B, C, and D. Traditional solutions rely on direct connections to a central server, which causes users in location A to experience a relatively large average latency due to traversing the backbone network between locations B, C, and A, and frequent course updates cause bandwidth spikes.

[0051] This application first divides the teaching resource package into blocks according to content type through the central server 301: video files are divided into independent blocks of 100MB each by chapter (e.g., one block per chapter), and PPT and exercise documents are divided into fine-grained blocks of 50KB-2MB each by functional modules. All blocks are completely copied to P edge servers, and each node stores all M resource blocks.

[0052] As in step S311, when a user in location A initiates a course update request through terminal 300, the system locates the user's location (location A) through IP address resolution and collects local network conditions and edge server status in real time. Combining geographical location matching degree (90% matching degree of edge server 302 in location A), latency weight (40%), bandwidth weight (30%), load weight (20%), and historical access preferences (80% of the user's past requests were completed through edge server 303 in location B), the weighted scoring model ultimately selects edge server 303 in location B as the primary node and edge server 302 in location A as the backup node.

[0053] In priority task allocation, video chunks are marked as the highest priority, as in step S312, and are transmitted in parallel by edge server 303 in location B; as in step S313, while PPT and exercise chunks are transmitted through edge server 302 in location A. During the download process, the system monitors the quality of each link in real time: when the packet loss rate of edge server 303 in location B rises to 5% due to a regional network failure, it is automatically removed from the task queue, and the 10 unfinished video chunks are reassigned to edge server 302 in location A.

[0054] As in step S314, after all segments have been transmitted, the client performs segment-level MD5 verification: if the hash value of the 7th video segment does not match (the 7th video segment was transmitted by edge server 303 in location B), the 7th video segment is immediately transmitted from edge server 302 in location A to terminal 300.

[0055] Ultimately, the user completed the download of all M blocks in a short time, significantly reducing bandwidth consumption and improving update success rate. Furthermore, because each resource block is redundantly stored on at least three regional nodes, even if the edge server in location A goes offline for any reason, the user can still complete the download through the nearby edge server in location C.

[0056] Please see Figure 4 , Figure 4 This diagram illustrates the architecture of the resource download method provided in this application, applied to a cross-border game update scenario. The scenario includes user A's terminal 410, a network 420, and a server cluster 430.

[0057] Terminal 410 includes a human-computer interaction screen, a processor, and a memory. The human-computer interaction screen displays the game resource package download progress interface and provides a human-computer interaction interface to receive user-sent resource package download requests via the terminal. The processor generates interaction instructions in response to the aforementioned human-computer interaction operations and sends these instructions to the server cluster; the processor also restores the received M resource blocks into a resource package for game execution. The memory stores the received M resource blocks. The terminal 410 involved in this application includes, but is not limited to, mobile phones, tablets, laptops, desktop computers, intelligent voice interaction devices, virtual reality devices, smart home appliances, vehicle terminals, and aircraft.

[0058] Client 411 runs on terminal 410. Taking a game client as an example, client 411 is deployed on terminal 410. Client 411 can run on terminal 410 through a browser, or as a standalone application (APP) or mini-program, etc.

[0059] Network 420 uses standard communication technologies and / or protocols, typically the Internet, but can also be any network, including but not limited to Bluetooth, local area network (LAN), metropolitan area network (MAN), wide area network (WAN), mobile, private network, or any combination of virtual private network. In some embodiments, custom or dedicated data communication technologies may be used to replace or supplement the aforementioned data communication technologies.

[0060] Server cluster 430 can be a server cluster or distributed system consisting of at least one physical server, or it can be 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 networks (CDNs), and big data and artificial intelligence (AI) platforms. Server cluster 430 includes a central server 431 and P edge servers 432.

[0061] The central server 431 retrieves the game's resource package, determines the chunking rules based on the file types within the resource package, and then chunks the resource package into M resource blocks. These M resource blocks are then sent to P edge servers 432 via network 420.

[0062] Each of the P edge servers 432 stores M resource blocks corresponding to the target service.

[0063] Players update the game via terminal 410. As in step S401, terminal 410 sends a resource package download request, which carries the terminal's address information. The edge server closest to terminal 410 responds to this request. As in step S402, the scheduling center of server cluster 430, based on the terminal's address information and the P performance parameters corresponding to the P edge servers, determines Q target edge servers from the P edge servers and Q sending tasks corresponding to the Q target edge servers. Each of the Q sending tasks carries M resource block identifiers, and each sending task carries at least one resource block identifier. The sending tasks instruct the target edge servers to send the corresponding resource blocks to terminal 410 according to the resource block identifiers. As in step S403, the scheduling center of server cluster 430, based on the Q sending tasks, controls the Q target edge servers to send the M resource blocks to terminal 410.

[0064] The method provided in this application significantly shortens the physical distance between the terminal and the server by distributing resource blocks to edge servers, reducing cross-border transmission latency and backbone network congestion risks. Simultaneously, dynamically selecting high-performance nodes (such as servers with low latency and sufficient bandwidth) ensures download speed stability, avoiding stuttering or download failures caused by node performance bottlenecks. After resource packets are segmented, users only need to download necessary segments instead of the complete file, significantly reducing redundant data transmission, especially in scenarios with frequent version iterations (such as hot game updates), saving considerable bandwidth consumption. By dynamically eliminating low-performance nodes and distributing download tasks to multiple high-quality nodes, overload of popular nodes is avoided. Furthermore, each resource block is redundantly stored across multiple edge servers, so even if some nodes fail, the terminal can still complete the download through other nodes, significantly improving system fault tolerance.

[0065] Please see Figure 5 , Figure 5 A flowchart of a resource download method is shown. It should be noted that the interactive programming data generation method provided in this application embodiment can be applied to a server, and this application embodiment does not impose any limitations. The method includes:

[0066] S510. In the case that each of the P edge servers stores the corresponding M resource blocks of the target service, receive the resource package download request sent by the terminal.

[0067] Among them, M resource blocks are obtained by dividing the resource package of the target service into blocks. The resource package is the data file for running the target service. M resource blocks correspond to M resource block identifiers. The resource package download request carries the terminal's address information, P≥1, M>1.

[0068] As can be understood, an edge server refers to a distributed node deployed at the edge of the user network, such as a city-level data center or a carrier base station. Its role is to shorten data transmission distance through localized storage. A resource block is an independent data unit (e.g., a 1MB block) that divides a target business resource package (such as a game client or video file) according to functional modules, file types, or a fixed size. Each block corresponds to a unique identifier (such as a hash value or sequence number). A resource package download request contains information such as the terminal IP address, device type, and network protocol preferences, used to trigger subsequent dynamic scheduling logic.

[0069] By leveraging the wide-area coverage of edge nodes, localized services are achieved, avoiding the long-distance transmission bottlenecks inherent in traditional direct-connection central server models. For example, when a user in a certain region downloads resources, they can directly obtain data from the local edge node, rather than traversing backbone network links across multiple regions, significantly reducing latency and packet loss rates. Simultaneously, the resource block identification system enables fine-grained management of data fragmentation, laying the foundation for subsequent parallel transmission and verification mechanisms.

[0070] S520: Based on the terminal's address information and the P performance parameters corresponding to the P edge servers, determine Q target edge servers from the P edge servers, and determine Q sending tasks corresponding to the Q target edge servers.

[0071] Among them, Q sending tasks carry M resource block identifiers, and each sending task carries at least one resource block identifier. The sending task is used to instruct the target edge server to send the corresponding resource block to the terminal according to the resource block identifier, and P≥Q≥1.

[0072] It is understandable that the terminal address information is used to locate the user's geographical location. Combined with the performance parameters of the edge server (including network latency, available bandwidth, operating load, geographical location matching degree, etc.), a weighted scoring model (such as Score = α × 1 / RTT + β × (Bandwidth / MaxBandwidth) + γ × (1-Load) + δ × GeoScore, where Score represents the score, α, β, γ and δ are the weights, RTT represents network latency in ms, Bandwidth represents bandwidth, Load represents operating load rate, and GeoScore represents geographical location matching degree) is used to select Q optimal edge servers.

[0073] For example, when a user is located in country A, the system will prioritize nodes with latency below 100ms, bandwidth utilization below 60%, and geographical distance less than 500 kilometers (such as nodes in major local cities), rather than relying solely on static CDN nodes. Furthermore, the design of sending tasks carrying resource block identifiers enables fine-grained task allocation. For instance, frequently accessed core code blocks are preferentially allocated to the highest-performing nodes, while low-frequency texture resource blocks are distributed to other nodes. This differentiated strategy balances the transmission efficiency of critical data with overall bandwidth utilization.

[0074] By using real-time parameter sensing and dynamic weight adjustment, the limitations of traditional solutions, such as node selection relying on manual configuration and inability to adapt to network fluctuations, are solved. For example, when the network is congested during the rainy season in a tropical region, the system can automatically switch to redundant nodes to avoid download interruptions.

[0075] S530: Based on Q sending tasks, control Q target edge servers to send M resource blocks to the terminal.

[0076] Understandably, controlling Q target edge servers to send M resource blocks to the terminal is not a simple data distribution, but rather a combination of priority marking and multi-link aggregation technology to achieve efficient transmission. For example, the system might push 30 critical blocks out of a total of 100 resource blocks in parallel across nodes in a Gulf region via the QUIC protocol, while the remaining 70 blocks are multiplexed and transmitted across nodes in Southeast Asia via the HTTP / 3 protocol. Simultaneously, a copy of each block is stored on at least three edge nodes to ensure reliability. When a node experiences a partial failure (such as hard drive damage) causing block verification to fail, the client automatically triggers a retransmission request from other nodes without interrupting the entire download process. This design not only improves transmission speed (e.g., reducing the download time for a 2GB course package from 4200ms to 1200ms for a user in a South Asian country), but also reduces the risk of single-point failures through block-level redundancy. For example, if a node in an archipelago region is offline, the user can still complete the download through nearby island nodes.

[0077] For easier understanding, please refer to Figure 6 , Figure 6 This is a timing diagram of resource download provided in an embodiment of this application. For example, in step S601, when a player in location A updates the game, they initiate a resource package download request through terminal 610. This request is received by the edge server A620, which is closest to the terminal's current location. The system collects the player's IP address location (location A) in real time, and obtains the local network latency, available bandwidth, and load status of edge server 621 in location A. Simultaneously, it calculates the geographical matching degree between the player and P edge servers, including edge server 622 in location B, edge server 623 in location C, and edge server 624 in location D. Using a weighted scoring model (network latency weight 40%, bandwidth weight 30%, load weight 20%, geographical matching degree 10%), edge servers 621 in location A, 622 in location B, 623 in location C, and 624 in location D are selected as target edge servers (Q=4). Then, the sending task for each edge server is determined. In priority task allocation, the core code block is marked as the highest priority, as in step S602, and is transmitted in parallel by edge server 621 in location A and edge server 622 in location B, utilizing two independent paths to accelerate downloading. As in step S603, art resource blocks and sound effect file blocks are sent in batches by edge server 623 in location C and edge server 624 in location D, in descending order of priority. During the download process, the system continuously monitors the transmission quality of each node: if edge server 622 in location B experiences a sudden surge in traffic load to 90%, the system immediately removes it from the task queue and reassigns the remaining undownloaded blocks to edge server 621 in location A and edge server 623 in location C. As in step S604, after the terminal receives M resource blocks, it reassembles the M resource blocks through a memory buffer.

[0078] The method provided in this application constructs a highly efficient "storage-scheduling-transmission" integrated architecture. Distributed storage breaks the traditional single-source limitation, enabling redundant distribution of resource blocks among edge nodes and ensuring the geographical availability of services. Dynamic load balancing, through real-time parameter awareness and intelligent decision-making, dynamically allocates download tasks to the optimal nodes, avoiding overload on popular nodes. Parallel transmission and fault tolerance mechanisms, through multi-link aggregation and block-level verification, significantly improve transmission efficiency and reliability. This architecture is particularly suitable for scenarios with high real-time requirements and wide user distribution (such as online education and live stream distribution). Its core advantage lies in achieving synergistic optimization of network efficiency, user experience, and system scalability through the integration of edge computing and dynamic scheduling technologies.

[0079] In an optional embodiment of the resource download method provided in the above embodiments of this application, the method further includes:

[0080] Obtain the resource package for the target business;

[0081] Determine the chunking rules based on the file types in the resource package;

[0082] According to the segmentation rules, the resource package is segmented into M resource blocks;

[0083] M resource blocks are stored on P edge servers, so that each edge server stores M resource blocks.

[0084] Understandably, a target business resource package refers to the collection of all data files required to run a specific business (such as an online game or a high-definition video platform). This package may contain various data units, including executable code, media resources, and configuration files. Segmentation rules are differentiated partitioning logic based on the characteristics of different file types within the resource package. For example, program code files might be divided by functional modules (e.g., separating the graphics rendering module from the physics engine code), video files might be divided into independent segments based on the timeline, and document resources might be split by chapters or pages.

[0085] The central server stores the resource packages for the target business and divides these packages into chunks. By automatically matching file types to chunking rules (such as code modularization and media stream fragmentation), the independence and manageability of each resource chunk are ensured. For example, in a game update scenario, core code chunks are prioritized, while art resource chunks are divided into fixed-size chunks. This differentiated strategy reduces redundant transmission and avoids uneven multi-threaded downloads caused by excessively large chunks.

[0086] The design of replicating M resource blocks completely across P edge servers (P≥1) breaks the limitation of traditional CDNs that only cache static resources, enabling global distribution of dynamic content. The advantage of each node storing all blocks is that when a node in a certain region goes offline due to natural disasters or network failures, users can still obtain the complete resource through other nodes without having to download it again from the central server. This is especially important in cross-border businesses.

[0087] The M resource block identifiers (such as hash values ​​or unique sequence numbers) generated after the resource package is segmented become the basis for subsequent dynamic scheduling. During download, the terminal can quickly locate the required block based on the identifiers, avoiding the additional delays caused by full file verification in traditional solutions. For example, in a video platform update scenario, users only need to download the modified blocks instead of the entire video file, reducing bandwidth consumption.

[0088] For easier understanding, please refer to Figure 7 , Figure 7 This is a timing diagram of resource distribution provided in an embodiment of this application. Whenever the game is updated, a complete resource package for the update is stored in the central server 720. As in step S701, the central server 720 determines the segmentation rules based on the file types in the resource package to segment the resource package into M resource blocks. As in step S702, the central server 720 sends the M resource blocks to P edge servers (including edge server A721, edge server B722, edge server C723, and edge server D724). As in step S703, each of the P edge servers stores the M resource blocks. Preferably, to ensure single point of failure, each resource block is stored on at least 3 edge servers.

[0089] The method provided in this application constructs an underlying support system for resource distribution. It maximizes resource utilization through intelligent block partitioning rules, while global redundant storage distributes the risk of single-point failures across multiple nodes. This design is particularly suitable for scenarios with frequent version iterations and widespread user distribution, effectively reducing loan costs and peak server load.

[0090] In an optional embodiment of the resource download method provided in the above embodiments of this application, the resource package includes R first-type files and T second-type files, where R≥1 and T≥1;

[0091] Based on the file types in the resource package, determine the chunking rules, including:

[0092] Based on the file types of R first-type files, a first block rule is determined, wherein the first block rule is used to indicate that the data in the first-type files is divided into blocks according to function;

[0093] Based on the file types of T second-type files, a second block rule is determined, wherein the second block rule is used to instruct the data in the second-type files to be divided into blocks according to a preset data size;

[0094] According to the partitioning rules, the resource package is partitioned into M resource blocks, including:

[0095] According to the first partitioning rule, the data in the R first-type files are partitioned into W resource blocks, where W > R.

[0096] According to the second partitioning rule, the data in the T second-type files are partitioned into U resource blocks, where U > T and U + W = M.

[0097] As can be understood, a resource package refers to the complete set of data required to run a target service (such as cloud gaming or a streaming media platform), containing R primary type files (such as executable code and configuration files) and T secondary type files (such as high-definition video and audio materials). The first partitioning rule divides the code file into independent resource blocks according to functional modules (such as a physics engine and rendering pipeline) based on the program's logical structure, with each module corresponding to a unique identifier. The second partitioning rule divides the media file into contiguous data blocks of a fixed size (such as 512KB), with each block retaining its original file structure.

[0098] This application considers both business characteristic adaptability and transmission efficiency optimization. For the first type of file, function-oriented chunking is adopted, allowing the terminal to dynamically load specific modules as needed during download (e.g., if a user only updates a new character's skill in a game, only the corresponding code function block needs to be downloaded), avoiding the bandwidth waste caused by traditional full-download downloads. For example, in a game update scenario, a 1.2GB update package code is broken down into 200 independent resource blocks (W=200) after function chunking. Users only need to obtain 20 blocks (15% of the total) to download the core combat module, shortening download time. For the second type of file, fixed-size chunking is implemented, allowing parallel transmission through multi-link aggregation technology (e.g., dividing a 1080P video into 512KB blocks and pushing it simultaneously on three independent paths using the QUIC protocol), effectively avoiding network congestion risks. In a live streaming scenario on a video platform, this method significantly reduces the buffering latency of 4K video, thus reducing stuttering.

[0099] Functional chunking avoids redundant data transmission. For example, an educational software program splits a 50MB courseware PPT into 10 functional chunks by chapter. Users only need to download 3 chapter chunks to preview the course, saving significant bandwidth. Fixed chunk sizes for media files adapt to different network environments. In low-bandwidth mountainous areas, the system can automatically switch to a 32KB chunk mode to maintain smooth playback. The independence of each resource chunk simplifies version management. When a functional module has a vulnerability, only the corresponding chunk (rather than the entire codebase) needs to be redistributed, improving repair efficiency. For example, in a security patch update for an app, functional chunking reduced the original 200MB update package to 2MB, decreasing download time.

[0100] For example, please refer to Figure 8 , Figure 8 The diagram illustrates the resource package segmentation. First, the acquired complete resource package undergoes file type analysis. Executable files (e.g., .exe files) are segmented by functional modules (e.g., account login module, combat module) to ensure key functions are downloaded first. Resource files (e.g., images, videos, audio, etc.) are evenly segmented at a fixed size (e.g., 1MB) to facilitate parallel transmission. Based on the segmentation results, a segmentation index file is generated so that the terminal can reassemble the segments.

[0101] The method provided in this application constructs a flexible and scalable resource processing framework through a hybrid chunking model. It not only supports collaborative optimization of code and media but also reserves rule extension interfaces for future additions of file types. By combining the logical atomicity of functional chunking with the physical continuity of media chunking, it achieves deep adaptation between business requirements and network characteristics. This architectural design significantly reduces the operating costs of content delivery networks (CDNs) while providing users with an access experience close to that of a local server, making it particularly suitable for globalized distributed business scenarios.

[0102] In an optional embodiment of the resource download method provided in the above embodiments of this application, the method further includes:

[0103] Based on the N running functions corresponding to the M resource blocks, the M resource blocks are prioritized to obtain the N download priority orders corresponding to the M resource blocks, where M≥N≥1;

[0104] Based on Q sending tasks, control Q target edge servers to send M resource blocks to the terminal, including:

[0105] Based on Q sending tasks and N download priority orders, control Q target edge servers to send M resource blocks to the terminal in sequence, where resource blocks with the same priority order are sent in parallel.

[0106] Understandably, "functionality" refers to the specific role of each resource block in the target business (e.g., core code blocks are responsible for the game's physics engine, texture resource blocks are used for character rendering). Its allocation is based on business logic rather than simply file type. For example, among 100 resource blocks in a game, the functional block identified as "combat skills" is assigned the highest priority. The priority marking process automatically assigns a priority level (e.g., P0-P3) to each resource block through static analysis or runtime monitoring. For instance, in a game update scenario, player character skill data (P0) has a higher download priority than background music resources (P2). The download priority order establishes an execution sequence based on the priority level. Higher priority blocks are started for transmission first, while blocks of the same level can be pushed in parallel. For example, 30 P0-level code blocks can be transmitted simultaneously across 5 edge nodes via the QUIC protocol to ensure rapid loading of core functional modules.

[0107] By prioritizing data, the system can dynamically identify resource blocks that have the greatest impact on user experience (such as audio and video encoding modules in live streaming) and allocate them preferentially in network resource allocation. For example, in a multinational live streaming platform, the real-time audio and video stream blocks of the streamer are marked as P0 level. The system will prioritize allocating these blocks to edge nodes with sufficient bandwidth and ensure their priority transmission through TCP acceleration protocols, thereby reducing the stuttering rate. The parallel sending strategy further utilizes multi-link aggregation technology. When multiple blocks with the same priority exist, the system will distribute these blocks to servers on different physical paths, avoiding the overall latency increase caused by single-link congestion. Preferably, in game update scenarios, files necessary for game startup (such as .exe files, .dll files, etc.) are marked as high priority, downloaded and verified first. Once the critical blocks (such as the first 10% of the packet) are downloaded, players are allowed to enter the game. During the download process, the unique identifier (such as hash value or sequence number) corresponding to the downloaded resource blocks is recorded. If a network interruption occurs, the download will automatically resume from the edge server closest to the terminal based on the resource block identifier.

[0108] In financial transaction scenarios, encrypted resource blocks involved in user authentication are marked with a P0 priority level to ensure priority download even during network congestion, thereby improving authentication success rates. In game update scenarios, non-core art resources (such as environment textures) are marked with a lower priority, and downloads only begin after the main task is completed, reducing bandwidth consumption per user.

[0109] When a change in the terminal's network status is detected (such as switching from 4G to WiFi), the system can adjust priority weights in real time (e.g., temporarily increasing the priority of video buffer blocks) to ensure a continuous user experience. For example, in a mobile video platform, this mechanism reduces the average buffering time for users experiencing network fluctuations in subway tunnels.

[0110] For easier understanding, please refer to Figure 9 , Figure 9 This is a timing diagram of priority marker transmission provided in an embodiment of this application. During the resource block distribution stage, as in step S901, the central server 920 divides the resource packets according to different file types using different segmentation modes: The data in the R first-type files (core code files) is divided into blocks according to functional modules, resulting in W resource blocks. Based on the operating function corresponding to each block, the W resource blocks are marked with priority order p1, p2, and p3. The data in the T second-type files (art resource files, sound effect files) is divided into blocks of fixed size, resulting in U resource blocks. The U resource blocks are marked with priority order p4. As in step S902, the central server 920 sends the M resource blocks carrying priority markers to edge servers A921, B922, C923, and D924 in parallel. As in step 903, edge servers A921, B922, C923, and D924 respectively store the M resource blocks carrying priority tags.

[0111] During the resource package download phase, terminal 910 sends a resource package download request to the nearest edge server A 921. As in step S911, edge server A 921 sends the resource block with priority p1 to terminal 910. As in step S912, edge server B 922 sends the resource block with priority p2 to terminal 910. Steps S912 and S913 are parallel processing steps. As in step S914, edge server C 923 sends the resource block with priority p3 to terminal 910. As in step S915, edge server D 923 sends the resource block with priority p4 to terminal 910. As in step S916, after receiving M resource blocks, terminal 910 reassembles the M resource blocks using a memory buffer.

[0112] The method provided in this application forms a closed-loop optimization system with priority marking and task scheduling mechanisms. Functional hierarchies at the service level and intelligent transmission control at the network level mutually reinforce each other: priority marking provides a quantitative basis for service value, while dynamic task scheduling translates this value into actual network resource allocation. This design not only improves resource download efficiency but, more importantly, establishes an intelligent matching mechanism between service requirements and network resources. Its value is particularly significant in globally distributed services—through priority-driven intelligent scheduling, enterprises can maximize the delivery quality of critical services within a limited bandwidth budget.

[0113] In an optional embodiment of the resource download method provided in the above embodiments of this application, the performance parameters include network latency parameters, available bandwidth parameters, and operating load parameters;

[0114] Based on the terminal's address information and the P performance parameters corresponding to the P edge servers, determine Q target edge servers from the P edge servers, including:

[0115] Obtain P network latency parameters, P available bandwidth parameters, P operating load parameters, and P address information for each edge server;

[0116] Based on the terminal's address information and the address information of P edge servers, P geographic location matching scores are calculated, where the geographic location matching score is used to characterize the distance between the terminal and the edge servers.

[0117] We calculate the P scores corresponding to the P edge servers by weighting the P network latency parameters, P available bandwidth parameters, P operating load parameters, and P geographical location matching degrees.

[0118] Based on P scores, determine Q target edge servers from the P edge servers, where the score of the target edge server is greater than the score threshold, or the Q target edge servers are the Q edge servers with higher scores among the P edge servers.

[0119] Understandably, the system first needs to obtain real-time operational status data from P edge servers, including network latency (round-trip time of data packets from the terminal to the server), available bandwidth (the maximum transmission rate that the server can currently allocate), operational load (server CPU / memory utilization percentage), and geographical location information (such as latitude and longitude coordinates or network topology identifiers).

[0120] Taking a cross-border game update scenario as an example, when a player is located in a city in Southeast Asia, the system collects the latency (e.g., 120ms / 180ms / 200ms), bandwidth (80Mbps / 60Mbps / 40Mbps), load (45% / 70% / 85%), and geographical coordinates (longitude 103°E / 105°E / 106°E) of nodes in regions A, B, C, and D. Based on the geographical location resolved from the terminal's IP address (e.g., 104°E East longitude), the system calculates the geographical matching degree between each server and the terminal (e.g., 92% matching degree for region A, 85% for region B, and 78% for region C). This value reflects the proximity of the server to the user's physical location and directly affects the routing efficiency of data transmission.

[0121] Based on the above data, the system constructed a multi-objective optimization model. As shown in Table 1, the score of each edge server is obtained by weighted summation of four parameters according to preset weights.

[0122] Table 1

[0123] index Weight Data collection method Network latency (RTT) 40％ ICMP Ping + TCP Handshake Measurement Available bandwidth 30％ Download speed test in chunks Server CPU / Memory Load 20％ Edge nodes actively report Geographic location matching 10％ IP address resolution

[0124] The edge server's score is calculated using a formula:

[0125]

[0126] Where α, β, γ, and δ are empirical coefficients (e.g., α = 0.4, β = 0.3, γ = 0.2, δ = 0.1). RTT is network latency, Bandwidth is measured bandwidth, and Load is server load rate.

[0127] Taking node A as an example, its score might be: 0.4×(1 / 120)+0.3×(80 / 100)+0.2×(1-45%)+0.1×92≈0.033+0.24+0.11+0.092=0.475. By comparing the scores of P nodes, the system selects Q optimal servers (e.g., Q=3), whose scores must exceed a threshold (e.g., 0.4) or rank among the top Q. In the above case, nodes A (0.475), B (0.422), and C (0.391) might be selected, while other nodes with excessive load (e.g., node D with 90% load) are eliminated.

[0128] By prioritizing nearby nodes based on geographical location matching, the physical distance of cross-border transmission is reduced. For example, routing downloads for Southeast Asian users to a node in location A instead of a central European node can reduce latency. High-load nodes (e.g., servers with a load rate >80%) are dynamically excluded to prevent them from becoming bottlenecks, while nodes with sufficient bandwidth are utilized to increase throughput, improving download speeds for individual users, especially in game update scenarios. Through real-time parameter awareness, the system can dynamically adapt to network fluctuations (e.g., bandwidth drops in Southeast Asia during the rainy season). In one case, when the bandwidth of a node in location B suddenly dropped to 30Mbps, the system automatically removed it from the candidate list and reassigned the task, ensuring that download tasks were migrated quickly without the user's awareness.

[0129] The method provided in this application constructs an adaptive, distributed resource scheduling network through a dynamic selection mechanism. It not only overcomes the limitations of traditional static CDN node selection but also achieves synergistic optimization of network efficiency, cost control, and service reliability through real-time parameter-driven decision-making. More importantly, through dynamic elimination and load balancing of edge nodes, enterprises can significantly reduce their reliance on expensive core nodes, saving infrastructure costs while maintaining the same service level. This design is particularly suitable for scenarios such as 5G edge computing and large-scale IoT connections, providing a cost-effective distributed solution for real-time sensitive services.

[0130] In an optional embodiment of the resource download method provided in the above embodiments of the present application, determining Q target edge servers from the P edge servers according to the address information of the terminal and P performance parameters corresponding to the P edge servers comprises:

[0131] According to P network delay parameters of the P edge servers, determining X edge servers with network delay parameters smaller than a network delay threshold from the P edge servers, where P>X≥1;

[0132] According to X available bandwidth parameters of the X edge servers, determining Y edge servers with available bandwidth parameters greater than a bandwidth threshold from the X edge servers, where P>X>Y≥1;

[0133] According to Y operating load parameters of the Y edge servers, determining Z edge servers with operating load parameters smaller than a load threshold from the Y edge servers, where P>X>Y>Z≥1;

[0134] Calculating Z distance values according to the Z address information of the Z edge servers and the address information of the terminal;

[0135] Determining Q target edge servers from the Z edge servers according to the Z distances, where the distance value between the target edge server and the terminal is smaller than a distance threshold, and P>X>Y>Z>Q≥1.

[0136] It can be understood that the method of the present application provides a target edge server screening method of network delay threshold filtering, bandwidth threshold filtering, load threshold filtering and geographic location distance screening.

[0137] Network delay threshold filtering: The network delay parameter refers to the round-trip time of data packets between the terminal and the edge server (e.g., 120ms), and the network delay threshold is the maximum allowable delay set according to service requirements (e.g., 200ms). First, nodes with delay exceeding the threshold are eliminated from the P edge servers (e.g., European nodes are excluded when a user in Africa accesses), leaving X servers (X<P). For example, in a cross-border game update scenario, if the threshold is set to 200ms, only local nodes such as Location A and Location B pass the screening, while the node at Location E is eliminated due to a delay of 280ms. By directly eliminating high-delay nodes, the delay perceived by the user is reduced, and stuttering caused by transoceanic transmission is avoided.

[0138] Bandwidth threshold filtering: The available bandwidth parameter refers to the current remaining available bandwidth of the server (e.g., 80Mbps), and the bandwidth threshold is the minimum bandwidth requirement for ensuring quality of service (e.g., 50Mbps). Y servers with sufficient bandwidth are further screened out from X low-latency nodes (Y<X). For example, when the bandwidth of an edge node drops sharply from 100Mbps to 30Mbps during peak hours, it will be automatically excluded. This ensures that the target server has sufficient bandwidth capacity and avoids download rate fluctuations caused by insufficient bandwidth.

[0139] Load threshold filtering: The running load parameter refers to the CPU / memory usage of the server (e.g., 70%), and the load threshold is the safety threshold for preventing overload (e.g., 85%). Z servers with excessively high load are eliminated from Y nodes that meet the bandwidth requirement (Z<Y). For example, if the load of a node rises to 92% due to processing a large number of concurrent requests, it will be removed from the candidate list. This prevents the degradation of service quality caused by server overload and extends the service life of hardware.

[0140] Geographic location distance screening: The distance value is used to calculate the physical distance between the terminal and the server through a geocoding algorithm (e.g., the Haversine formula) (e.g., 300 kilometers). The Z low-load nodes are sorted by distance, and Q optimal servers with a distance less than the threshold (e.g., 500 kilometers) are selected. For example, when a user is located in Kuala Lumpur, the node in Singapore (200 kilometers) is preferred over the node in Jakarta (1000 kilometers). This further optimizes the physical transmission path and reduces the number of packet hops in the backbone network.

[0141] For example, please refer to Figure 10 , Figure 10 which is a schematic diagram of the screening process of target edge nodes. First, according to the network delay parameter, edge servers with network delay greater than or equal to the network delay parameter (100ms) are marked as unavailable edge servers. Next, available bandwidth judgment is performed on edge servers with network delay less than the network delay parameter, and edge servers with available bandwidth less than or equal to the available bandwidth parameter (20Mbps) are marked as downgrade candidates. Then, running load judgment is performed on edge servers with available bandwidth greater than the available bandwidth parameter, edge servers with running load parameter greater than or equal to the load threshold (60%) are marked as standby nodes, and edge servers with running load parameter less than the load threshold are marked as preferred nodes. Finally, the target edge server is selected according to the physical distance between the edge server marked as the preferred node and the terminal.

[0142] The method provided in this application embodiment forms an optimization system of "latency-bandwidth-load-distance" through a four-level filtering mechanism. By imposing hard threshold constraints, it ensures that the Q servers selected in the end all meet the minimum performance requirements. The layered filtering avoids global traversal calculations, and each level of filtering provides quality assurance for subsequent steps. For example, even if all servers in a certain region have insufficient bandwidth, the system can still automatically fall back to a higher latency but stable node through load filtering without interrupting the entire download process.

[0143] In an optional embodiment of the resource download method provided in the above embodiments of this application, determining Q sending tasks corresponding to Q target edge servers includes:

[0144] Based on the Q network latencies, Q available bandwidths, and Q operating loads of the Q target edge servers, determine the Q sending tasks corresponding to the Q target edge servers.

[0145] Understandably, the system first collects real-time performance parameters (e.g., once per second) from Q servers to construct a multi-dimensional feature vector (latency, bandwidth, load). Then, it dynamically calculates a "task capacity index" for each server using a machine learning model (e.g., reinforcement learning) or a rule engine (e.g., a PID-based control algorithm). Based on this index, the system allocates M resource blocks to the Q servers, ensuring that high-capacity nodes receive more tasks, while inefficient nodes are limited to a safe threshold.

[0146] In game update scenarios, if a server has a bandwidth of 100Mbps and a load of only 30%, the system will allocate 80% of the tasks (e.g., 40 chunks) to it, while a server with the same bandwidth of 100Mbps but a load of 70% will only be allocated 20% of the tasks, avoiding resource waste. By monitoring the load in real time, the system can dynamically avoid overloaded nodes (e.g., automatically reducing task allocation to a server when its load exceeds 85%). Combined with latency parameters, the system prioritizes allocating frequently accessed chunks to nodes with latency below 100ms. For example, when a user in Southeast Asia downloads a game update, the core code chunks are transmitted through local nodes (80ms latency) instead of European nodes (220ms latency), increasing the download speed of critical chunks and shortening download time.

[0147] In a 5G edge computing scenario, when a user downloads a 1GB game update package via a mobile hotspot (bandwidth 50Mbps), the system first selects three local nodes with latency <50ms and load <50%. Then, it dynamically allocates the task volume (e.g., 35% / 30% / 35%) based on the real-time bandwidth of each node (e.g., 30Mbps / 40Mbps / 45Mbps), and finally completes the download within 90 seconds, which is 40% faster than the traditional polling scheduling mechanism.

[0148] The method provided in this application uses threshold filtering to select candidate nodes, while the task allocation stage optimizes resource scheduling through performance indicators, thereby improving network resource utilization, enhancing server stability, and increasing transmission efficiency.

[0149] In an optional embodiment of the resource download method provided in the above embodiments of this application, the method further includes:

[0150] Based on the hash algorithm, calculate the M hash values ​​corresponding to the M resource blocks to obtain the M first hash values;

[0151] M first hash values ​​are sent to the terminal. After receiving M resource blocks, the terminal calculates the M hash values ​​corresponding to the M resource blocks according to the hash algorithm to obtain M second hash values. The terminal performs consistency determination based on the M first hash values ​​and the M second hash values.

[0152] As can be understood, a hash algorithm refers to using cryptographic hash functions such as SHA-256 or MD5 to convert resource block data into a unique numerical identifier of fixed length (such as a 32-bit hexadecimal string). For example, a 1MB game resource block, after being hashed using SHA-256, generates a 256-bit hash value. The first hash value is a hash value pre-calculated by the edge server when storing resource blocks, serving as a "digital fingerprint" of the resource block's integrity. For example, the hash value of a video block is generated at the Singapore node and written to the metadata table. Consistency determination: After downloading, the terminal recalculates the hash value of the received resource block (the second hash value) and compares it with the first hash value to verify whether the data has been tampered with or corrupted during transmission.

[0153] When storing resource blocks, the central server generates a first hash value for each block and synchronizes it to the edge servers. After the terminal finishes downloading, it calculates a second hash value using its local hash engine and performs block-by-block verification in conjunction with the first hash value. For example, in a multinational education platform, a 1GB course package is divided into 1000 1MB blocks. Each block is stored on edge servers in locations A and B, each with its own first hash value. When a user in location C downloads the resource, the terminal performs a hash calculation for each block it receives. If it finds that the second hash value of a block does not match its corresponding first hash value (e.g., due to data corruption caused by transmission errors), it automatically triggers a retransmission request from other nodes.

[0154] Hash verification can detect single-bit errors, preventing data integrity breaches caused by network noise or node storage failures. When consistency checks fail, the system can pinpoint the faulty block (e.g., by block identifier) ​​instead of downloading the entire block again, thus shortening repair time. For example, in 4K video streaming, if a 10KB texture block fails verification, it only needs to be retrieved from a neighboring node, reducing repair time. The hash value itself represents only a tiny percentage of the data (e.g., a 1MB block hash is only 256 bytes), and by synchronizing metadata instead of full data redundancy, storage overhead is significantly reduced. In cloud gaming scenarios, this mechanism reduces redundant storage costs across global nodes.

[0155] Please see Figure 11 , Figure 11 This diagram illustrates a timing diagram for resource block hash value verification provided in an embodiment of this application. During the resource block distribution phase, as in step S1101, the central server 1120 divides the resource packet into M resource blocks and calculates the M hash values ​​corresponding to the M resource blocks. As in step S1102, the central server 1120 sends the M resource blocks carrying the first hash value to edge servers A 1121, B 1122, C 1123, and D 1124 in parallel. As in step S1103, edge servers A 1121, B 1122, C 1123, and D 1124 respectively store the M resource blocks carrying the first hash value.

[0156] During the resource package download phase, terminal 1110 sends a resource package download request to the nearest edge server A 1121. As in steps S1111 to S1115, terminal 1110 receives M resource blocks carrying first hash values ​​from edge servers A 1121, B 1122, C 1123, and D 1124. As in step S1116, terminal 1110 calculates M hash values ​​corresponding to the M resource blocks according to a hash algorithm, obtaining M second hash values. As in step S1117, the terminal performs a consistency check based on the M first hash values ​​and the M second hash values. If the M first hash values ​​and M second hash values ​​are the same, the M resource blocks are reassembled using a memory buffer.

[0157] The method provided in this application ensures data is obtained from the nearest node through dynamic node selection, while hash verification guarantees the accuracy of the obtained data. This dual protection is particularly important in 5G edge computing scenarios—when a hardware failure at an edge node leads to data corruption, the terminal can quickly switch to a healthy node through consistency determination, without relying on the complex fault-tolerance logic of the upper application layer. This design not only improves the reliability of the distributed system but also provides underlying technical support for digital rights protection (such as preventing illegal tampering), and is especially suitable for scenarios with high security requirements such as blockchain-based evidence storage and medical image sharing.

[0158] In an optional embodiment of the resource download method provided in the above embodiments of this application, after sending M first hash values ​​to the terminal, the method further includes:

[0159] The receiving terminal sends a resource package download success message, which indicates that the terminal performs a consistency determination based on M first hash values ​​and M second hash values, and obtains a determination result that the M first hash values ​​and M second hash values ​​are the same.

[0160] or,

[0161] The receiving terminal sends a download request for the i-th resource block, wherein the download request for the i-th resource block is used to represent the result that the terminal performs a consistency determination based on M first hash values ​​and M second hash values ​​and obtains that the first hash value and the second hash value corresponding to the i-th resource block are different, where M≥i≥1.

[0162] Understandably, a successful resource package download message is a confirmation message sent by the terminal after downloading all M resource blocks, containing a global consistency determination result (such as "SUCCESS" or "FAILED"). The terminal verifies data integrity by comparing the local hash value (second hash value) of the M resource blocks with the first hash value sent by the server. Upon receiving a successful determination message, the server triggers a global resource status update (such as marking the resource package as distributed and disabling redundant backup tasks), and may record the terminal's verification pass rate. If a failure determination message is received, a global alarm process is initiated to automatically investigate storage anomalies at edge nodes. This successful message enables unattended confirmation of the download status, reducing the cost of manual inspection.

[0163] For example, please refer to Figure 12 , Figure 12 This is a timing diagram for sending terminal hash verification results as provided in the embodiments of this application. The content of the resource block distribution phase is related to... Figure 11 The content of the resource block distribution stage is the same as that in the previous stage, and will not be repeated here. Steps S1211 to S1216 of the resource package download stage are the same as those in the previous stage. Figure 11The steps corresponding to the resource package download stage are the same and will not be repeated here. For example, in step S1217, if the M first hash values ​​and the M second hash values ​​are the same, the terminal 1210 sends a resource package download success message to the edge server A1221. For example, in step S1218, the terminal 1210 reassembles the M resource blocks through the memory buffer.

[0164] The i-th resource block download request: An independent download instruction sent by the terminal for a specific block (e.g., block number i=45), including the hash value comparison result of the erroneous block (e.g., "BLOCK_45_MISMATCH"). Upon receiving such a request, the server performs a fault-tolerant response: first, it re-pushes the block from its local redundant replica (prioritizing nodes in the same region); if this fails, it switches to another available node via routing; finally, it triggers a blockchain notarization request from the central server. This isolates the problem to a specific block (rather than the entire resource package), avoiding a full data retransmission. For example, if only two blocks in a 1GB update package are corrupted, only 2MB of data is re-downloaded instead of the entire 1GB.

[0165] For example, please refer to Figure 13 , Figure 13 This is a timing diagram for sending terminal hash verification results as provided in the embodiments of this application. The content of the resource block distribution phase is related to... Figure 11 The content of the resource block distribution stage is the same as that in the previous stage, and will not be repeated here. Steps S1311 to S1316 of the resource package download stage are the same as those in the previous stage. Figure 11 The steps for the resource package download stage are the same and will not be repeated here. If terminal 1310 performs a consistency determination based on M first hash values ​​and M second hash values ​​and finds that the first hash value and the second hash value corresponding to the i-th resource block are different, then as in step S1317, terminal 1310 sends a request to the edge server A1221 to re-download the i-th resource block.

[0166] This application provides a method that reduces the incidence of data integrity corruption or content distortion during transmission or storage due to factors such as network interference, hardware failure, and human tampering by using dynamic block partitioning rules and edge node health monitoring. Cross-validation (server-side verification + terminal verification) is implemented through dual hash verification to improve detection accuracy. Block-level retry requests combined with intelligent routing selection (prioritizing low-latency nodes) shorten fault recovery time.

[0167] In an optional embodiment of the resource download method provided in the above embodiments of this application, after receiving the i-th resource block download request sent by the terminal, the method further includes:

[0168] The target edge server for sending the i-th resource block to the terminal is determined to be the first edge server among the Q target edge servers;

[0169] Control the second edge server to send the i-th resource block to the terminal, wherein the second edge server is any one of the Q target edge servers except the first edge server.

[0170] It is understandable that tracing the edge server that sent the i-th resource block and determining that the first edge server was the node that sent the i-th resource block to the terminal may have caused the data of the i-th resource block stored in the first edge server to be modified. In this case, any target edge server other than the first edge server can be controlled to send the i-th resource block to the terminal. Preferably, the target edge server with lower network latency, lower current bandwidth utilization, lower operating load and closer distance to the terminal can be determined as the second edge server.

[0171] For example, please refer to Figure 14 , Figure 14 The sequence diagram for retransmitting resource blocks is shown. As in step S1413, edge server B 1422 sends the i-th resource block to terminal 1410. As in step S1416, terminal 1410 verifies the M first hash values ​​and M second hash values, finding that the first hash value and second hash value of the i-th resource block are inconsistent. As in step S1417, terminal 1410 sends a request to edge server A 1421 to re-download the i-th resource block. As in step S1418, edge server A 1421 sends the i-th resource block to terminal 1410. As in step S1419, terminal 1410 recalculates the hash value of the newly received i-th resource block. If the first hash value and second hash value of the i-th resource block are the same, as in step S1420, terminal 1410 reassembles the M resource blocks using a memory buffer.

[0172] Please see Figure 15 , Figure 15 The diagram illustrates resource block exception handling. If a resource block download fails, the terminal records the block's identifier and re-downloads it from another available edge server. If three consecutive downloads fail, the edge server containing the resource block is marked as "unavailable," and this is reported to the central server. Downloaded resource blocks are cached on the terminal, supporting resume download and preventing duplicate downloads.

[0173] The method provided in this application optimizes the average utilization of edge servers through load balancing between primary and backup nodes. When an edge server sends a resource block that fails the hash consistency check, other edge servers immediately send a new resource block, reducing the error rate and enabling rapid error correction.

[0174] In an optional embodiment of the resource download method provided in the above embodiments of this application, the method further includes:

[0175] Based on the hash algorithm, calculate the M hash values ​​corresponding to the M resource blocks to obtain the M first hash values;

[0176] After storing M resource blocks across P edge servers, so that each edge server stores M resource blocks, the following steps are also included:

[0177] Control each of the P edge servers to calculate the M hash values ​​corresponding to the M resource blocks according to the hash algorithm, and obtain the M third hash values;

[0178] Each of the P edge servers is controlled to perform a consistency determination based on M first hash values ​​and M third hash values.

[0179] Understandably, the first hash value—the initial hash value (such as SHA-256) calculated by the central server or content generation nodes when dividing the resource package—serves as a digital signature of the original integrity of the resource block. For example, a 1MB block of game code generates a hash value H1 = abc123...xyz, which is then stored on the blockchain. Establishing a data fingerprint during the resource generation stage provides a benchmark for all subsequent verifications. In distributed storage scenarios, each edge server must synchronously record the first hash value when storing resource blocks to ensure the initial state of all copies is traceable.

[0180] The third hash value: After the edge server stores the resource block locally, it periodically (e.g., hourly) recalculates the hash value, reflecting the real-time status of the storage medium. For example, if an edge node's block data shifts due to hard drive aging, its third hash value will deviate from H1. Each edge server independently performs hash calculations and consistency comparisons, for example, by automatically triggering verification tasks through smart contracts. When the first and third hash values ​​of the same resource block are detected to be unequal, the node immediately marks itself as "untrusted" and triggers a data repair process.

[0181] Each edge server reports the comparison result of the first hash value and the third hash value of each resource block to the consortium blockchain consensus node, and achieves global consensus through the Byzantine fault tolerance algorithm. When the difference rate between the third hash value and the first hash value of an edge node exceeds a threshold (e.g., 5%), the system automatically initiates the data tracing process, obtains the correct block from other healthy nodes, and recalculates the hash.

[0182] As shown in Table 2, Table 2 shows the hash verification levels.

[0183] Table 2

[0184] Verification level Verification content algorithm Triggering conditions Block level Single block integrity MD5 When download complete File level Correct combination of all file blocks Merkle Tree After all parts are downloaded Version level Version consistency across the entire update package RSYNC Pre-installation verification

[0185] The method provided in this application, by constructing an end-to-end dual hash verification and distributed consistency determination mechanism, achieves multi-level protection of data integrity and the self-evolution capability of the storage system. The first hash value serves as the digital fingerprint of the data source, combined with blockchain evidence storage technology to ensure the traceability of the original integrity of the resource block, while the periodic local calculation of the third hash value monitors the health status of the edge server storage medium in real time, promptly detecting changes caused by hardware aging, data corruption, or malicious tampering.

[0186] In an optional embodiment of the resource download method provided in the above embodiments of this application, after controlling each of the P edge servers to perform a consistency determination based on M first hash values ​​and M third hash values, the method further includes:

[0187] If the third hash value corresponding to the i-th resource block calculated by the first edge server is not equal to the first hash value, the first edge server is controlled to delete the i-th resource block, and the second edge server is controlled to send the i-th resource block to the first edge server so that the first edge server stores the i-th resource block sent by the second edge server. The distance between the first edge server and the second edge server is less than the distance threshold, and both the first edge server and the second edge server are edge servers among P edge servers.

[0188] The method provided in this application involves each of P edge servers calculating a hash value for its own resource block and comparing it with the first hash value of each resource block calculated by the central server. When the first edge server detects that the third hash value of the i-th resource block does not match the first hash value, the system triggers a response: first, it performs an atomic deletion operation (removing only the corrupted block, not the entire resource packet) to prevent the spread of erroneous data; then, based on the spatial topology database, it selects a second edge server less than 50km away as the data source and establishes a dedicated transmission channel through the QUIC protocol; finally, it uses incremental verification technology (such as verifying only the difference parts of the corrupted block) to complete data reconstruction. The synchronization process uses P2P transmission, prioritizing data acquisition from low-latency nodes.

[0189] like Figure 16 As shown, Figure 16 The diagram illustrates the resource block consistency verification process. For each resource block, the edge server calculates a hash value, concatenates the hash values ​​of M resource blocks, and compares the concatenated result with the hash value of the central server.

[0190] For example, such as Figure 17 As shown, Figure 17The sequence diagram for resource block consistency verification is shown. As in step S1701, the central server 1720 divides the resource packet into blocks and calculates the hash values ​​of M resource blocks. As in step S1702, the central server 1720 sends the M resource blocks carrying the first hash values ​​to edge servers A1721 and B1722 in parallel. As in step S1703, edge servers A1721 and B1722 store the M resource blocks. As in step S1704, edge servers A1721 and B1722 respectively calculate the hash values ​​of the M resource blocks to obtain the third hash value corresponding to each resource block. As in step S1705, edge servers A1721 and B1722 perform consistency verification on the first hash value and the third hash value corresponding to the M resource blocks, respectively. If edge server A1721 finds that the first hash value and the third hash value corresponding to the i-th resource block are not equal, as in step S1706, edge server A1721 deletes the i-th local edge server, as in step S1707, edge server A1721 sends a request to edge server B1722 to obtain the i-th resource block, as in step S1708, edge server B1722 sends the i-th resource block to edge server A1721.

[0191] The method provided in this application extends the lifespan of storage media by proactively eliminating corrupted blocks and prioritizing retransmission using low-load nodes. Through collaborative autonomy among edge nodes, it achieves end-to-end automation from fault detection to data repair, constructing a data protection paradigm in distributed storage systems.

[0192] For example, such as Figure 18 As shown, Figure 18 This is an architecture diagram of the method provided in the embodiments of this application. The distributed resource download system described in the embodiments of this application achieves efficient collaborative data distribution and service quality assurance through a three-layer architecture of center-edge-terminal. The entire process begins with the central server initiating version release and data synchronization. It first differentiates the target business resource package into blocks according to functional modules and media types (e.g., code modules are split into independent functional blocks, and video streams are divided into fixed sizes), and generates a digital fingerprint (first hash value) for each resource block using the SHA-256 algorithm. These block data are stored on the blockchain to ensure source credibility before transmission, and are then synchronized to a globally distributed cluster of P edge storage servers.

[0193] After receiving data, the edge storage server cluster allocates M resource blocks to various nodes for storage based on a dynamic load balancing algorithm. Each node not only stores a complete copy of the block but also periodically (e.g., hourly) recalculates the hash value (third hash value) locally and compares it with the original hash value to monitor the health of the storage medium. When an edge server (e.g., the Singapore node) detects an anomaly in the third hash value of the i-th resource block, it immediately triggers an autonomous repair process: first, the corrupted block is deleted; then, a neighboring node with a distance of <50km and a load of <60% is selected as the data source through a spatial topology database, and an incremental verification retransmission is performed through a dedicated transmission channel established via the QUIC protocol.

[0194] When a user initiates a download request, the system dynamically selects Q optimal edge servers based on multi-dimensional parameters (network latency, bandwidth, load, and geographical matching degree), and sends the chunked tasks sequentially according to priority markers. Each chunk employs TCP acceleration and multi-path aggregation technology during transmission. Upon receiving the chunk, the terminal performs consistency checks using MD5 verification and the first hash value stored on the blockchain. In case of failure, the chunk is retransmitted from other healthy nodes. Finally, the terminal integrates all correct chunks and completes the business logic rendering. The entire process automatically records key metrics (such as verification success rate and repair time) through smart contracts, feeding them back to the central server to optimize subsequent chunking strategies.

[0195] Furthermore, the horizontal scaling scheme proposed in this application achieves the dual goals of storage efficiency and cost optimization through hot and cold data separation and dynamic resource control mechanisms. In terms of data tiered management, the system stores frequently accessed hot data (such as recently downloaded game resources and live stream caches) in high-performance NVMe SSDs, retaining the three most recent versions to support rapid rollback and version comparison; while infrequently accessed cold data (such as historical course recordings and offline documents) is archived to low-cost object storage (such as AWS S3), achieving on-demand loading through intelligent caching strategies, significantly reducing cold data storage costs while maintaining data accessibility. This tiered architecture reduces hot data access latency from 15ms to 2ms and cold data retrieval time to within 300ms, balancing performance and economy. In terms of resource elasticity control, the system calculates the comprehensive load value and triggers intelligent scaling decisions by real-time monitoring of edge node CPU utilization, memory usage, and bandwidth throughput. When the load remains above 80% for five minutes, the system automatically requests virtual machine nodes from the cloud platform and initializes storage services. The new nodes seamlessly join the cluster via the Anycast routing protocol, achieving horizontal scaling. Conversely, if the load falls below 30% for more than an hour, the system marks idle nodes as terminateable and releases resources, recovering costs. By dynamically adjusting the number of nodes, the system consistently maintains an optimal load range of 60%-70%, increasing single-node resource utilization to over 90% and reducing failover time to the second level. This adaptive resource management strategy not only ensures stability during peak business periods but also optimizes cloud resource procurement plans through load prediction models (such as LSTM-based traffic prediction), achieving elastic and intelligent operation and maintenance of IT infrastructure.

[0196] This application also provides a resource download device; please refer to [link / reference]. Figure 19 In (A), the resource download device 1900 includes:

[0197] The receiving module 1901 is used to receive a resource package download request sent by the terminal when each of the P edge servers stores the corresponding M resource blocks of the target service; wherein, the M resource blocks are obtained by dividing the resource package of the target service into blocks, the resource package is the data file for running the target service, the M resource blocks correspond to M resource block identifiers, and the resource package download request carries the address information of the terminal, P≥1, M>1;

[0198] The determination module 1902 is used to determine Q target edge servers from the P edge servers based on the terminal's address information and the P performance parameters corresponding to the P edge servers, and to determine Q sending tasks corresponding to the Q target edge servers. The Q sending tasks carry M resource block identifiers, and each sending task carries at least one resource block identifier. The sending tasks are used to instruct the target edge servers to send the corresponding resource blocks to the terminal according to the resource block identifiers, where P≥Q≥1.

[0199] The control module 1903 is used to control Q target edge servers to send M resource blocks to the terminal based on Q sending tasks.

[0200] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application, please refer to... Figure 19 In section (B), the resource download device 1900 also includes:

[0201] Module 1904 is used to obtain the resource package of the target business.

[0202] Module 1902 is also used to determine the chunking rules based on the file types in the resource package;

[0203] Processing module 1905 is used to divide the resource package into M resource blocks according to the block division rules.

[0204] Storage module 1906 is used to store M resource blocks in P edge servers, so that each edge server stores M resource blocks.

[0205] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application,

[0206] The determining module 1902 is further configured to determine a first block rule based on the file types of R first type files, wherein the first block rule is used to indicate that the data in the first type files are blocked according to function;

[0207] The determination module 1902 is further configured to determine a second block rule based on the file types of the T second type files, wherein the second block rule is used to instruct that the data in the second type files be divided into blocks according to a preset data size;

[0208] Processing module 1905 is also used to divide the data in R first type files into blocks according to the first block division rule to obtain W resource blocks, where W > R;

[0209] The processing module 1905 is also used to divide the data in T second-type files into blocks according to the second block division rule to obtain U resource blocks, where U > T and U + W = M.

[0210] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application, please refer to... Figure 19 In section (C), the resource download device 1900 also includes:

[0211] The marking module 1907 is used to mark the priority of M resource blocks according to the N running functions corresponding to M resource blocks, so as to obtain the N download priority order corresponding to M resource blocks, where M≥N≥1;

[0212] The control module 1903 is also used to control the Q target edge servers to send M resource blocks to the terminal in sequence according to the Q sending tasks and N download priority orders, wherein resource blocks with the same priority order are sent in parallel.

[0213] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application, the performance parameters include network latency parameters, available bandwidth parameters, and operating load parameters; please refer to... Figure 19 In (D), the resource download device 1900 also includes:

[0214] The acquisition module 1904 is also used to acquire P network latency parameters, P available bandwidth parameters, P operating load parameters, and address information of P edge servers corresponding to P edge servers;

[0215] The calculation module 1908 is used to calculate P geographic location matching degrees based on the address information of the terminal and the address information of P edge servers, wherein the geographic location matching degree is used to characterize the distance between the terminal and the edge server.

[0216] The calculation module 1908 is also used to perform weighted calculations on P network latency parameters, P available bandwidth parameters, P operating load parameters and P geographical location matching degrees to obtain P scores corresponding to P edge servers;

[0217] The determination module 1902 is further configured to determine Q target edge servers from P edge servers based on P scores, wherein the scores of the target edge servers are greater than a score threshold, or the Q target edge servers are the Q edge servers with higher scores among the P edge servers.

[0218] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application,

[0219] The determination module 1902 is further configured to determine X edge servers whose network latency parameters are less than the network latency threshold from the P edge servers based on the P network latency parameters of the P edge servers, where P > X ≥ 1;

[0220] The determination module 1902 is further configured to determine Y edge servers whose available bandwidth parameters are greater than the bandwidth threshold from the X edge servers based on the X available bandwidth parameters of the X edge servers, where P > X > Y ≥ 1;

[0221] The determination module 1902 is further configured to determine Z edge servers whose operating load parameters are less than the load threshold from the Y edge servers based on the Y operating load parameters of the Y edge servers, wherein P > X > Y > Z ≥ 1;

[0222] The determination module 1902 is also used to calculate Z distance values ​​based on the Z address information of the Z edge servers and the address information of the terminal;

[0223] The determination module 1902 is also used to determine Q target edge servers from Z edge servers based on Z distances, wherein the distance between the target edge server and the terminal is less than a distance threshold, P>X>Y>Z>Q≥1.

[0224] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application,

[0225] The determination module 1902 is also used to determine the Q sending tasks corresponding to the Q target edge servers based on the Q network delays, Q available bandwidths, and Q operating loads of the Q target edge servers.

[0226] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application,

[0227] The calculation module 1908 is also used to calculate the M hash values ​​corresponding to the M resource blocks according to the hash algorithm, and obtain the M first hash values;

[0228] The processing module 1905 is also used to send M first hash values ​​to the terminal. After receiving M resource blocks, the terminal calculates the M hash values ​​corresponding to the M resource blocks according to the hash algorithm to obtain M second hash values. The terminal performs consistency determination based on the M first hash values ​​and the M second hash values.

[0229] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application,

[0230] The processing module 1905 is also used to receive resource package download success information sent by the terminal, wherein the resource package download success information is used to indicate that the terminal performs consistency determination based on M first hash values ​​and M second hash values ​​and obtains a determination result that the M first hash values ​​and M second hash values ​​are the same;

[0231] or,

[0232] The processing module 1905 is further configured to receive the i-th resource block download request sent by the terminal, wherein the i-th resource block download request is used to represent the result that the terminal performs consistency determination based on M first hash values ​​and M second hash values ​​and obtains that the first hash value and the second hash value corresponding to the i-th resource block are different, M≥i≥1.

[0233] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application,

[0234] The determination module 1902 is also used to determine that the target edge server that sends the i-th resource block to the terminal is the first edge server among the Q target edge servers;

[0235] The control module 1903 is also used to control the second edge server to send the i-th resource block to the terminal, wherein the second edge server is any one of the Q target edge servers except the first edge server.

[0236] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application,

[0237] The calculation module 1908 is also used to calculate the M hash values ​​corresponding to the M resource blocks according to the hash algorithm, and obtain the M first hash values;

[0238] The control module 1903 is also used to control each of the P edge servers to calculate the M hash values ​​corresponding to the M resource blocks according to the hash algorithm, and obtain the M third hash values.

[0239] The control module 1903 is also used to control each of the P edge servers to perform consistency determination based on M first hash values ​​and M third hash values.

[0240] In an optional embodiment of the resource download generation apparatus provided in the above embodiments of this application,

[0241] The control module 1903 is further configured to, when the third hash value corresponding to the i-th resource block calculated by the first edge server is not equal to the first hash value, control the first edge server to delete the i-th resource block and control the second edge server to send the i-th resource block to the first edge server, so that the first edge server stores the i-th resource block sent by the second edge server, wherein the distance between the first edge server and the second edge server is less than a distance threshold, and both the first edge server and the second edge server are edge servers among P edge servers.

[0242] Those skilled in the art will clearly 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.

[0243] 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.

[0244] 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, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0245] 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.

[0246] Furthermore, the functional units in the various 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0247] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it 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 all or part 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 server or terminal device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0248] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for downloading resources, characterized in that, include: In the case that each of the P edge servers stores M resource blocks corresponding to the target service, a resource package download request sent by the terminal is received; wherein, the M resource blocks are obtained by dividing the resource package of the target service into blocks, the resource package is a data file for running the target service, the M resource blocks correspond to M resource block identifiers, and the resource package download request carries the address information of the terminal, P≥1, M>1; Based on the address information of the terminal and the P performance parameters corresponding to the P edge servers, Q target edge servers are determined from the P edge servers, and Q sending tasks corresponding to the Q target edge servers are determined. The Q sending tasks carry the M resource block identifiers, and each sending task carries at least one resource block identifier. The sending task is used to instruct the target edge server to send the corresponding resource block to the terminal according to the resource block identifier, where P≥Q≥1. Based on the Q sending tasks, control the Q target edge servers to send the M resource blocks to the terminal.

2. The resource download method as described in claim 1, characterized in that, The method further includes: Obtain the resource package for the target business; The segmentation rules are determined based on the file types in the resource package; According to the segmentation rules, the resource package is segmented into M resource blocks; The M resource blocks are stored in the P edge servers, so that each edge server stores the M resource blocks.

3. The resource download method as described in claim 2, characterized in that, The resource package includes R first-type files and T second-type files, where R≥1 and T≥1; The step of determining the segmentation rules based on the file types in the resource package includes: Based on the file types of the R first type files, a first block rule is determined, wherein the first block rule is used to indicate that the data in the first type files is divided into blocks according to function; Based on the file types of the T second-type files, a second block rule is determined, wherein the second block rule is used to instruct that the data in the second-type files be divided into blocks according to a preset data size; The process of dividing the resource package into M resource blocks according to the block division rules includes: According to the first partitioning rule, the data in the R first type files are partitioned into W resource blocks, where W > R; According to the second partitioning rule, the data in the T second-type files are partitioned into U resource blocks, where U > T and U + W = M.

4. The resource download method as described in claim 1, characterized in that, The method further includes: Based on the N running functions corresponding to the M resource blocks, the M resource blocks are prioritized to obtain the N download priority orders corresponding to the M resource blocks, where M≥N≥1; The step of controlling the Q target edge servers to send the M resource blocks to the terminal according to the Q sending tasks includes: Based on the Q sending tasks and the N download priority orders, the Q target edge servers are controlled to send the M resource blocks to the terminal in sequence, wherein resource blocks with the same priority order are sent in parallel.

5. The resource download method as described in claim 1, characterized in that, The performance parameters include network latency parameters, available bandwidth parameters, and operating load parameters; The step of determining Q target edge servers from the P edge servers based on the terminal's address information and the P performance parameters corresponding to the P edge servers includes: Obtain the P network latency parameters, P available bandwidth parameters, P operating load parameters, and the address information of the P edge servers corresponding to the P edge servers; Based on the address information of the terminal and the address information of the P edge servers, P geographic location matching degrees are calculated, wherein the geographic location matching degree is used to characterize the distance between the terminal and the edge server; The P network latency parameters, P available bandwidth parameters, P operating load parameters, and the P geographical location matching degrees are weighted and calculated to obtain P scores corresponding to the P edge servers; Based on the P scores, Q target edge servers are determined from the P edge servers, wherein the score of the target edge server is greater than the score threshold, or the Q target edge servers are the Q edge servers with higher scores among the P edge servers.

6. The resource download method as described in claim 5, characterized in that, The step of determining Q target edge servers from the P edge servers based on the terminal's address information and the P performance parameters corresponding to the P edge servers includes: Based on the P network latency parameters of the P edge servers, determine X edge servers whose network latency parameters are less than the network latency threshold from the P edge servers, where P > X ≥ 1; Based on the X available bandwidth parameters of the X edge servers, determine Y edge servers from the X edge servers whose available bandwidth parameters are greater than the bandwidth threshold, where P > X > Y ≥ 1; Based on the Y operating load parameters of the Y edge servers, determine Z edge servers whose operating load parameters are less than the load threshold from the Y edge servers, where P > X > Y > Z ≥ 1; Calculate Z distance values ​​based on the Z address information of the Z edge servers and the address information of the terminal; Based on the Z distances, Q target edge servers are determined from the Z edge servers, wherein the distance between the target edge server and the terminal is less than a distance threshold, P > X > Y > Z > Q ≥ 1.

7. The resource download method as described in claim 5, characterized in that, Determining the Q sending tasks corresponding to the Q target edge servers includes: Based on the Q network delays, Q available bandwidths, and Q operating loads of the Q target edge servers, determine the Q sending tasks corresponding to the Q target edge servers.

8. The resource download method as described in claim 1, characterized in that, The method further includes: According to the hash algorithm, calculate the M hash values ​​corresponding to the M resource blocks to obtain the M first hash values; The M first hash values ​​are sent to the terminal. After receiving the M resource blocks, the terminal calculates the M hash values ​​corresponding to the M resource blocks according to the hash algorithm to obtain M second hash values. The terminal performs a consistency determination based on the M first hash values ​​and the M second hash values.

9. The resource download method as described in claim 8, characterized in that, After sending the M first hash values ​​to the terminal, the process further includes: The terminal receives a resource package download success message, wherein the resource package download success message is used to indicate that the terminal performs a consistency determination based on the M first hash values ​​and the M second hash values, and obtains a determination result that the M first hash values ​​and the M second hash values ​​are the same; or, The terminal receives a download request for the i-th resource block, wherein the i-th resource block download request is used to indicate that the terminal performs a consistency determination based on the M first hash values ​​and the M second hash values, and obtains a result that the first hash value and the second hash value corresponding to the i-th resource block are different, where M≥i≥1.

10. The resource download method as described in claim 9, characterized in that, After receiving the i-th resource block download request sent by the terminal, the method further includes: The target edge server for sending the i-th resource block to the terminal is determined to be the first edge server among the Q target edge servers; The second edge server is controlled to send the i-th resource block to the terminal, wherein the second edge server is any one of the Q target edge servers except the first edge server.

11. The resource download method as described in claim 2, characterized in that, The method further includes: According to the hash algorithm, calculate the M hash values ​​corresponding to the M resource blocks to obtain the M first hash values; After storing the M resource blocks in the P edge servers, so that each edge server stores the M resource blocks, the method further includes: Each of the P edge servers is controlled to calculate the M hash values ​​corresponding to the M resource blocks according to the hash algorithm, thereby obtaining M third hash values; Each of the P edge servers is controlled to perform a consistency determination based on the M first hash values ​​and the M third hash values.

12. The resource download method as described in claim 11, characterized in that, After controlling each of the P edge servers to perform a consistency determination based on the M first hash values ​​and the M third hash values, the method further includes: If the third hash value corresponding to the i-th resource block calculated by the first edge server is not equal to the first hash value, the first edge server is controlled to delete the i-th resource block, and the second edge server is controlled to send the i-th resource block to the first edge server, so that the first edge server stores the i-th resource block sent by the second edge server. The distance between the first edge server and the second edge server is less than the distance threshold, and both the first edge server and the second edge server are edge servers among the P edge servers.

13. A resource download device, characterized in that, include: The receiving module is configured to receive a resource package download request sent by a terminal when each of the P edge servers stores M resource blocks corresponding to the target service; wherein the M resource blocks are obtained by dividing the resource package of the target service into blocks, the resource package is a data file for running the target service, the M resource blocks correspond to M resource block identifiers, and the resource package download request carries the address information of the terminal, where P≥1 and M>1; The determining module is configured to determine Q target edge servers from the P edge servers based on the address information of the terminal and the P performance parameters corresponding to the P edge servers, and to determine Q sending tasks corresponding to the Q target edge servers. The Q sending tasks carry the M resource block identifiers, and each sending task carries at least one resource block identifier. The sending task is used to instruct the target edge server to send the corresponding resource block to the terminal according to the resource block identifier, where P≥Q≥1. The control module is used to control the Q target edge servers to send the M resource blocks to the terminal according to the Q sending tasks.

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

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

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

Images