A multi-service edge network cache optimization method based on delay hit

Abstract

The present invention discloses a multi-service edge network cache optimization method based on delay hit, which belongs to the field of edge computing and online caching. The method includes: determining the optimal request processing path through real-time analysis of local cache hit status, neighboring server cache distribution and relay path delay; detecting the remaining time window of the current file acquisition operation, and dynamically evaluating the cost of waiting for a delay hit or triggering a new operation; selecting the target server based on weight sorting, dynamically eliminating low-weight files, and combining a cross-server redundancy elimination mechanism to reduce cache conflicts; when both the local cache and the relay path do not meet the delay constraints, dynamically evaluating the cloud response time and bandwidth cost of the bypass operation to determine the feasibility of the bypass operation; dynamically calculating the file weight based on historical request characteristics and operation delay, and quantifying the file replacement cost in combination with the server cache status and remaining capacity. The present invention can greatly reduce the average retrieval delay of user requests.

Description

Technical Field

[0001] The present invention belongs to the field of edge computing and online caching, and in particular relates to a multi-service edge network cache optimization method based on delay hit. Background Art

[0002] Mobile Edge Computing (MEC), an emerging distributed computing paradigm, significantly reduces data transmission distances and network latency by moving computing, storage, and network resources from traditional centralized clouds to network edge nodes (such as base stations, routers, and local servers) close to end users or data sources, thereby meeting the quality of service requirements of real-time-sensitive applications. This technology is driven by the stringent requirements for millisecond-level response, high bandwidth, and data privacy protection in scenarios such as the Internet of Things (IoT), autonomous driving, augmented reality (AR / VR), and the Industrial Internet of Things (IIoT). For example, in autonomous driving, vehicles must process massive amounts of data from lidar, cameras, and sensors in real time, and any delay in cloud transmission can lead to erroneous decisions. In AR / VR scenarios, the smoothness of user interactions relies heavily on local rendering and low-latency content distribution. However, edge computing faces multiple technical challenges in its implementation: First, the resource constraints of edge servers, whose computing power, storage capacity, and energy supply are typically far lower than those of cloud data centers, make it difficult to directly migrate traditional cloud computing methods. Second, the complexity of dynamic network environments, user mobility, frequent changes in network topology, and bursty traffic require highly adaptive resource allocation strategies. Third, the challenge of multi-server collaboration: how to efficiently share data, synchronize cache states, and implement task offloading across different edge nodes is key to improving overall system performance. Furthermore, edge computing must balance data localization with global optimization. While local processing can reduce latency, cross-node collaborative decision-making (such as multi-user request scheduling and distributed cache updates) requires complex protocol support. These challenges have led to the deep integration of edge computing and caching technologies, maximizing the utilization of limited resources in edge networks through intelligent resource management and real-time decision-making.

[0003] Online caching algorithms, as a core enabling technology for edge computing, aim to dynamically manage cached content to minimize data access latency and reduce reliance on the cloud. Traditional caching algorithms (such as LRU, LFU, and FIFO) perform well in cloud computing scenarios, relying primarily on locality (temporal and spatial locality) or frequency statistics to optimize cache replacement strategies. However, in edge computing environments, these algorithms face fundamental limitations: First, the latency hit problem becomes prominent. When a file is not cached locally, it must be retrieved from the cloud. If a subsequent request arrives before the file has been retrieved (i.e., the file is in transit), traditional algorithms cannot exploit this "about-to-be-cached" state, resulting in repeated retrieval operations or passive waiting, accumulating additional latency. (For example, LRU will simply replace the old file and re-retrieve it, ignoring the fact that the file being transferred may be available soon.) Second, there is a lack of multi-server collaboration. Existing algorithms are mostly optimized for single servers and fail to consider cross-server relay path selection, redundancy elimination, or load balancing. For example, when a file is not cached locally, traditional algorithms may blindly select a remote server or the cloud, ignoring the possibility that a neighboring server may cache the same file, resulting in unnecessary hops and link congestion. Furthermore, the lack of dynamic weight allocation is a significant issue. Traditional weighting methods rely solely on access frequency or recent access time, failing to incorporate real-time network status (such as link congestion and hop cost), future latency predictions (such as remaining file retrieval time), or cross-server resource distribution. This leads to rigid decision-making in highly dynamic edge networks. For example, while LRU-MAD incorporates latency hit statistics, its weight calculation does not quantify path selection costs, making it unable to balance the global costs of local retrieval, relay forwarding, and bypass operations in multi-server scenarios. More seriously, redundancy and conflict issues arise in multi-server scenarios: the same file may be cached repeatedly on multiple neighboring nodes, wasting storage resources and potentially leading to version inconsistencies or update conflicts (e.g., after a server updates a file, neighboring nodes still serve the old version). These limitations make traditional algorithms unable to meet the low latency, high reliability, and efficient resource utilization requirements of edge computing. New caching strategies that combine network topology awareness, dynamic weight fusion, and cross-node collaboration are urgently needed to cope with the complex and changing edge environment. Summary of the Invention

[0004] The present invention designs a multi-service edge network cache optimization method based on delay hits. In complex scenarios with delay hits, cross-server relays and cloud bypasses, the method significantly reduces the total request delay and improves the cache hit rate through dynamic weight updates, multi-path collaborative decision-making and competitive replacement mechanisms.

[0005] To achieve the above-mentioned purpose, the technical solution adopted by the present invention comprises the following steps:

[0006] Step S1, local and relay judgment: Check in real time whether the requested file is cached on the local server. If it is, respond to the request directly and update the weight. If it is not, traverse the cache status of neighboring servers and select the optimal path whose relay path delay is less than the local file re-retrieval delay and less than the delay hit time waiting for the current file to be retrieved. When there are multiple relay paths, the path with the best overall performance is selected based on the number of hops, link congestion and path stability, and prioritize reducing redundant hops to reduce transmission delay.

[0007] Step S2, delay hit judgment: real-time tracking of the remaining completion time of the file being obtained and calculation of the expected delay for waiting for the file cache to complete. If the waiting time is less than the delay of the relay or bypass operation, the request is marked as a delay hit and added to the high-priority queue. At the same time, a maximum waiting time threshold is set to avoid infinite waiting and service degradation. Timed requests automatically trigger relay or bypass operations to ensure service response reliability.

[0008] Step S3, server selection and acquisition replacement strategy: give priority to servers with sufficient remaining cache capacity to execute file acquisition to reduce the frequency of file replacement. If the target server cache space is insufficient, create a server cache copy and insert the file to be cached to simulate the change of weight. Iterate and eliminate files from low to high weight until the capacity constraint is met. If the file to be cached is not eliminated, trigger file acquisition and update the cache. Through the inter-server collaboration protocol, ensure that only one copy of the same file is cached within the preset hop range to avoid resource waste.

[0009] Step S4, bypass decision: When the delays of the local and relay paths and the acquisition strategy all exceed the service quality requirements, the cloud bypass operation is triggered. The cloud response time and bandwidth cost of the bypass operation are dynamically evaluated to select the operation path that meets the delay constraints and has the lowest resource consumption. The bypass triggering conditions are optimized through weight update and replacement strategies to adapt to the dynamic network environment.

[0010] Step S5, weight update strategy: comprehensively calculate the file weight based on the file's historical request frequency, cumulative delay hit time, and cross-server relay path delay.

[0011] Furthermore, in step S1, it is preferred to check whether the requested file is cached in the local server. If it is, the request is directly responded to and the weight is updated. If it is not, the neighboring server set is traversed and S is set to the entire server set. is the set of edge servers within the range of the i-th user, is a set of other edge servers that are not in the range of the i-th user, and then calculates the local edge server and relay edge servers Relay delay , specifically:

[0012] (1),

[0013] If f is already cached on the relay edge server On, and relay edge server If it is a non-local server, then the local edge server is calculated and relay edge servers The relay delay between them is σ, where σ is the delay time of each relay hop. From the local edge server To the Relay Edge Server The number of relay hops, so the local edge server and relay edge servers The relay delay is and The product of =1 means that file f has been cached on the server at time t.

[0014] Furthermore, in step S2, the specific method for calculating the delayed hit delay is as follows:

[0015] Delay hit: Delay hit in multi-cache scenario includes local delay hit and relay delay hit, local edge server Delayed hit time on It is expressed as follows:

[0016] (2),

[0017] in, Indicates the time when the file f was last triggered to obtain the operation, t indicates the current time, Indicates the length of each time slot, Indicates that file f is cached to the local edge server Therefore, the acquisition delay on Indicates the total time to obtain the file minus the time already obtained, that is, the remaining time required to delay the hit, where , is the time window for starting the file extraction operation, Is a decision variable, indicating whether to decide to obtain file f to the relay edge server at time T In the above, τ represents the feasible time step for generating delayed hit delay. Specifically, the timestamp of generating delayed hit delay is Expressed as:

[0018] (3),

[0019] The above formula (3) shows that Get f from f and make sure that the time interval between two requests for the same file f is less than Otherwise, f has been cached on the server or has been evicted by other files when the request arrives, so no delay hit will occur. However, in the relay case, it is still possible to trigger a delay hit, that is, if f is being obtained to the relay edge server , a relay edge server will appear Relay delay hit delay on , and because the relay and crawl processes can run concurrently, Equal to the maximum of the relay delay and the relay delay hit delay, specifically:

[0020] (4),

[0021] In determining After that, we still need to compare it with the relay delay, and finally get Specifically expressed as:

[0022] (5),

[0023] Furthermore, in step S3, if the current server does not have the file f that satisfies the local, relay, or delayed hit requirements, it is necessary to consider obtaining the file f from the cloud or bypassing the request to the cloud. The specific steps are as follows:

[0024] Step S31, first select a server with available cache space to obtain the file, if there is no such server, then select the weight Minimal local edge server To decide whether to extract the file, Indicates the local edge server Storage files in The weight of , where:

[0025] (6),

[0026] Step S32: Create a server A copy of Cache the requested file f in the copy and update the copy The cache size and weight of file f in;

[0027] Step S33: Set η to represent the minimum weight per unit cache space. Then, iteratively reduce the weight η of all cached files and move files with negative weights to Fevict, where Fevict is the set of files to be deleted, until the cache size of all files in the replica is less than its maximum capacity, where:

[0028] (7),

[0029] Represents a file The size of the cache space occupied.

[0030] Step S34: If the requested file f is still in the replica, the file in Fevict is transferred from the local edge server to the local edge server. Delete it and get the file f from the cloud to the relay edge server Otherwise, the file request is bypassed.

[0031] Furthermore, in step S4, if there is no file f in the current server that meets the local, relay or delayed hit requirements and the acquisition decision is rejected, the specific performance is as follows:

[0032] The cached file f does not exist on the local server. , the cached file f does not exist on the relay server, , and neither exists ,and When , the weight replacement strategy is used to optimize the bypass trigger conditions to adapt to the dynamic network environment.

[0033] Furthermore, in step S5, the weight is composed of three parts: cumulative hit delay, cumulative acquisition and delayed hit delay, and future delay prediction. The cumulative hit delay statistics the total delay of direct hits of files on local or relay servers, the cumulative acquisition and delayed hit delay statistics the total delay of acquisition operations triggered by cache misses and the subsequent waiting delay hit time, and the future delay prediction estimates the potential delay based on the square value of the file acquisition delay, and balances the contribution ratio of historical statistics and predictions through a weight adjustment factor. The weight adjustment factor ranges from 0 to 1. The weight retention threshold is dynamically set according to the remaining cache capacity of the server to prioritize the elimination of low-weight files. At the same time, the cache status and weight information of neighboring servers are periodically synchronized to optimize global resource allocation. The specific method is as follows:

[0034] The weight update process is divided into two modules: local module and relay module. The first is the local module. When the file requested by the user is cached locally, the local edge server that processes the request Cumulative hit delay on Plus file f cached to the local edge server The acquisition delay on , The file itself has its own attributes. If the file is not cached locally and the acquisition operation is triggered to select the file to be acquired locally, the local edge server will be Cumulative acquisition delay on Plus file f cached to edge server The acquisition delay on ,Since the delays caused by the two are different in actual situations, the hit will have almost no delay, so the cumulative hit delay and cumulative acquisition delay of the edge server should be calculated separately. If there is a file in the server that has been triggered to be acquired in the past and has not yet been acquired, it is called a delayed hit. The delayed hit delay is calculated together with the acquisition delay, but the delay caused by it is lower than the delay caused by caching the file f to the local edge server. The acquisition delay on , through the local edge server Delayed hit time on Calculate its remaining delay hit time and add it to Then, based on the file, the local edge server Cumulative hit delay on , local edge server Cumulative acquisition delay on , combined with the upper bound of file bypass latency from the cloud , calculate the local file weight, specifically:

[0035] (8),

[0036] Among them, the weight adjustment factor The value range is 0 to 1.

[0037] The relay module is similar to the local module. When the local server does not cache the file, it first determines whether there is a file cache condition on the edge server around it. If so, and the relay delay to the edge server is less than the bypass delay, then it will be placed on the relay server to process the same relay hit, and the relay edge server will be Cumulative hit delay on Add this file to the relay edge server The relay delay required by the relay is still likely to trigger a delay hit, so when the relay delay hits, the relay edge server Cumulative acquisition delay on Add local server to relay edge server Relay delay on and on relay edge servers The maximum value of the upper relay delay hit delay ,Here, since the relay file and the delay hit situation are processed in parallel, the final delay caused should take the maximum value between the two, and finally update the weight corresponding to the relay server file.

[0038] Compared with the prior art, the present invention has the following beneficial effects:

[0039] (1) Expand the traditional single edge cache to multiple servers, that is, the broadcast request sent by the user can be received by all servers in the range and the optimal processing strategy can be determined;

[0040] (2) Delayed hits are added so that requests that originally needed to be obtained or bypassed can be hit after a certain delay, greatly reducing the average retrieval delay of user requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 is a flow chart of a method in an embodiment of the present invention;

[0042] Figure 2 This is a workflow diagram of relay and delay hit in the present invention;

[0043] Figure 3 The flowchart of the present invention is based on the weight acquisition or bypassing process;

[0044] Figure 4 This is a workflow diagram for weight update of the present invention. DETAILED DESCRIPTION

[0045] The present invention will now be described in further detail with reference to the accompanying drawings.

[0046] Figure 1The following is a flowchart of a method according to an embodiment of the present invention. When a user issues a request, the system first checks whether the request can be directly accessed by the local server. If the requested file exists in a local cache, the request is immediately responded to and the relevant weights are updated to reflect the file's latest usage. If there is no local hit, the system proceeds to the relay determination phase, traversing the cache status of neighboring servers to identify the optimal relay path with lower latency than retrieving the file locally or waiting for the currently retrieved file to complete. During this process, the system comprehensively considers the number of hops, link congestion, and path stability, prioritizing relay paths with the fewest hops and highest transmission efficiency to reduce latency caused by redundant transmission. If there is a delay hit (i.e., the file is currently being retrieved and the remaining completion time is short), the system marks the request as high priority and dynamically evaluates the cost of waiting for a delay hit versus triggering a relay or bypass operation to select the strategy with the lowest impact on overall latency. If the local, relay, and delay hits fail to meet quality of service requirements, the system proceeds to the server selection and retrieval replacement phase. At this point, servers with sufficient remaining cache capacity are prioritized for file retrieval to avoid the performance loss caused by frequent file replacement. If the target server runs out of space, cached copies are created to simulate weight changes, gradually eliminating low-value files from low to high weights until the capacity constraint is met. During this process, the system uses a cross-server collaboration protocol to ensure that only one copy of the same file is retained within a preset range, avoiding resource waste. Finally, if all strategies fail to meet the latency constraint, the system triggers a cloud bypass operation, dynamically evaluating cloud response time and bandwidth costs to select the optimal path. After each request is processed, the system updates the file weight based on the results, providing a dynamic optimization basis for subsequent decision-making.

[0047] Figure 2This is the workflow diagram of relay and delay hit of the present invention. For requests that have arrived at the local server, the system first determines whether the requested file has been cached on the local server. If there is a local hit, the request is directly responded to and the weight is updated. If there is no hit, the system enters the delay hit judgment link, tracks the remaining completion time of the file being obtained in real time, and calculates the time window required to wait for the file to be cached. If the waiting time is less than the delay of the relay or bypass operation, the request is marked as a delay hit and added to the high priority queue, and the maximum waiting threshold is set to prevent infinite waiting. If the delay hit condition is not met, the system will further traverse the neighboring servers and filter out the optimal path that meets the relay condition. During this process, the system also checks whether there is a relay delay hit (that is, the file is being obtained by the neighboring server) and calculates the maximum value of the relay path delay and the relay delay hit. Subsequently, the system compares the delay values ​​of the local delay hit, the relay path, and the relay delay hit, and selects the minimum value of the three as the final processing strategy. If all conditions are not met (i.e., no hit, no relay path, and no latency hit), a weight-driven server selection or bypass strategy is implemented. By dynamically evaluating the server's cache status and cache cost, the decision is made whether to retrieve the file from the cloud or bypass the request. The entire process aims to minimize overall latency, ensuring service reliability in complex scenarios through multi-path coordination and dynamic priority scheduling.

[0048] Figure 3 This is a workflow diagram for weighted retrieval or bypassing in the present invention. It focuses on how to select a server or implement a bypass strategy based on weights in the absence of a hit. When local, relay, and delayed hits all fail to satisfy a request, the system first checks whether there is a server with sufficient remaining cache space. If so, that server is directly selected for the file retrieval operation, avoiding the additional delay introduced by file replacement. If all servers are running low on space, the server with the lowest overall weight (i.e., the node with the lowest overall cached file value) is selected, a cache replica is created for it, and the requested file is added to the replica to simulate weight changes. The system then iteratively reduces the weights of all cached files, each time subtracting the minimum unit weight (i.e., the ratio of weight to file size) and marking files with negative weights for deletion. This process continues until the replica capacity constraints are met. If the requested file still remains in the replica after the iteration, the file retrieval operation is triggered, and the file to be eliminated is deleted from the original server. If the file is eliminated, the request is directly bypassed to the cloud. This strategy prioritizes high-value files within limited cache space by dynamically simulating weight changes and a competitive replacement mechanism, avoiding unnecessary resource consumption. The entire process embodies weight-driven refined resource management, ensuring the optimal balance between latency and cost in multi-server scenarios.

[0049] Figure 4This is the workflow diagram of the weight update of the present invention. The specific impact of different request processing results on weight update. Regardless of whether the request is ultimately completed through a local hit, relay hit, delayed hit, or bypass strategy, the system will dynamically update the weight of the relevant file according to the processing method. If the request is responded to through a local hit, the local hit delay of the file is accumulated to its weight; if the local file acquisition operation is triggered, the acquisition delay is accumulated and the subsequent possible delayed hit time is superimposed. For relay hits or relay delay hits, the system accumulates the maximum value of the relay path delay or relay delay hit to the weight of the corresponding file. If the request is ultimately bypassed to the cloud, the delay and cost of the bypass operation will be included in the global weight calculation. Weight updates not only rely on historical statistics, but also combine future delay predictions (such as the square value of the file acquisition delay) to balance the contribution ratio of historical data and predicted values ​​through weight adjustment factors. In addition, the system periodically synchronizes the cache status and weight information of neighboring servers to ensure consistency in global resource allocation. This dynamic weight update mechanism can reflect the actual value of the file and changes in the network environment in real time, providing accurate decision-making basis for subsequent request processing, thereby continuously optimizing cache efficiency and service quality in multi-server edge computing scenarios.

Claims

1. A multi-service edge network cache optimization method based on delay hit, characterized in that: The following steps are involved: Step S1, local and relay judgment: Check in real time whether the requested file is cached on the local server. If it is, respond to the request directly and update the weight. If it is not, traverse the cache status of neighboring servers and select the optimal path whose relay path delay is less than the delay of re-acquiring the local file and less than the delay of waiting for the current file to be retrieved. When there are multiple relay paths, the path with the best overall performance is selected based on the number of hops, link congestion and path stability. Step S2, delay hit judgment: real-time tracking of the remaining completion time of the file being retrieved and calculation of the expected delay for waiting for the file cache to complete. If the waiting time is less than the delay of the relay or bypass operation, the request is marked as a delay hit and added to the high-priority queue. At the same time, a maximum waiting time threshold is set to avoid infinite waiting and service degradation. Timed-out requests automatically trigger relay or bypass operations to ensure service response reliability. Step S3, server selection and acquisition replacement strategy: prioritize servers with sufficient remaining cache capacity to execute file acquisition to reduce file replacement frequency. If the target server cache space is insufficient, create a server cache copy and insert the file to be cached to simulate weight changes. Iteratively eliminate files from low to high weights until the capacity constraint is met. If the file to be cached is not eliminated, trigger file acquisition and update the cache. Through the inter-server collaborative protocol, ensure that only one copy of the same file is cached within the preset hop count range. Step S4, bypass decision: When the delays of the local and relay paths and the acquisition strategy all exceed the service quality requirements, the cloud bypass operation is triggered. The cloud response time and bandwidth cost of the bypass operation are dynamically evaluated to select the operation path that meets the delay constraints and has the lowest resource consumption. The bypass triggering conditions are optimized through weight update and replacement strategies to adapt to the dynamic network environment. Step S5, weight update strategy: comprehensively calculate the file weight based on the file's historical request frequency, cumulative delay hit time, and cross-server relay path delay.

2. The multi-service edge network cache optimization method based on delay hit according to claim 1 is characterized in that: In step S1, it is preferred to check whether the requested file is cached in the local server. If it is, the request is directly responded to and the weight is updated. If it is not, the neighboring server set is traversed and S is set to the entire server set. is the set of edge servers within the range of the i-th user, is a set of other edge servers that are not in the range of the i-th user, and then calculates the local edge server and relay edge servers Relay delay , specifically: （1）， If f is already cached on the relay edge server On, and relay edge server If it is a non-local server, then the local edge server is calculated and relay edge servers The relay delay between them is σ, where σ is the delay time of each relay hop. From the local edge server To the Relay Edge Server The number of relay hops, so the local edge server and relay edge servers The relay delay is and The product of =1 means that file f has been cached on the server at time t.

3. The multi-service edge network cache optimization method based on delay hit according to claim 2 is characterized in that: In step S2, the specific method for calculating the delayed hit delay is as follows: Delay hit: Delay hit in multi-cache scenario includes local delay hit and relay delay hit, local edge server Delayed hit time on It is expressed as follows: （2）， in, Indicates the time when the file f was last triggered to obtain the operation, t indicates the current time, Indicates the length of each time slot, Indicates that file f is cached to the local edge server Therefore, the acquisition delay on Indicates the total time to obtain the file minus the time already obtained, that is, the remaining time required to delay the hit, where , is the time window for starting the file extraction operation, Is a decision variable, indicating whether to decide to obtain file f to the relay edge server at time T superior, Indicates the feasible time step for generating delay hit delay, specifically, the timestamp of generating delay hit delay Expressed as: （3）， The above formula (3) shows that Get f from f and make sure that the time interval between two requests for the same file f is less than Otherwise, f has been cached on the server or has been evicted by other files when the request arrives, so no delay hit will occur. However, in the relay case, it is still possible to trigger a delay hit, that is, if f is being obtained to the relay edge server , a relay edge server will appear Relay delay hit delay on , and because the relay and crawl processes are running simultaneously, Equal to the maximum of the relay delay and the relay delay hit delay, specifically: （4）， In determining After that, we still need to compare it with the relay delay, and finally get Specifically expressed as: （5）。 4. The multi-service edge network cache optimization method based on delay hit according to claim 3 is characterized in that: In step S3, if the current server does not have file f that meets the local, relay, or delayed hit requirements, it is necessary to consider obtaining the file f from the cloud or bypassing the request to the cloud. The specific steps are as follows: Step S31, first select a server with available cache space to obtain the file, if there is no such server, then select the weight Minimal local edge server To decide whether to extract the file, Indicates the local edge server Storage files in The weight of , where: （6）， Step S32: Create a local edge server A copy of Cache the requested file f in the copy and update the copy The cache size and weight of file f in; Step S33: Set η to represent the minimum weight per unit cache space. Then, iteratively reduce the weight η of all cached files and move files with negative weights to Fevict, where Fevict is the set of files to be deleted, until the cache size of all files in the replica is less than its maximum capacity, where: （7）， Represents a file The size of the cache space occupied; Step S34: If the requested file f is still in the replica, the file in Fevict is transferred from the local edge server to the local edge server. Delete it and get the file f from the cloud to the local edge server Otherwise, the file request is bypassed.

5. The multi-service edge network cache optimization method based on delay hit according to claim 4 is characterized in that: In step S4, if there is no file f in the current server that meets the requirements of local, relay or delayed hit, and the acquisition decision is rejected, the specific performance is as follows: The cached file f does not exist on the local server. , the cached file f does not exist on the relay server, , and neither exists ,and When , the weight replacement strategy is used to optimize the bypass trigger conditions to adapt to the dynamic network environment.

6. The multi-service edge network cache optimization method based on delay hit according to claim 5 is characterized in that: In step S5, the weight is composed of three parts: cumulative hit delay, cumulative acquisition and delayed hit delay, and future delay prediction. The cumulative hit delay statistics the total delay of direct hits of files on the local or relay server, the cumulative acquisition and delayed hit delay statistics the total delay of the acquisition operation triggered by cache misses and the subsequent waiting delay hit time, and the future delay prediction estimates the potential delay based on the square value of the file acquisition delay. The contribution ratio of historical statistics and predictions is balanced by the weight adjustment factor, which ranges from 0 to 1. The weight retention threshold is dynamically set according to the remaining cache capacity of the server to prioritize the elimination of low-weight files. At the same time, the cache status and weight information of neighboring servers are periodically synchronized to optimize global resource allocation. The specific method is as follows: The weight update process is divided into two modules: local module and relay module. The first is the local module. When the file requested by the user is cached locally, the local edge server that processes the request Cumulative hit delay on Plus file f cached to the local edge server The acquisition delay on , The file itself has its own attributes. If the file is not cached locally and the acquisition operation is triggered to select the file to be acquired locally, the local edge server will be Cumulative acquisition delay on Plus file f cached to edge server The acquisition delay on ,Since the delays caused by the two are different in actual situations, the hit will have almost no delay, so the cumulative hit delay and cumulative acquisition delay of the edge server are calculated separately. If there is a file in the server that has been triggered to be acquired in the past and has not yet been acquired, it is called a delayed hit. The delayed hit delay is calculated together with the acquisition delay, but the delay caused by it is lower than the delay caused by caching the file f to the local edge server. The acquisition delay on , through the local edge server Delayed hit time on Calculate its remaining delay hit time and add it to Then, based on the file, the local edge server Cumulative hit delay on , local edge server Cumulative acquisition delay on , combined with the upper bound of file bypass latency from the cloud , calculate the local file weight, specifically: （8）， Among them, the weight adjustment factor The value range is 0 to 1. When the local server does not cache the file, it can determine whether there is a file cache condition on the edge server around it. If so, and the relay delay to the edge server is less than the bypass delay, then it will be placed on the relay server to handle the same relay hit, and the relay edge server will be Cumulative hit delay on Add this file to the relay edge server The relay delay required by the relay is still likely to trigger a delay hit, so when the relay delay hits, the relay edge server Cumulative acquisition delay on Add local server to relay edge server Relay delay on and on relay edge servers The maximum value of the upper relay delay hit delay , and finally update the weight corresponding to the relay server file.

Images