Multi-service edge network cache optimization method based on delayed hit

Abstract

The invention discloses a multi-service edge network cache optimization method based on delayed hit, which belongs to the field of edge computing and online caching, and comprises the following steps: deciding an optimal request processing path by analyzing a local cache hit state, adjacent server cache distribution and relay path delay in real time; 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 a target server based on weight sorting, dynamically eliminating low-weight files, and reducing cache conflicts in combination with a cross-server redundancy elimination mechanism; when the local cache and the relay path do not meet the delay constraint, dynamically evaluating the cloud response time and bandwidth cost of the bypassing operation, and determining the feasibility of the bypassing operation; the file weight is dynamically calculated based on historical request characteristics and operation delay, the file replacement cost is quantified by combining the cache state and the residual capacity of the server, and the average retrieval delay of user requests can be greatly reduced.

Description

Technical Field

[0001] The present invention belongs to the fields of edge computing and online caching, and particularly relates to a multi-service edge network caching optimization method based on latency hit. Background Art

[0002] Mobile Edge Computing (MEC), as an emerging distributed computing paradigm, significantly reduces the data transmission distance and network latency by sinking 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, thus meeting the quality-of-service requirements of latency-sensitive applications. The core driving force of this technology comes from the strict requirements of scenarios such as the Internet of Things (IoT), autonomous driving, augmented reality (AR / VR), and industrial Internet of Things (IIoT) for millisecond-level response, high bandwidth, and data privacy protection. For example, in autonomous driving, vehicles need to process massive amounts of data from lidar, cameras, and sensors in real time, and any latency in cloud transmission may lead to decision-making errors; in AR / VR scenarios, the smoothness of user interaction highly depends on local rendering and low-latency content distribution. However, MEC faces multiple technical challenges during implementation: firstly, the resource constraints of edge servers, whose computing power, storage capacity, and energy supply are usually much lower than those of cloud data centers, making it difficult to directly migrate methods from traditional cloud computing; secondly, the complexity brought by the dynamic network environment, where user mobility, frequent changes in network topology, and bursty traffic require resource allocation strategies to be highly adaptable; thirdly, the problem of multi-server collaboration, and how to efficiently share data, synchronize cache states, and achieve task offloading between different edge nodes becomes the key to improving the overall system performance. In addition, MEC also needs to balance the contradiction between data localization and global optimization - although local processing can reduce latency, cross-node collaborative decision-making (such as multi-user request scheduling, distributed cache update) requires complex protocol support. These challenges have given rise to the deep integration of edge computing and caching technology, maximizing the utilization of limited resources in the edge network through intelligent resource management and real-time decision-making.

[0003] Online caching algorithms, as the core enabling technologies for edge computing, aim to dynamically manage cache content to minimize data access latency and reduce dependence on the cloud. Traditional caching algorithms (such as LRU, LFU, FIFO) perform well in cloud computing scenarios, mainly relying on the locality principle (temporal locality and spatial locality) or frequency statistics to optimize cache replacement policies. However, in the edge computing environment, these algorithms face fundamental limitations: Firstly, the prominent issue of latency hit - when a file is not cached locally and needs to be fetched from the cloud, if subsequent requests arrive before the file fetching is completed (i.e., the file is in transit), traditional algorithms cannot utilize the "about - to - be - cached" state, resulting in repeated triggering of fetch operations or passive waiting, accumulating additional latency (for example, LRU will directly replace the old file and fetch it again, ignoring the characteristic that the file in transit may be available soon). Secondly, the lack of multi - server cooperation - existing algorithms are mostly designed for single - server optimization and do not consider cross - server relay path selection, redundancy elimination, or load balancing. For example, when the local server does not cache a file, 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 increase in hops and link congestion. In addition, the problem of insufficient dynamic weight assignment is significant - traditional weight methods only rely on access frequency or recent access time, without considering real - time network status (such as link congestion, hop cost), future latency prediction (such as remaining time for file fetching), or cross - server resource distribution, leading to rigid decision - making in highly dynamic edge networks. For example, although LRU - MAD introduces latency hit statistics, its weight calculation does not quantify the path selection cost and cannot balance the global costs of local fetching, relay forwarding, and bypass operations in a multi - server scenario. More seriously, the redundancy and conflict problems in a multi - server scenario: the same file may be repeatedly cached at multiple neighboring nodes, not only wasting storage resources but also potentially causing version inconsistency or update conflicts (such as after a server updates a file, neighboring nodes still provide the old version). These limitations make it difficult for traditional algorithms to meet the requirements of edge computing for low latency, high reliability, and efficient resource utilization, and there is an urgent need for a new caching strategy that combines network topology awareness, dynamic weight fusion, and cross - node cooperation 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 latency hit. In complex scenarios with latency hit, cross - server relay, and cloud bypass, through dynamic weight update, multi - path collaborative decision - making, and competitive replacement mechanisms, it significantly reduces the total request latency and improves the cache hit rate.

[0005] To achieve the above - mentioned objectives, the technical solutions adopted by the present invention have 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 hits, directly respond to the request and update the weight. If it misses, traverse the cache status of neighboring servers, and filter out the optimal path whose relay path delay is less than the local re-acquisition file delay and less than the delay hit time of waiting for the currently acquired file to complete. When there are multiple relay paths, select the path with the optimal comprehensive performance by combining the number of hops, link congestion degree, and path stability, and preferentially reduce redundant hops to reduce transmission delay.

[0007] Step S2, Delay Hit Judgment: Track in real time the remaining completion time of the file being acquired and calculate the estimated delay of waiting for the file cache to complete. If the waiting time is less than the delay of the relay or bypass operation, mark the request as a delay hit and add it to the high-priority queue. At the same time, set the maximum waiting time threshold to avoid service degradation caused by infinite waiting. The timeout request automatically triggers the relay or bypass operation to ensure the reliability of service response.

[0008] Step S3, Server Selection and Acquisition Replacement Strategy: Preferentially select a server with sufficient remaining cache capacity to execute file acquisition to reduce the file replacement frequency. If the cache space of the target server is insufficient, create a server cache copy and insert the file to be cached to simulate the weight change. Iteratively eliminate files from low to high according to the weight until the capacity constraint is met. If the file to be cached is not eliminated, trigger file acquisition and update the cache. Ensure that only one copy of the same file is cached within the preset number of hops through the inter-server cooperation protocol to avoid resource waste.

[0009] Step S4, Bypass Decision: When the delays of both the local and relay paths and the acquisition strategy exceed the service quality requirements, trigger the cloud bypass operation. Dynamically evaluate the cloud response time and bandwidth cost of the bypass operation to select the operation path that meets the delay constraint and has the lowest resource consumption. Optimize the bypass trigger condition through weight update and replacement strategy to adapt to the dynamic network environment;

[0010] Step S5, Weight Update Strategy: Calculate the file weight comprehensively according to the historical request frequency of the file, the cumulative delay hit time, and the cross-server relay path delay.

[0011] Further, in the above step S1, first detect whether the requested file is cached on the local server. If it hits, directly respond to the request and update the weight. If it misses, traverse the set of neighboring servers. Let S be the entire server set, is the set of edge servers within the range of the i-th user, is the set of other edge servers not within the range of the i-th user. Then calculate the relay delay between the local edge server and the relay edge server , specifically:

[0012] (1),

[0013] If f has been cached in the relay edge server and the relay edge server is a non-local server, calculate the relay delay between the local edge server and the relay edge server where σ is the delay time per relay hop, is the number of relay hops from the local edge server to the relay edge server So the relay delay between the local edge server and the relay edge server is the product of and = 1 indicates that file f has been cached on the server at time t.

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

[0015] Delay hit: Delay hit in a multi-cache scenario includes local delay hit and relay delay hit. The delay hit time on the local edge server is expressed as follows:

[0016] (2),

[0017] where represents the time when file f was last triggered for a fetch operation, t represents the current time, represents the length of each time slot, represents the fetch latency when file f is cached on the local edge server So represents the total time of file fetching minus the time that has been fetched, that is, the remaining time that needs to be delay hit, where , is the time window for starting the file extraction operation, is a decision variable indicating whether to decide to fetch file f to the relay edge server at time T, and τ represents a feasible time step for generating the delay hit latency. Specifically, the time stamp for generating the delay hit latency is expressed as:

[0018] (3),

[0019] The above formula (3) shows that in ​Obtain f from it to ensure 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 there will be no delayed hit, while in the relay case, it is still possible to trigger a delayed hit situation, that is, if f is being fetched to the relay edge server , then there will be a relay edge server relay delay hit latency on , and since the relay and fetch processes can occur simultaneously, it is equal to the maximum of the relay delay and the relay delay hit latency, specifically:

[0020] (4),

[0021] After determining , it still needs to be compared with the relay delay, and finally obtain Specifically expressed as:

[0022] (5),

[0023] Furthermore, in step S3, if there is no file f that satisfies local, relay, or delayed hit in the current server, it is necessary to consider fetching it from the cloud to the local 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 fetch the file. If there is no such server, select the local edge server with the lowest weight to determine whether to extract the file. represents the weight of the stored file in the local edge server , where:

[0025] (6),

[0026] Step S32, create a copy of the server , and cache the requested file f into the copy, updating the cache size and weight of file f in the copy ;

[0027] Step S33, set η to represent the minimum weight per unit of cache space. Then, iteratively reduce the weights of all cached files by η, and move the 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 copy 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 edge server is the same as the relay delay hit. Cumulative acquisition delay on Add local server to relay edge server Relay delay on the relay edge server 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 beneficial effects of the present invention are:

[0039] (1)Based on the traditional single-edge cache, it is extended to multiple servers, that is, the requests sent by users are broadcast requests that can be received by all servers within the range, and the optimal processing strategy is judged.

[0040] (2)The delayed hit is added, so that the requests that originally needed to be retrieved or bypassed can be hit after a certain delay, greatly reducing the average retrieval delay of user requests. Description of the Drawings

[0041] Figure 1 It is the flowchart of the method in the embodiment of the present invention.

[0042] Figure 2 It is the flowchart of the operation of relay and delayed hit of the present invention.

[0043] Figure 3 It is the flowchart of the operation of obtaining or bypassing based on weights of the present invention.

[0044] Figure 4 It is the flowchart of the weight update of the present invention. Detailed Implementation Manner

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

[0046] Figure 1It is the method flowchart of an example of the present invention. When a user issues a request, the system first checks whether the request can be directly hit on the local server. If there is a cache of the required file locally, the request is immediately responded to and the relevant weights are updated to reflect the latest usage of the file. If there is no local hit, the system will turn to the relay judgment stage, traverse the cache status of neighboring servers, and filter out the relay path with a delay lower than the optimal path for the local to re-obtain the file or wait for the currently obtaining file to complete. During this process, the system comprehensively considers the number of hops, link congestion degree, and path stability, and preferentially selects the relay path with the fewest hops and the highest transmission efficiency to reduce the delay caused by redundant transmission. If there is a delay hit (i.e., the file is being obtained and the remaining completion time is short), the system will mark the request as high priority and dynamically evaluate the cost of waiting for the delay hit and triggering the relay or bypass operation to select the strategy with the least impact on the total delay. If the local, relay path, and delay hit cannot meet the service quality requirements, the system will enter the server selection and acquisition replacement stage. At this time, the server with sufficient remaining cache capacity is preferentially selected to execute the file acquisition to avoid performance losses caused by frequent file replacement. If the target server has insufficient space, the weight change is simulated by creating a cache copy, and the low-value files are gradually eliminated from low to high according to the weights until the capacity constraint is met. During this process, the system ensures that only one copy of the same file is retained within a preset range through the cross-server cooperation protocol to avoid resource waste. Finally, if all strategies cannot meet the delay constraint, the system will trigger the cloud bypass operation, dynamically evaluate the cloud response time and bandwidth cost, and select the optimal path. After each request processing ends, the system updates the file weights according to the processing results to provide a basis for dynamic optimization for subsequent decisions.

[0047] Figure 2It is the workflow diagram of relay and delayed hit in the present invention. For requests that have reached the local server, the system first determines whether the requested file is already 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 delayed hit judgment process, real-time tracks the remaining completion time of the file being obtained, and calculates the time window required to wait 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 delayed hit and added to the high-priority queue, and a maximum waiting threshold is set to prevent infinite waiting. If the conditions for delayed hit are not met, the system further traverses neighboring servers to filter out the optimal path that meets the relay conditions. During this process, the system simultaneously checks whether there is a relay delayed hit (i.e., the situation where the file is being obtained by a neighboring server), and calculates the maximum value of the relay path delay and the relay delayed hit. Subsequently, the system compares the delay values of the local delayed hit, the relay path, and the relay delayed hit, and selects the minimum value among the three as the final processing strategy. If all conditions are not met (i.e., no hit, no relay path, and no delayed hit), the system enters the weight-driven server selection or bypass strategy, and decides whether to obtain the file from the cloud or directly bypass the request by dynamically evaluating the server cache status and cache cost. The entire process always aims to reduce the total delay, and through multi-path collaboration and dynamic priority scheduling, ensures service reliability in complex scenarios.

[0048] Figure 3 It is the workflow diagram of weight-based acquisition or bypass in the present invention. It focuses on how to select a server or execute a bypass strategy based on weights in the case of no hit. When the local, relay, and delayed hits cannot meet the request, the system first checks whether there is a server with sufficient remaining cache space. If there is, the server is directly selected to perform the file acquisition operation to avoid introducing additional delay due to file replacement. If the space of all servers is insufficient, the server with the smallest comprehensive weight (i.e., the node with the lowest overall value of the cached file) is selected, its cache copy is created, and the file to be requested is added to the copy to simulate the weight change. Subsequently, the system gradually reduces the weights of all cached files in an iterative manner, subtracting the minimum unit weight each time (i.e., the ratio of the weight to the file size), and marking the file with a negative weight as pending deletion. This process continues until the copy capacity meets the constraint. If the file to be requested still remains in the copy after iteration, the file acquisition 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 preferentially retains high-value files under limited cache space through dynamic simulation of weight changes and a competitive replacement mechanism, avoiding unnecessary resource consumption. The entire process reflects the refined resource management driven by weights, ensuring the optimal balance between delay and cost in a multi-server scenario.

[0049] Figure 4This is the workflow diagram for the weight update of the present invention. The specific impact of different request processing results on weight update. Regardless of whether the request is finally completed through local hit, relay hit, latency hit or bypass strategy, the system will dynamically update the weights of relevant files according to the processing method. If the request is responded through local hit, the local hit latency of the file will be accumulated to its weight; if the local file acquisition operation is triggered, the acquisition latency will be accumulated and the subsequent possible latency hit time will be superimposed. For relay hit or relay latency hit, the system accumulates the maximum value of the relay path latency or relay latency hit to the weight of the corresponding file respectively. If the request finally bypasses to the cloud, the latency and cost of the bypass operation will be incorporated into the global weight calculation. The weight update not only depends on historical statistics, but also combines future latency prediction (such as the square value of file acquisition latency), and balances the contribution ratio of historical data and predicted value through a weight adjustment factor. In addition, the system periodically synchronizes the cache status and weight information of neighboring servers to ensure the consistency of global resource allocation. This dynamic weight update mechanism can reflect the actual value of files and network environment changes in real time, provide accurate decision-making basis for subsequent request processing, and thus continuously optimize the cache efficiency and service quality in the multi-server edge computing scenario.

Claims

1. A multi-service edge network cache optimization method based on delayed hit, characterized in that It includes the following steps: Step S1, local and relay judgment: Check in real time whether the requested file is cached in the local server. If it hits, directly respond to the request and update the weight; if it misses, traverse the cache status of neighboring servers, and screen the optimal path where the relay path delay is less than the local re-acquisition file delay and less than the delay hit time of waiting for the currently acquired file to complete. When there are multiple relay paths, select the path with the optimal comprehensive performance by combining the number of hops, link congestion degree, and path stability; Step S2, delay hit judgment: Track in real time the remaining completion time of the file being acquired and calculate the estimated delay of waiting for the file cache to complete. If the waiting time is less than the delay of the relay or bypass operation, mark the request as a delay hit and add it to the high-priority queue. At the same time, set the maximum waiting time threshold to avoid service degradation caused by infinite waiting. The timeout request automatically triggers the relay or bypass operation to ensure the reliability of service response; Step S3, server selection and acquisition replacement strategy: Give priority to selecting a server with sufficient remaining cache capacity to execute file acquisition to reduce the file replacement frequency. If the cache space of the target server is insufficient, create a server cache copy and insert the file to be cached to simulate the weight change, and iteratively 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. Ensure that only one copy of the same file is cached within the preset number of hops through the inter-server cooperation protocol; Step S4, bypass decision: When the delays of both the local and relay paths and the acquisition strategy exceed the service quality requirements, trigger the cloud bypass operation. Dynamically evaluate the cloud response time and bandwidth cost of the bypass operation to select the operation path that meets the delay constraint and has the lowest resource consumption. Optimize the bypass trigger condition through weight update and replacement strategy to adapt to the dynamic network environment; Step S5, weight update strategy: Comprehensively calculate the file weight according to the historical request frequency of the file, the cumulative delay hit time, and the cross-server relay path delay.

2. The multi-service edge network cache optimization method based on delayed hit according to claim 1, wherein In the step S1, it is preferred to detect whether the request file is cached in the local server. If a hit occurs, the request is directly responded to and the weight is updated. If no hit occurs, the set of neighboring servers is traversed, where S is set as the entire server set, is the set of edge servers within the range where the i-th user is located, is the set of other edge servers not within the range where the i-th user is located. Then, the local edge server and the relay edge server calculate the relay delay between them, specifically: （1）， If f has been cached in the relay edge server and the relay edge server is a non-local server, calculate the relay delay between the local edge server and the relay edge server where σ is the delay time per relay hop, is the number of relay hops from the local edge server to the relay edge server so the relay delay between the local edge server and the relay edge server is the product of and , = 1 indicates that the file f has been cached on the server at time t.

3. The multi-service edge network cache optimization method based on delayed hit according to claim 2, wherein In the said Step S2, the specific method for calculating the delay hit delay is as follows: Delayed Hit: In a multi-cache scenario, a delayed hit includes a local delayed hit and a relay delayed hit. The local edge server The delayed hit time on is expressed as follows: （2）， Among them, represents the time when the file f was last triggered to obtain an operation, t represents the current time, represents the length of each time slot, represents the acquisition delay when the file f is cached to the local edge server Therefore, represents the total time of file acquisition minus the time that has been acquired, that is, the remaining time that needs to be delayed for a hit, where , is the time window for starting the file extraction operation, is a decision variable indicating whether it is decided to obtain the file f on the relay edge server at time T above, represents the feasible time step for generating the delay hit delay. Specifically, the time stamp for generating the delay hit delay is 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）， After determining it still needs to be compared with the relay delay, and finally is specifically expressed as: （5）。 4. The multi-service edge network cache optimization method based on delayed hit according to claim 3, characterized in that, In the said Step S3, if there is no file f that meets the local, relay, or delay hit in the current server, it is necessary to consider acquiring it from the cloud to the local 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 copy of a local edge server and cache the requested file f into the copy, and update the cache size and weight of file f in the copy ; ​ Step S33, set η to represent the minimum weight per unit cache space. Then, iteratively reduce the weight η of all cached files, and move the files with negative weights to Fevict. Fevict is the set of files to be deleted until the cache size of all files in the copy is less than its maximum capacity, where: （7）， Indicates the file The size of the cache space occupied; Step S34, if the requested file f is still in the replica, delete the file in Fevict from the local edge server and obtain the file f from the cloud to the local edge server otherwise, bypass the file request.

5. The multi-service edge network cache optimization method based on delayed hit according to claim 4, wherein, In the said Step S4, if there is no file f that meets the local, relay, or delay hit in the current server and the acquisition decision is rejected, the specific manifestation is as follows: There is no cached file f on the local server, and there is no cached file f on the relay server, and neither exists and when this is the case, the trigger condition is optimized and bypassed through the weight replacement strategy to adapt to the dynamic network environment.

6. The multi-service edge network cache optimization method based on delayed hit according to claim 5, wherein In the step S5, the weight is composed of three parts: cumulative hit latency, cumulative acquisition and latency hit latency, and future latency prediction. Among them, the cumulative hit latency statistics the total direct hit latency of the file on the local or relay server; the cumulative acquisition and latency hit latency statistics the total latency triggered by cache misses for acquisition operations and the subsequent waiting latency hit time; the future latency prediction estimates the potential latency based on the square value of the file acquisition latency, and balances the contribution ratio of historical statistics and prediction through a weight adjustment factor. The value range of the weight adjustment factor is from 0 to 1. The weight retention threshold is dynamically set according to the remaining cache capacity of the server to preferentially eliminate files with low weights. At the same time, the cache status and weight information of neighboring servers are periodically synchronized to optimize the 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 latency bypassed from the cloud , calculate the local file weight, specifically: （8）， Among them, the weight adjustment factor has a value range of 0 to 1, When the local server does not have a cached file, it can be determined whether there is a situation where the edge server around it meets the file caching condition. If there is and the relay delay to this edge server is less than the bypass delay, then it is placed on the relay server to handle the same relay hit, and the relay edge server The cumulative hit delay on plus the relay delay required for this file to be relayed to the relay edge server on. And relay may still trigger a delay hit. Therefore, in the case of a relay delay hit, the relay edge server The cumulative acquisition delay on plus the relay delay from the local server to the relay edge server on and the maximum value of the relay delay hit delay on the relay edge server on , and finally update the weight corresponding to the relay server file.

Images