CN114500529A - A cloud-edge collaborative caching method and system based on perceived redundancy - Google Patents

Abstract

The invention discloses a cloud-edge collaborative caching method and system based on perceptible redundancy, and relates to the technical field of cloud-edge collaborative caching to solve the problems of low hit rate and long access delay in the existing cloud-edge collaborative caching method. The cloud-edge collaborative caching method performs the following operations in each cycle: based on the data access information of the previous cycle, using a cooperative edge data caching strategy based on perceived redundancy to selectively cache the data in the data set in multiple locations; edge server. After receiving a data access request, the cache space of each edge server is managed using a replacement strategy based on perceived redundancy. By designing a cooperative edge data caching strategy based on perceived redundancy and a replacement strategy based on perceived redundancy, we can balance the extra overhead of accessing edge servers and accessing cloud servers to obtain missing data, improve the space utilization of edge servers, and improve the system. hit rate and reduce data access latency.

Description

A cloud-edge collaborative caching method and system based on perceived redundancy

technical field

The present invention relates to the technical field of cloud-edge collaborative caching, in particular to a cloud-edge collaborative caching method and system based on perceived redundancy.

Background technique

Under the traditional centralized cloud architecture, when multiple users access the same content, the cloud data center needs to send the same data to each user, resulting in massive duplicate data in the network, resulting in network congestion. A natural idea is to enable caching on the edge side close to users, so that access requests for popular data are handled by the edge side as much as possible, thereby reducing the bandwidth pressure on cloud servers. In order to make up for the insufficiency of cloud architecture, the concept of edge computing came into being. In the edge computing mode, computing and storage capabilities can be moved down to edge servers close to users, so that the network edge also has data processing and data caching capabilities. Edge caching technology focuses on using edge servers to cache popular content in cloud data centers, thereby relieving the bandwidth pressure of cloud servers and reducing data access latency.

The management of edge cache needs to consider two aspects of cache placement strategy and cache replacement strategy. The main goal of the cache placement strategy is to balance access to edge collaboration domains and access to cloud servers. Compared with the data transmission overhead between edge servers, access to cloud servers will bring greater data transmission overhead. In order to reduce the load of the cloud server to the greatest extent, it is usually necessary to perform data deduplication operations on the edge servers in the cooperative cache domain. However, data deduplication can minimize the access to the cloud server, but also make a large number of data access requests unable to be responded by the local edge server. Considering the limited bandwidth resources of edge servers, the data transmission overhead between edge servers cannot be ignored, and the frequent transmission of popular data between edge servers will generate a large collaboration overhead and seriously affect the overall performance. Extreme deduplication can affect access performance, and edge storage systems require appropriate redundancy.

The research on the cache replacement strategy also has a long history. Considering different influencing factors, an appropriate cache replacement strategy can be designed to complete the cache content update operation. However, the above cache replacement algorithm is only applicable to the cache space management of a single server, and is not applicable to the cache space management of multi-edge servers in collaborative scenarios. The main reason is that when edge servers make cache replacement decisions independently, each edge server tends to keep the most popular content, and popular data is cached on almost all edge servers. In this case, the space utilization at the edge is greatly reduced, the system hit rate is reduced, and the data access delay is increased.

Therefore, there is an urgent need for a method and system that can effectively reduce the execution time and improve the cache hit rate.

SUMMARY OF THE INVENTION

The purpose of the present invention is to provide a cloud-edge collaborative caching method and system based on perceptible redundancy, and design a cooperative edge data caching strategy based on perceptible redundancy and a replacement strategy based on perceptible redundancy to balance access to edge servers. And the additional overhead of accessing cloud servers to obtain missing data, improve the space utilization of edge servers, improve the system hit rate, and reduce data access latency.

In order to achieve the above object, the present invention provides the following technical solutions:

A cloud-edge collaborative caching method based on perceived redundancy, the cloud-edge collaborative caching method comprising:

During each cycle, do the following:

Based on the data access information of the previous cycle, the data in the data set is selectively cached in a plurality of edge servers using a cooperative edge data caching strategy based on perceived redundancy; all the edge servers constitute a cooperative cache domain;

After the data access request is received, the cache space of each of the edge servers is managed using a replacement strategy based on perceived redundancy.

Compared with the prior art, the present invention provides a cloud-edge collaborative caching method based on perceptible redundancy. In each cycle, the following operations are performed: The cooperative edge data caching strategy of the data set selectively caches the data in the data set in multiple edge servers; all the edge servers constitute a cooperative caching domain, and after receiving a data access request, the replacement strategy based on perceived redundancy is used to The cache space of each of the edge servers is managed. By designing a cooperative edge data caching strategy based on perceived redundancy and a replacement strategy based on perceived redundancy, we can balance the extra overhead of accessing edge servers and accessing cloud servers to obtain missing data, improve the space utilization of edge servers, and improve the system. hit rate and reduce data access latency.

A cloud-edge collaborative caching system based on perceived redundancy, the cloud-edge collaborative caching system includes a cloud data center, an edge server cluster, and a controller; the cloud data center and the edge server cluster are both connected to the controller. communication connection; the edge server cluster is a cooperative cache domain composed of multiple edge servers; the cache space of each edge server is divided into a redundant area and an exclusive area;

The controller is configured to execute the above-mentioned cloud-edge collaborative caching method.

Compared with the prior art, the beneficial effects of the cloud-edge collaborative caching system provided by the present invention are the same as the beneficial effects of the cloud-edge collaborative caching method described in the above technical solutions, which will not be repeated here.

Description of drawings

The accompanying drawings described herein are used to provide a further understanding of the present invention and constitute a part of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention, and do not constitute an improper limitation of the present invention. In the attached image:

1 is a schematic structural diagram of a cloud-edge collaborative caching system provided by Embodiment 1 of the present invention;

FIG. 2 is a schematic diagram of the division of the edge server cache space provided by Embodiment 1 of the present invention;

3 is a schematic flowchart of a perceptible redundancy-based replacement strategy provided in Embodiment 1 of the present invention;

Fig. 4 is the popularity distribution diagram of the data used in the experiment provided by the embodiment of the present invention 1;

5 is a schematic diagram of performance performance of three cache placement strategies under two loads provided in Embodiment 1 of the present invention;

6 is a schematic diagram of performance performance of three cache replacement strategies under two loads provided in Embodiment 1 of the present invention;

FIG. 7 is a schematic flowchart of a cloud-edge collaborative caching method provided by Embodiment 2 of the present invention.

Detailed ways

In order to clearly describe the technical solutions of the embodiments of the present invention, in the embodiments of the present invention, words such as "exemplary" or "for example" are used to represent examples, illustrations, or illustrations. Any embodiment or design described herein as "exemplary" or "such as" should not be construed as preferred or advantageous over other embodiments or designs. Rather, use of words such as "exemplary" or "such as" is intended to present the related concepts in a specific manner.

Embodiment 1:

For infrastructure providers, edge caching technology can improve the utilization of edge storage resources and bring higher economic benefits; for application providers, edge caching technology can help them place application data at the edge. Minimize storage costs under the premise of given service quality requirements; for users, edge caching technology can optimize users' data access experience in the context of exponential growth in data volume. In view of this, edge caching technology has increasingly become the focus of researchers' attention. Edge caching technology is usually used to assist Content Delivery Network (CDN) for content caching. Compared with CDN servers, edge servers are closer to user equipment, and the deployment density is much higher than that of CDN servers. Therefore, enabling caching at the edge can meet the needs of massive The low-latency data access needs of the device. However, the storage resources of edge servers are far less than that of CDN servers, and fine-grained cache space management is required to meet the low-latency data access requirements of a large number of users.

The management of edge cache needs to consider two aspects of cache placement strategy and cache replacement strategy.

Considering that the more nodes participating in data deduplication, the higher the storage space utilization at the edge end, but the cooperation between the long-distance edge servers will generate a large network overhead, which will increase the data access delay. Some researchers have proposed an edge data deduplication (EF-dedup) strategy, which divides several edge servers into disjoint rings, performs distributed deduplication for each ring, and sets the optimal number of nodes in the ring. It is used to weigh storage overhead and network overhead; some researchers consider the huge difference in popularity of hot and cold data, and combine popularity-based hot data caching with data deduplication based on maximizing space utilization to minimize cloud storage. Frequency of server access. Although data deduplication can minimize the access to the cloud server, it will also make a large number of data access requests unable to be responded by the local edge server. Considering the limited bandwidth resources of edge servers, the data transmission overhead between edge servers cannot be ignored. The frequent transmission of popular data between edge servers will result in a large collaboration overhead, which will seriously affect the overall performance.

Classic cache replacement strategies, such as Least Recently Used (LRU) and Least Frequently Used (LFU), update cache content by considering data access interval, data access frequency and other factors respectively; ARC introduces ghost cache by introducing To comprehensively consider the data access time interval and data access frequency, so as to update the cache content; GDS (Greedy Dual Size) introduces the factor of data acquisition cost to update the cache content; GDS-LF expands the priority of GDS on the basis of GDS The high-level computing function realizes the purpose of multi-cost perception; Qaca considers the impact of IO request arrival rate, and realizes fairness guarantee for multiple users in the scenario of shared cache; MPC sorts data according to data popularity, and when new data arrives Eliminate the data with the lowest popularity; considering that the rate of adding new content is high, and most of the content only receives a few access requests, the addition of such temporary content will lead to the pollution of the cache space, so some researchers propose that based on the data access interval A cache replacement strategy that predicts short-term popularity to reduce cache update frequency. However, the existing cache replacement algorithm is only suitable for the cache space management of a single server, and is not suitable for the cache space management of multiple edge servers in a collaborative scenario. The main reason is that when edge servers make cache replacement decisions independently, each edge server tends to keep the most popular content, and popular data is cached on almost all edge servers. In this case, the space utilization at the edge is greatly reduced, the system hit rate is reduced, and the data access delay is increased.

In view of the defects of the prior art, this embodiment is used to provide a cloud-edge collaborative caching system based on perceived redundancy, which ensures space utilization by limiting the maximum available cache space for redundant data. As shown in Figure 1, the cloud-edge collaborative caching system includes a cloud data center, an edge server cluster and a controller, and both the cloud data center and the edge server cluster are connected in communication with the controller. In an edge caching system, a terminal device first requests data from the local edge server closest to it, and the edge server provides caching services for terminal devices within its coverage. The caching system is composed of multiple edge servers and cloud data centers that cooperate with each other. . Each edge server can be used to cache popular data, multiple edge servers form a cooperative cache domain, and cache content can be shared among edge servers. If the requested data is not cached in any edge server, you need to visit the cloud data center to add the missing data to the edge server.

The cloud data center is a new type of data center based on cloud computing architecture. The cloud data center physically gathers a large number of servers, is the logical center of the network, and provides the source of services. An edge server cluster is a cooperative cache domain composed of multiple edge servers, and the cache space of each edge server is divided into a redundant area and an exclusive area. The redundant area caches some data with the highest popularity, and access requests for popular data can be directly responded by the local edge server as much as possible, reducing the frequency of data transmission between edge servers; the exclusive area is used to cache data content that is not cached by other edge servers , so as to ensure the overall space utilization efficiency, and in order to make the data access performance of each edge server similar, the data is evenly cached according to the popularity ranking in the exclusive area of each edge server.

The controller is configured to execute the cloud-edge collaborative caching method described in Embodiment 2. The controller acts as a hub for collaborative caching between cloud data centers and edge servers, including access information collection module, caching revenue prediction module, edge data caching module, request processing module and cloud service access module.

The access information collection module is used to count relevant information when processing data access requests, such as the access times of data objects in each edge server, the hit situation of data access requests, data access delays, etc., to obtain data access information. The delay (ie data access delay) generated in the data access process is mainly composed of the following three parts: the data download delay L _down caused by the user accessing the local edge server, the data transmission delay L _edge between the edge servers, and the data transmission caused by accessing the cloud server. Delay L _cloud , where L _down < L _edge < L _cloud .

The cache revenue prediction module is used to calculate the global popularity, local access preference, access frequency, cache revenue and cache revenue threshold based on the historical data access information of the previous cycle and the data access information of real-time statistics, so as to adjust the cache policy.

The specific calculation method is as follows:

假设第j个数据d_j的出现 频率符合Zipf分布，则第j个数据的全局数据流行度P_j的计算公式如下：Suppose the data set is sorted in descending order of access frequency as

Assuming that the occurrence frequency of the _jth data dj conforms to the Zipf distribution, the calculation formula of the global data popularity Pj of the _jth data is as follows:

In formula (1), α is the Zipf distribution index.

的计算公式如下：The local access preference of the jth data to the ith edge server

The calculation formula is as follows:

为上一周期内，第i个边缘服务器n_i的服务范围内，数据d_j的累计请求量；

In formula (2),

is the cumulative request amount of data d _j within the service range of the i-th edge server n _i in the previous cycle;

的计算公式为：Access frequency of data d _j in edge server n _i

The calculation formula is:

则 缓存收益的计算公式如下：Use the access probability of unit byte to represent the cache revenue of data d _j being cached in edge server n _i

The calculation formula of cache revenue is as follows:

In formula (4), s _j is the data size of the data.

The calculation formula of the cache revenue threshold pt _i of the edge server n _i is as follows:

为边缘服务器n_i中缓存收益最低的数据d_min的缓存收益；N_n为边缘服务器的总个数。In formula (5),

is the cache revenue of the data d _min with the lowest cache revenue in the edge server n _i ; N _n is the total number of edge servers.

则将数据d_j缓存于n_i的收 益大于成本的临界条件为：

If data _dj has been cached in several nodes M in the cooperative cache domain, and

Then the critical condition that the benefit of caching data d _j in _ni is greater than the cost is:

The edge data cache module is used to perform cache placement operations using a cooperative edge data cache strategy based on perceived redundancy. Specifically, a cache placement plan is formulated based on information such as the cache capacity, network status, and data cache revenue of the edge server, and the popular data is actively cached. to the edge server to optimize the data access experience on the user side. Redundancy-aware cooperative edge data caching strategy, also known as RCEDC (Redundancy-aware Cooperative Edge Data Caching), which caches popular data on edge servers based on greedy strategy to avoid directly solving hybrid shaping nonlinear programming problems. and selectively cache part of the data in multiple edge servers to balance the additional cost of accessing the edge server to obtain the missing data and the additional cost of accessing the cloud server to obtain the missing data.

The RCEDC algorithm includes the following steps:

(1) Simplify the edge data caching problem into a linear programming problem to solve the initial caching scheme, determine the proportion of redundant data, and determine the popularity ranking of the data objects with the lowest caching benefit in the edge server.

表示边缘服务器，

表示各个边缘服务器的缓存容量 (Cache Capacity)，其中，N_n表示边缘服务器的总个数。

表示数据访问过 程中涉及的数据对象(Data)，

表示数据大小(Size)。use

represents an edge server,

represents the cache capacity (Cache Capacity) of each edge server, where N _n represents the total number of edge servers.

Represents the data objects (Data) involved in the data access process,

Indicates the data size (Size).

In order to solve the appropriate redundant data ratio, RCEDC reduces the edge data caching problem to a linear programming problem:

minL(N _r )

Among them, N _r is the amount of data that can be cached in the redundant area, N _s is the amount of data that can be cached in the exclusive area, and L(N _r ) is expressed as:

(2) Using the greedy algorithm, the data is arranged in descending order of cache revenue, and the uncached data is added to the edge server in turn, and the data with higher cache revenue is cached first.

存在差异， 按照d_j的局部访问偏好对边缘服务器进行降序排列，得到有序的边缘服务器集合

优先将数据添加到局部访问热度最高的边缘服务器即

若

剩余缓存空间大于数据对象的数据大小s_j，则将d_j缓存于

若数据缓存成功，则进入步 骤(4)，反之选择缓存收益次优的边缘服务器进行缓存。(3) Due to the different access heat of data d _j in different edge servers _ni , that is, local access preference

There are differences, and the edge servers are sorted in descending order according to the local access preferences of d _j to obtain an ordered set of edge servers

Priority is given to adding data to the edge server with the highest local access, i.e.

like

If the remaining cache space is greater than the data size s _j of the data object, then cache d _j in

If the data is cached successfully, go to step (4), otherwise select the edge server with the next best cache revenue for caching.

若数据缓存收益

大于缓存收益阈值pt_m，且

剩余缓存容量大于数据对象大小s_j则进行数据缓存，随后选择下一个边缘服务 器尝试进行数据缓存。(4) Traverse the remaining edge servers

If data caching benefits

is greater than the cache revenue threshold pt _m , and

If the remaining cache capacity is greater than the data object size _sj , data caching is performed, and then the next edge server is selected to attempt data caching.

The request processing module is used to perform a cache replacement operation using a replacement strategy based on perceived redundancy. Specifically, when a data access request arrives, it sequentially retrieves the local edge server, adjacent edge servers in the cooperative cache domain, and cloud data centers to obtain data. If the data access request is not hit, the missing data needs to be added to the local edge server. At this time, if the remaining cache space is insufficient, the data with the lowest cache benefit needs to be eliminated from the cached data.

The request processing module adopts a partitioned cache-oriented replacement strategy based on perceived redundancy, called RPCRS (Redundancy-aware Partitioned Cache Replacement Strategy). In order to perceive the data redundancy state, the strategy divides the cached data in the edge server according to the source of acquisition. There are two types: one is the data obtained by the cloud data center (exclusive data), which is only cached in a single edge server; the other is the data obtained from adjacent edge servers (redundant data), which is Class data has been cached on adjacent edge servers. As shown in Figure 2, the RPCRS strategy divides the cache space of each edge server into two regions, C1 and C2. Among them, the C1 area is used to cache the data content that is not cached by adjacent nodes, and can only cache exclusive data; while the C2 area caches popular data according to the local access heat of the edge server, which can cache both exclusive data and redundant data. According to the data access load in each node, the proportion of redundant data and exclusive data can be adjusted adaptively to optimize data access performance.

The data addition process of the RPCRS strategy has the following process: when the exclusive data enters the cache for the first time, it is added to the C1 area. When the cache space in the C1 area is insufficient, the data with the lowest priority is demoted to the C2 area, and competes with the redundant data for the cache space. When the exclusive data is located in the C2 area, if it is hit again, it will be upgraded to the C1 area; the redundant data is added to the C2 area when it enters the cache for the first time, and can only be located in the C2 area regardless of whether it is hit or not. The maximum available cache space for redundant data is limited by the cache capacity of the C2 area, but because the C2 area includes redundant data and exclusive data downgraded from the C1 area, the two compete for the cache space of the C2 area. Therefore, the cache space actually used by redundant data is based on the cache capacity of the C2 area as the upper bound, and the space ratio can be adjusted adaptively according to the actual access situation.

The RPCRS strategy calculates the priority of data in the C1 and C2 regions in the edge server. The process is as follows:

Calculate the real-time access frequency of data d _j

表示当前周期开始时刻t₀至当前时刻t_cur，边缘服务器n_i内数据d_j的累 计访问次数；

则表示t₀至t_cur时间范围内，边缘服务器n_i内所有缓存数据的累 计访问次数之和。In formula (8),

represents the cumulative access times of the data d _j in the edge server n _i from the start time t ₀ of the current cycle to the current time t _cur ;

It represents the sum of the cumulative access times of all cached data in edge server n _i in the time range from t ₀ to t _cur .

Use exponentially weighted moving average f _i ^j to represent data access frequency:

In formula (9), α represents a weighting factor, which is a decimal between 0 and 1.

为：Cache priority of data d _j in the C1 region of edge server n _i

for:

为：The priority of data d _j in the C2 region of edge server n _i

for:

Weight is the weight. Since eviction of exclusive data has greater overhead, it is assumed that:

FIG. 3 is a flowchart of cache content update under RPCRS. When processing a data access request, check whether the C1 area and C2 area of the local edge server and the cache space of the adjacent edge server contain the requested data in turn. According to the hit situation of the data access request, it can be divided into the following situations:

(1) Hit the request data in the C1 area of the local edge server. At this time, no new data is added, only the cache priority of the accessed data needs to be updated;

(2) Hit the request data in the C2 area of the local edge server. At this time, it needs to be processed according to the data type: If the hit data is exclusive data, because the exclusive data is not cached in the adjacent edge server and is hit again in a short period of time, the data is upgraded to the C1 area. If the C1 area remains If the cache space is insufficient, the data with the lowest priority in the C1 area is eliminated to free up enough cache space; if the hit data is redundant data, only the priority of the target data needs to be updated to avoid redundant data preempting the cache space in the C1 area. So as to limit the maximum available cache space for redundant data;

(3) Hit the request data on the adjacent edge server side. At this time, it is necessary to access the adjacent edge server to add the missing data locally, and modify its data type to redundant data, and then add the data to the C2 area. If the remaining cache space in the C2 area is insufficient, the data with the lowest priority in the C2 area will be eliminated, and then the data will be cached, and its data popularity will be initialized for the new data;

(4) Failed to hit the requested data in the cooperative cache domain. In this case, you need to access the cloud server to obtain the missing data, change the data type to exclusive data, and then add the data to the C1 area. If the remaining cache space in the C1 area is not enough to cache new data, the data with lower priority will be demoted to the C2 area to free up the C1 area cache space. When exclusive data is demoted, its cache priority is updated, and it competes with redundant data for C2 area cache space. Although exclusive data has a higher priority weight than redundant data, it has an advantage in competing for cache space, but if the exclusive data has not been accessed for a long time, along with the update of the cache content, the exclusive data with lower access frequency will be deleted. eliminated in time.

Based on the above replacement strategy, the cache space actually occupied by redundant data is upper bounded by the cache capacity of the C2 area, and the actual space ratio can be dynamically adjusted according to the data access load. Therefore, each edge server can adaptively adjust the space ratio of the two types of data according to the actual access load, and further optimize the data access performance under different access loads.

The cloud service access module is used to call the cloud service access module to access the cloud data center to obtain missing data when the requested data is not cached in the collaborative cache domain, and add the data to the local edge server.

Compared with the existing solution, this embodiment divides data into redundant data and exclusive data according to whether the data is cached in multiple edge servers, and limits the maximum available cache space of redundant data, thereby improving space utilization. In general, in order to solve the problems related to edge storage in the current distributed storage field, this embodiment takes the redundant-perceived cooperative edge data caching strategy RCEDC and the partition-oriented cache-oriented replacement strategy RPCRS based on perceptible redundancy as the core. , and established a cloud-edge collaborative caching system.

In the existing solutions in the past, on the one hand, the strategy of attaching importance to the cache hit rate and increasing redundant data as much as possible will lead to low space utilization and serious shortage of edge cache server storage resources; on the other hand, it is hoped that it is possible to improve edge collaboration capabilities , the strategy of not setting redundant cache will lead to frequent access to the cloud and greatly increase the access delay. It can be proved in experiments that the cloud-edge collaborative caching system provided by this embodiment can adapt to the current network environment, effectively reduce the execution time and improve the cache hit rate. The effectiveness of this embodiment is proved by the following experiments:

The experiments used an edge computing simulator called SimEdgeIntel. In this embodiment, the test experiment is carried out in the Linux environment, and the server is configured with 2 Intel Xeon E5-2620 CPUs and 128 GB of memory; the software used and its version numbers are shown in Table 1.

Table 1 Software Versions

The experimental load selected 1 million anonymous data access requests to the top ten websites in the United States in 2016 (hereinafter referred to as cdn-request-18), which has been used in many research works. The popularity distribution of data objects under this load is shown in Figure 4. The load contains about 450,000 accessed data objects, among which data access requests are concentrated on a small number of popular data, while the content popularity of data ranked after 1,000 tends to 0, that is, most of the data exists only a few times The accessed cold data conforms to the popularity characteristics of Zipf distributed data. Using the Zipf distribution to fit the data popularity distribution curve, the Zipf distribution index is 0.74. Based on the fitting results, 2 million data access requests are generated as a synthetic payload (hereinafter referred to as zipf-0.74). The experimental loads used are shown in Table 2:

Table 2 Experimental load

The experimental parameters are shown in Table 3. The data transmission delay between edge servers is set to 20ms, and the access delay of cloud server is 200ms. In order to study the impact of cache capacity on system performance, the cache capacity is set to be 1% to 10% of the total data; in order to study the impact of the number of edge servers on system performance, the number of edge servers is set to be 2 to 6; in order to study the effect of edge network status on the system performance Due to the impact of system performance, the data transmission delay between edge servers is set to vary from 20ms to 80ms.

Table 3 Experimental parameter table

In order to evaluate the cache policy performance, the following describes the performance evaluation indicators:

1. Cache hit rate: the ratio of the number of user request hits to the total number of requests. A request hit means that a data access request can be processed by the local edge server or an adjacent edge server;

2. Average delay: the ratio of the total data access delay to the total number of requests, the average delay is an important indicator that the user can intuitively feel, and is also the primary target of the optimization of the present invention;

3. Offload traffic: the total data traffic processed by the edge. An important role of edge caching technology is to process users' access requests for popular data at the edge to solve the bandwidth bottleneck under the cloud architecture. Therefore, in the existing research work, offload traffic is often used as an evaluation index for edge caching strategies;

4. Execution time: Considering that the RCEDC strategy proposed in this embodiment aims to obtain a cache placement scheme within a limited time, the execution time of each algorithm is compared in the cache placement strategy experiment.

The following uses SimEdgeIntel's built-in cache placement strategy Greedy, distributed cooperative caching strategy (hereinafter referred to as Contrast) and the redundancy-aware cooperative edge data caching strategy RCEDC proposed in this paper for comparative experiments. Among them, Greedy aims to maximize the total cache revenue of the cooperative cache domain, and places the data with the highest cache revenue on each edge server side to maximize the total revenue of the edge cached data. Compare the hit rate, average latency, offload traffic, and execution time under the three cache placement strategies. Set the edge server cache capacity C=0.75GB, the number of edge servers N _n =3, and the data transmission delay between edge servers L _edge =20ms. Experiments were carried out under two loads of cdn-request-18 and zipf-0.74, respectively, and the experimental results are shown in Figure 5.

As shown in Figure 5(a) and Figure 5(b), Figure 5(a) is a comparison chart of hit ratio under cdn-request-18 load, and Figure 5(b) is a comparison chart of hit ratio under zipf-0.74 load . Contrast and RCEDC have similar hit rates and much higher than Greedy under both loads, while Contrast and RCEDC have an average hit rate difference of up to 0.3%.

As shown in Figure 5(c) and Figure 5(d), Figure 5(c) is a comparison chart of unloaded traffic under cdn-request-18 load, and Figure 5(d) is a comparison chart of unloaded traffic under zipf-0.74 load . Under the two loads, the offload traffic of Contrast and RCEDC is similar and much higher than that of Greedy, while under the zipf-0.74 load, the offload traffic is further improved due to the doubling of the number of requests.

As shown in Figure 5(e) and Figure 5(f), Figure 5(e) is the average delay comparison chart under cdn-request-18 load, and Figure 5(f) is the average delay comparison chart under zipf-0.74 load . Under cdn-request-18 load, RCEDC reduces the average delay by 5.64% and 16.00% compared to Contrast and Greedy, respectively, and under zipf-0.74 load, RCEDC reduces the average delay compared to Contrast and Greedy, respectively 5.63% and 14.43%.

As shown in Figure 5(g) and Figure 5(h), Figure 5(g) is a comparison chart of execution time under cdn-request-18 load, and Figure 5(h) is a comparison chart of execution time under zipf-0.74 load . Under both loads, the execution time of RCEDC is similar to that of Greedy and lower than that of Contrast. Under the cdn-request-18 load, the execution time of RCEDC is reduced by 81.46% compared to Contrast.

The above experimental results show that compared with Contrast, RCEDC can significantly reduce the average delay and greatly shorten the algorithm execution time; compared with Greedy, RCEDC has significant improvements in hit rate, offload traffic and average delay. That is, RCEDC can get closer to the optimal cache placement scheme in a limited time.

Next, we use LRU, GDS-LF and RPCRS to conduct comparative experiments. Among them, the LRU updates the cache content based on the data access time interval. First, compare the hit rate, average delay, and offload traffic under the three cache replacement strategies. The configuration and load used are the same as the previous ones. The experimental results are shown in Figure 6.

As shown in Figure 6(a) and Figure 6(b), Figure 6(a) is a comparison chart of hit ratio under cdn-request-18 load, and Figure 6(b) is a comparison chart of hit ratio under zipf-0.74 load . In terms of hit rate, RPCRS outperforms LRU and GDS-LF. Under the load of cdn-request-18, compared with GDS-LF and LRU, the hit rate of RPCRS is increased by 18.85% and 25.20%, respectively, and the three cache strategies all have higher hit rate under the load of zipf-0.74.

As shown in Figure 6(c) and Figure 6(d), Figure 6(c) is a comparison chart of unloaded traffic under cdn-request-18 load, and Figure 6(d) is a comparison chart of unloaded traffic under zipf-0.74 load . On offloading traffic, RPCRS outperforms LRU and GDS-LF. Under the load of cdn-request-18, compared with GDS-LF and LRU, the offload traffic of RPCRS is increased by 66.11% and 88.11% respectively, and the three cache strategies further improve the offload traffic under the load of zipf-0.74.

As shown in Figure 6(e) and Figure 6(f), Figure 6(e) is the average delay comparison chart under cdn-request-18 load, and Figure 6(f) is the average delay comparison chart under zipf-0.74 load . In terms of average latency, RPCRS outperforms LRU and GDS-LF. Under the load of cdn-request-18, the average delay of RPCRS is reduced by 12.70% and 15.97%, respectively, compared with GDS-LF and LRU, and the average delay of the three caching strategies is further reduced under the load of zipf-0.74.

Analyze the performance of the three cache replacement strategies in terms of hit rate and offload traffic. The RPCRS cache strategy partitions and caches data according to whether it is cached in multiple edge servers. By limiting the maximum available cache space for redundant data, the data in the collaborative cache domain is redundant. The margin is significantly reduced, so compared with the other two cache replacement strategies, RPCRS can significantly improve the cache hit rate. At this time, because more data access requests can be processed in the cooperative cache domain, the offload traffic under the RPCRS caching strategy is also much higher than that of LRU and GDS-LF. Then analyze the performance of the three cache replacement strategies on the average delay. Since there are a large number of large objects that are only accessed once during the data access process, the cache of this part of the data will cause a large number of popular data to be expelled from the cache, which will be serious when the cache space is small. Affects total data access latency. The RPCRS and GDS-LF caching strategies take into account the impact of data size on system performance. Unpopular large objects can be quickly removed from the cache with limited impact on system performance. However, LRU fails to take into account the difference in data size and the frequency of data access, so it cannot avoid the pollution of cache space caused by unpopular large objects.

Compared with GDS-LF, RPCRS improves edge space utilization and reduces access to cloud servers by limiting the amount of redundant data; on the other hand, it caches popular data in redundant areas of each edge server, making most data Access requests can be handled by local edge servers, reducing the frequency of data transmission between edge servers. Therefore, compared to GDS-LF, RPCRS can further reduce the average delay.

The above compares the performance of RCEDC, RPCRS and the latest research work on hit rate, average latency, offload traffic and runtime respectively. The experimental results show that RCEDC can reduce the average delay by up to 25.40% and the execution time by up to 81.46%; RPCRS can improve the cache hit rate by up to 29.15% and the average delay by up to 16.80%.

Example 2:

The present embodiment is used to provide a cloud-edge collaborative caching method based on perceived redundancy, and works based on the cloud-edge system caching system described in Embodiment 1. As shown in Figure 7, the cloud-edge collaborative caching method includes:

During each cycle, do the following:

S1: Based on the data access information of the previous cycle, the data in the data set is selectively cached in multiple edge servers using a cooperative edge data caching strategy based on perceived redundancy; all the edge servers form a cooperative cache domain;

S1 can include:

(1) Calculate the cache condition based on the data access information of the previous cycle; the cache condition includes the local access preference of each data in the data set to each edge server, the cache revenue of each data cached in each edge server, and The cache revenue threshold of each edge server; the data access information includes the access frequency of each data, the cumulative request volume and data access delay of each data within the service scope of each edge server;

Specifically, the acquisition of data access information is implemented by the access information collection module, and the calculation of cache conditions according to the data access information is implemented by the cache revenue prediction module.

More specifically, the cache conditions calculated based on the data access information of the previous cycle include:

1) For each data, according to the cumulative request amount of the data within the service range of each edge server, the local access preference of the data to each edge server is calculated by using the formula (2) in Embodiment 1, and each data set in the data set is obtained. The local access preference of a data to each edge server.

2) Based on the access frequency of the data, the global data popularity of the data is calculated using the formula (1) in Embodiment 1; the data is cached at each edge according to the global data popularity and the local access preference of the data to each edge server. Cache revenue in the server, get the cache revenue of each data cached in each edge server.

For each edge server, the global data popularity and the local access preference of the data to the edge server are summed, and the access frequency of the data in the edge server is obtained by using the formula (3) in Embodiment 1. According to the access frequency of the data in the edge server and the data size of the data, the formula (4) in Embodiment 1 is used to calculate the cache revenue of the data being cached in the edge server.

3) Determine the minimum value of the cache revenue corresponding to each edge server according to the cache revenue of each data cached in each edge server, and calculate each Cache revenue threshold for an edge server.

(2) Arrange the data in the data set in descending order according to the cache revenue, and selectively cache the data in multiple edge servers in sequence based on the cache conditions.

Specifically, sequentially selectively caching data in multiple edge servers based on caching conditions may include:

1) Select the first data as the data to be cached;

2) Arrange all edge servers in descending order according to the local access preference of each edge server according to the data to be cached to obtain an ordered set of edge servers; and select the first edge server in the set of edge servers as the edge server to be stored;

3) Determine whether the remaining cache space of the edge server to be stored is larger than the data size of the data to be cached, and obtain a first judgment result;

4) if the first judgment result is no, then select the next edge server in the edge server set as the edge server to be stored, and return the step of "judging whether the remaining cache space of the edge server to be stored is greater than the data size of the data to be cached";

5) If the first judgment result is yes, cache the data to be cached on the edge server to be stored, and at the same time cache the data to be cached on edge servers other than the edge server to be stored and meet the preset conditions; the preset The condition is that the cache revenue of the data to be cached in the edge server is greater than the cache revenue threshold of the edge server and the remaining cache space of the edge server is greater than the data size of the data to be cached;

6) Determine whether the data in the data set has been cached;

7) If not, select the next data after the data to be cached as the data to be cached, and return to the step of "arranging all edge servers in descending order according to the local access preference of each edge server according to the data to be cached".

S2: After receiving the data access request, use a replacement strategy based on perceived redundancy to manage the cache space of each of the edge servers.

S2 can include:

(1) After receiving the data access request, determine whether the target data requested by the data access request is located in the exclusive area of the local edge server, and obtain a second judgment result; the local edge server is the edge covering the terminal that issued the data access request. server; the cache space of each edge server is divided into an exclusive area and a redundant area; the exclusive area is used to cache the exclusive data not cached by the remaining edge servers; the redundant area is used to cache the exclusive data and the remaining edge servers Also cached redundant data;

(2) if the second judgment result is yes, then update the priority of the target data;

(3) if the second judgment result is no, then judge whether the target data is located in the redundant area of the local edge server, and obtain the third judgment result;

(4) if the third judgment result is yes, then judge whether the target data is exclusive data; if so, then the target data is upgraded and cached to the exclusive area; if not, then the priority of the target data is updated;

Upgrading the cache of the target data to the exclusive area may include: judging whether the remaining cache space of the exclusive area is larger than the data size of the target data; if so, upgrading the cache of the target data to the exclusive area; if not, removing the one with the lowest priority in the exclusive area Exclusive data, and return to the step of "judging whether the remaining cache space of the exclusive area is larger than the data size of the target data".

(5) if the 3rd judgment result is no, then judge whether the target data is located in the adjacent edge server, obtain the 4th judgment result; The adjacent edge server is the remaining edge servers except the local edge server;

(6) if the 4th judgment result is yes, then visit adjacent edge server, to add target data as redundant data to the redundant area of local edge server;

Adding the target data as redundant data to the redundant area of the local edge server may include: judging whether the remaining cache space of the redundant area is larger than the data size of the target data; if so, caching the target data in the redundant area; if not, Then remove the data with the lowest priority in the redundant area, and return to the step of "judging whether the remaining cache space of the redundant area is larger than the data size of the target data".

(7) If the fourth judgment result is no, access the cloud data center to add the target data as exclusive data to the exclusive area of the local edge server.

Although the invention is described herein in conjunction with various embodiments, those skilled in the art can understand and implement the disclosure by reviewing the drawings, the disclosure, and the appended claims in practicing the claimed invention. Other variations of the embodiment. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that these measures cannot be combined to advantage.

Although the invention has been described in conjunction with specific features and embodiments thereof, it will be apparent that various modifications and combinations can be made therein without departing from the spirit and scope of the invention. Accordingly, this specification and drawings are merely illustrative of the invention as defined by the appended claims, and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the invention. It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit and scope of the invention. Thus, provided that these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims (10)

1. A cloud edge cooperative caching method based on perceptual redundancy is characterized by comprising the following steps:

in each cycle, the following operations are performed:

selectively caching data in the data set in a plurality of edge servers by utilizing a cooperative edge data caching strategy based on the perceptible redundancy based on the data access information of the previous period; all the edge servers form a cooperative cache domain;

and after receiving the data access request, managing the cache space of each edge server by using a replacement strategy based on perceptible redundancy.

2. The cloud-edge cooperative caching method according to claim 1, wherein the selectively caching data in the data set in a plurality of edge servers by using a cooperative edge data caching policy based on perceptual redundancy based on the data access information of the previous cycle specifically comprises:

calculating a cache condition based on the data access information of the previous period; the caching condition comprises local access preference of each data in the data set to each edge server, caching income of each data cached in each edge server and caching income threshold of each edge server; the data access information comprises the access frequency of each data, the accumulated request quantity of each data in the service range of each edge server and the data access delay;

and performing descending order arrangement on the data in the data set according to cache benefits, and selectively caching the data in a plurality of edge servers in sequence based on the cache conditions.

3. The cloud-edge cooperative caching method according to claim 2, wherein the calculating the caching condition based on the data access information of the previous cycle specifically includes:

for each piece of data, calculating local access preference of the data to each edge server according to the accumulated request amount of the data in the service range of each edge server, and obtaining the local access preference of each piece of data in the data set to each edge server;

calculating a global data popularity of the data based on the access frequency of the data; calculating cache benefits of the data cached in each edge server according to the global data popularity and the local access preference of the data to each edge server, and obtaining the cache benefits of each data cached in each edge server;

determining the minimum value of the cache income corresponding to each edge server according to the cache income of each data cached in each edge server; and calculating the caching profit threshold of each edge server according to all the minimum values and the data access delay.

4. The cloud-edge collaborative caching method according to claim 3, wherein the calculating, according to the global data popularity and the local access preference of the data to each of the edge servers, a caching gain of the data cached in each of the edge servers specifically comprises:

for each edge server, summing the global data popularity and the local access preference of the data to the edge server to obtain the access frequency of the data in the edge server;

and calculating the caching benefit of the data cached in the edge server according to the access frequency of the data in the edge server and the data size of the data.

5. The cloud-edge collaborative caching method according to claim 2, wherein the sequentially selectively caching the data in the plurality of edge servers based on the caching condition specifically comprises:

selecting first data as data to be cached;

according to the local access preference of the data to be cached on each edge server, performing descending order arrangement on all the edge servers to obtain an ordered edge server set; selecting a first edge server in the edge server set as an edge server to be stored;

judging whether the residual cache space of the edge server to be stored is larger than the data size of the data to be cached or not to obtain a first judgment result;

if the first judgment result is negative, selecting the next edge server in the edge server set as an edge server to be stored, and returning to the step of judging whether the residual cache space of the edge server to be stored is larger than the data size of the data to be cached;

if the first judgment result is yes, caching the data to be cached in the edge server to be stored, and caching the data to be cached in an edge server which is except the edge server to be stored and meets a preset condition; the preset conditions are that the cache benefit of the data to be cached in the edge server is greater than the cache benefit threshold value of the edge server, and the residual cache space of the edge server is greater than the data size of the data to be cached;

judging whether the data in the data set are cached or not;

and if not, selecting the next data behind the data to be cached as the data to be cached, and returning to the step of performing descending order arrangement on all the edge servers according to the local access preference of the data to be cached on all the edge servers.

6. The cloud-edge collaborative caching method according to claim 1, wherein the managing the cache space of each edge server by using a replacement policy based on perceptual redundancy after receiving a data access request specifically comprises:

after receiving a data access request, judging whether target data requested to be acquired by the data access request is located in an exclusive area of a local edge server or not, and obtaining a second judgment result; the local edge server is an edge server covering a terminal which sends the data access request; the cache space of each edge server is divided into an exclusive area and a redundant area; the exclusive area is used for caching the exclusive data which is not cached by the rest edge servers; the redundant area is used for caching the exclusive data and redundant data cached by other edge servers;

if the second judgment result is yes, updating the priority of the target data;

if the second judgment result is negative, judging whether the target data is located in a redundant area of the local edge server to obtain a third judgment result;

if the third judgment result is yes, judging whether the target data is exclusive data or not; if yes, upgrading and caching the target data to the exclusive area; if not, updating the priority of the target data;

if the third judgment result is negative, judging whether the target data is positioned in the adjacent edge server or not to obtain a fourth judgment result; the adjacent edge server is the rest edge servers except the local edge server;

if the fourth judgment result is yes, accessing the adjacent edge server to add the target data serving as redundant data to a redundant area of the local edge server;

if the fourth judgment result is negative, accessing the cloud data center to add the target data serving as exclusive data to an exclusive area of the local edge server.

7. The cloud-edge cooperative caching method according to claim 6, wherein the upgrading and caching the target data to the exclusive area specifically includes:

judging whether the residual cache space of the exclusive area is larger than the data size of the target data or not;

if yes, upgrading and caching the target data to the exclusive area;

if not, removing the exclusive data with the lowest priority in the exclusive area, and returning to the step of judging whether the residual cache space of the exclusive area is larger than the data size of the target data.

8. The cloud edge collaborative caching method according to claim 6, wherein the adding the target data as redundant data to a redundant area of the local edge server specifically comprises:

judging whether the residual cache space of the redundant area is larger than the data size of the target data or not;

if yes, caching the target data to the redundant area;

if not, removing the data with the lowest priority in the redundant area, and returning to the step of judging whether the residual cache space of the redundant area is larger than the data size of the target data.

9. A cloud edge cooperative cache system based on perceptible redundancy is characterized by comprising a cloud data center, an edge server cluster and a controller; the cloud data center and the edge server cluster are both in communication connection with the controller; the edge server cluster is a cooperative cache domain consisting of a plurality of edge servers; the cache space of each edge server is divided into a redundant area and an exclusive area;

the controller is used for executing the cloud edge collaborative caching method of any one of claims 1 to 8.

10. The cloud-edge collaborative caching system according to claim 9, wherein the controller comprises an access information acquisition module, a cache profit prediction module, an edge data caching module, a request processing module, and a cloud service access module;

the access information acquisition module is used for counting relevant information when processing the data access request to obtain data access information;

the cache profit prediction module is used for calculating local access preference, cache profit and a cache profit threshold value based on the data access information;

the edge data caching module is used for performing caching placement operation by utilizing a cooperative edge data caching strategy based on the perceptible redundancy;

the request processing module is used for carrying out cache replacement operation by utilizing a replacement strategy based on perceptual redundancy.

Images