A cuckoo filter-based Redis cache eviction middleware

Abstract

The application discloses a Redis cache elimination middleware based on a cuckoo filter, which is arranged between Redis and an application layer and comprises the following modules: a hot degree tracking module, a cold data cleaning module, an accurate elimination module, an adaptive tuning module, a memory management module and a concurrent control module. The application can realize intelligent elimination and dynamic management of a Redis cache space, and through accurate hot degree tracking, distributed cleaning, accurate elimination, adaptive tuning, intelligent memory management and efficient concurrent control, can effectively solve problems of low cache space utilization, long-term occupation of space by cold data and low elimination accuracy caused by a traditional cache elimination strategy, and improve the overall efficiency and resource utilization of a cache system.

Description

Technical Field

[0001] This invention relates to the field of cloud computing, big data, and edge computing technologies, and in particular to a Redis Cache Eviction Middleware (RCEM) based on a cuckoo filter. Background Technology

[0002] In recent years, with the rapid development of cloud computing technology and the deepening of enterprise digital transformation, Redis, as a high-performance in-memory database, has been widely used in various application systems. Especially in scenarios such as microservice architecture, real-time data processing, and caching acceleration, Redis has become an indispensable core component. However, in a cloud environment, Redis cache eviction strategies face many challenges.

[0003] First, low cache space utilization is a widespread problem. Traditional eviction policies (LRU, LFU, FIFO) do not actively clean up cold data in the cache, causing the cache to remain full once it is full. A large amount of cold data that may not be accessed in the future occupies cache space for a long time, reducing the effective utilization of cache space.

[0004] Secondly, there is a lack of accurate popularity tracking mechanisms. Existing solutions cannot accurately track and dynamically update data popularity information, making it difficult to accurately identify cold data. LRU only considers the most recent access time, and LFU only considers access frequency, neither of which can fully reflect the true popularity of the data.

[0005] Secondly, there's the issue of high overhead in cleanup operations. TTL-based cleanup methods require periodically scanning all cached objects, resulting in significant computational costs. Even with random sampling methods, expired objects may still be retained, impacting the freshness of cached content.

[0006] Furthermore, the eviction policy is not precise enough. The existing eviction policy cannot accurately select the coldest metadata for eviction when the cache is full, which may lead to the wrong eviction of hot data, affecting the cache hit rate.

[0007] Existing solutions can be mainly categorized as follows:

[0008] (1) Traditional LRU elimination strategy Redis employs an approximated LRU algorithm: each key object internally stores a 24-bit LRU clock (recording the second-level timestamp of the last access). When memory is insufficient and eviction is triggered, Redis will randomly sample a number of keys (5 by default, which can be adjusted via maxmemory-samples) and select the key with the smallest LRU timestamp (i.e., the least used) for eviction.

[0009] The disadvantages of this method include: ① Low cache space utilization: It does not actively clean up cold data in the cache, so the cache will always remain full once it is full; ② Lack of accurate popularity tracking mechanism: It only considers the most recent access time and cannot fully reflect the true popularity of the data; ③ The eviction policy is not accurate enough: It cannot accurately select the coldest metadata to evict when the cache is full.

[0010] (2) TTL-based cache cleanup Some systems employ a time-to-live (TTL)-based cleanup strategy, setting a lifespan for each object and removing it upon expiration. However, this approach requires setting a reasonable TTL for each object, and without prior knowledge, it's difficult to choose an appropriate TTL value, potentially leading to frequently accessed objects being prematurely cleaned up.

[0011] The disadvantages of this method include: ① High overhead of cleanup operations: It requires periodically scanning all cached objects, which incurs high computational overhead; ② Difficult configuration: It requires setting a reasonable TTL for each object, and it is difficult to choose an appropriate TTL value without prior knowledge; ③ Potential for false cleanup: It may cause frequently accessed objects to be cleaned up prematurely.

[0012] (3) S3-FIFO elimination strategy S3-FIFO employs three FIFO queues: a fast degradation queue, a ghost queue, and a main queue. While capable of handling objects accessed only once, maintaining three FIFO queues is very complex, the ghost queue increases memory overhead, and it still cannot effectively clean up cold data.

[0013] (4) Hash table-based cache management Some systems use hash tables to manage cached data, quickly locating data positions through hash functions. While this offers high query efficiency, it lacks an effective data popularity tracking mechanism and cannot achieve intelligent cache eviction.

[0014] (5) Time window-based caching strategy Some systems employ a time-window-based caching strategy, managing cached data by setting fixed time windows. However, this method cannot adapt to dynamically changing access patterns, and improper time window settings can negatively impact caching performance.

[0015] These existing solutions all have the following shortcomings: ①Low cache space utilization: Traditional eviction strategies do not actively clean up cold data in the cache, causing the cache to remain full once it is full, and a large amount of cold data that may not be accessed in the future will occupy the cache space for a long time. ② Lack of accurate popularity tracking mechanism: Existing solutions cannot accurately track and dynamically update the popularity information of data, and it is difficult to accurately identify cold data. LRU only considers the most recent access time, and LFU only considers the access frequency. Neither can fully reflect the true popularity of the data. ③ High overhead of cleanup operations: TTL-based cleanup methods require periodically scanning all cached objects, which is computationally expensive. Even with random sampling methods, expired objects may still be retained. ④ The eviction policy is not precise enough: the existing eviction policy cannot accurately select the coldest metadata for eviction when the cache is full, which may lead to hot data being wrongly evicted and affect the cache hit rate; ⑤ Lack of adaptive tuning mechanism: The existing solution uses fixed parameter configuration, which cannot be dynamically adjusted according to changes in system load and access mode, resulting in unstable performance in different business scenarios; ⑥ Low memory management efficiency: Traditional solutions lack an effective memory management mechanism and cannot dynamically adjust memory allocation strategies based on data usage, resulting in wasted memory resources. Summary of the Invention

[0016] Purpose of the invention: In view of the problems and shortcomings of the existing technology, the purpose of this invention is to provide a precise, efficient, adaptive, and intelligent Redis cache eviction middleware based on the cuckoo filter.

[0017] Technical Solution: To achieve the above-mentioned objectives, this invention proposes a Redis Cache Eviction Middleware (RCEM) based on a cuckoo filter. This middleware is deployed between Redis and the application layer and includes the following modules: (1) Heat Tracking Module (HTM): Based on the Cuckoo Filter, the heat of data is accurately tracked. A two-dimensional heat evaluation model is adopted. The clock value records the time characteristics of the data, and the frequency value records the access frequency of the data. The heat calculation formula is: heat = α·clock + β·frequency, where α is the weight factor of clock and β is the weight factor of frequency. (2) Cold Data Cleaning Module (CDC): It achieves efficient cold data cleanup through a cleanup operation distribution strategy, distributing the cleanup work to the normal data access process. It maintains a pointer for each bucket to mark the starting position of the next round of cleanup operation. When traversing the corresponding bucket entries during data insertion and query, it sequentially updates random entries and checks the hotness value of the updated entry. If the hotness value is lower than the preset coldness threshold, the entry is cleared from the cache. (3) Precise Elimination Module (EPM): Based on the non-uniform heat level division, it realizes precise cold data elimination. Level 0 manages data with a heat value of 1, Level 1 manages data with a heat value between 2 and 3, and Level n manages data with a heat value between 2^n and 2^(n+1)-1. Each heat level maintains an LRU list and saves data in order of last access time. When the cache space is insufficient, the lowest heat level and non-empty LRU list is found, and the data located at the end of the LRU list is eliminated. (4) Adaptive Tuning Module (ATM): Based on changes in system operating status, business access patterns and performance indicators, the key parameters of the middleware are dynamically adjusted. The key parameters include dynamic threshold adjustment, weight factor optimization, performance monitoring feedback and multi-dimensional tuning strategies. (5) Memory Management Module (MMM): Dynamically adjusts memory allocation strategy based on data popularity, adopts memory pool management and object reuse mechanism, and combines incremental compression and dynamic memory adjustment to improve memory utilization; (6) Concurrency Control Module (CCM): The hash table is divided into multiple segments using a segmented locking strategy and read-write lock optimization. Each segment uses an independent read-write lock for concurrency control to ensure data consistency and operational performance in a high-concurrency environment.

[0018] Furthermore, the heat tracking module uses a cuckoo filter as its core data structure. Each entry contains four fields: ID, which is a unique identifier for the cached data; clock, which indicates the time elapsed since the data entered the cache (the larger the value, the newer the data); frequency, which records the number of times the data has been accessed; and ptr, which points to the position in the LRU list of the eviction data structure. The heat calculation formula is: Heat = α·clock + β·frequency, where α is the weighting factor of clock and β is the weighting factor of frequency, both with a default value of 1.

[0019] Furthermore, the update mechanism of the heat tracking module includes: periodic updates, where the middleware decrements the clock value by one and performs the update once every 2^b-1 operations, where b is the bit length of the clock; and on-access updates, where when data is accessed again, the middleware updates the frequency of the data (increments by 1) and the clock (set to the current value C), indicating that the data has been refreshed.

[0020] Furthermore, the heat tracking module adopts a sliding window mechanism, and the window length is dynamically calculated as: window_length = base_length × (cache_size / 64MB), where base_length is the base window length, which defaults to 120000; cache_size is the cache capacity parameter involved in the formula calculation; when the operation count reaches the window length, the global clock is triggered to decrement, and the clock value of all entries is decremented by 1 at the same time, realizing the sliding of the time window.

[0021] Furthermore, the cold data cleanup module employs the following cleanup operation amortization strategy: between two periodic updates and cleanups, a pointer is maintained for each bucket to mark where the next round of updates and heat checks will begin; during data insertion and querying, when traversing the corresponding two bucket entries, random entries are updated sequentially and their update heat is checked, with the pointer moving to the next unscanned entry; if the update heat is lower than a preset cold / hot threshold, the module will remove it from the cache. Cleanup triggering conditions include data access operation triggers, cache space utilization exceeding a threshold, and preventative cleanup when system load is low.

[0022] Furthermore, the cold data determination criterion of the cold data cleaning module is: is_cold_data = (hotness_value)<cold_threshold) AND (last_access_time> The cached data is defined as follows: is_cold_data indicates whether the current cached data is cold data, hotness_value is the hotness value of the cached data, cold_threshold is the cold data hotness threshold, last_access_time is the last access time of the cached data, and time_threshold is the time threshold. The cold_threshold is adjusted according to the cache hit rate, the time_threshold is adjusted according to the system load, and personalized adjustments are made considering business characteristics.

[0023] Furthermore, the non-uniform popularity levels of the precise eviction module are divided into: Level 0 manages data with a popularity value of 1, Level 1 manages data with a popularity value between 2 and 3, and Level n manages data with a popularity value between 2^n and 2^(n+1)-1; each popularity level maintains an LRU list, storing all data belonging to the corresponding popularity range in order of last access time; when the cache space is insufficient, the lowest popularity level and non-empty LRU list is found, and the data at the end of it is evictioned; the module also includes an eviction prediction mechanism, which predicts future changes in data popularity by analyzing the trend of data access pattern changes and calculating the access frequency decay rate.

[0024] Furthermore, the elimination strategies of the precise elimination module include: a precise elimination strategy, which determines that the system load is low when the system CPU utilization is lower than a first preset threshold, and prioritizes eliminating the coldest data; a batch elimination strategy, which determines that the system load is high when the system CPU utilization is not lower than a second preset threshold, and reduces the frequency of elimination operations; and an aggressive elimination strategy, which determines that the memory pressure is high when the proportion of Redis used memory to the maximum configured memory is not lower than a third preset threshold, and increases the elimination ratio.

[0025] Furthermore, the adaptive tuning module obtains system status information in real time through Redis's INFO command, including memory usage through the INFO MEMORY command, statistical information through the INFO STATS command, and persistence-related information through the INFOPERSISTENCE command. Based on this real-time monitoring data, it calculates key performance indicators such as cache hit rate, memory utilization, and operation latency. At the same time, it adopts a multi-dimensional tuning strategy encompassing time, business, and system dimensions, collects system performance data in real time, periodically analyzes trends, records tuning history, and supports parameter rollback.

[0026] Furthermore, the compression strategy of the memory management module is as follows: a high compression ratio algorithm is used for cold data with a popularity value below the fourth preset threshold; a balanced compression algorithm is used for warm data with a popularity value between the fourth and fifth preset thresholds; and no compression is performed on hot data with a popularity value not lower than the fifth preset threshold. An incremental compression algorithm is used to periodically compress the memory usage of low-popularity data, and the compression frequency is dynamically adjusted according to the system load. The memory pool management adopts a pre-allocated fixed-size memory pool and an object pool mode to reuse memory blocks, and the memory pool size is adjusted according to the access frequency. The dynamic memory adjustment mechanism dynamically adjusts memory allocation according to the cache hit rate. When the proportion of used memory to total configured memory reaches a preset upper limit threshold, additional memory is automatically requested from the system. When the memory usage rate is lower than a preset lower limit threshold, excess memory is released.

[0027] Furthermore, the concurrency control module divides the hash table into 2^n segments, where n is a configurable parameter, defaulting to 4. Each segment contains a contiguous range of buckets, and the segment to which the data belongs is determined by the high-order bits of the hash value. A read-write lock mechanism is used to support the concurrent execution of multiple read operations, while write operations use mutex locks to ensure data consistency. The lock acquisition order is fixed to avoid deadlock problems. At the same time, lock-free operation design and batch operation optimization are adopted to reduce lock overhead and improve concurrency performance.

[0028] The beneficial effects of this invention are as follows: This invention can realize intelligent eviction and dynamic management of Redis cache space. Through accurate heat tracking, distributed cleanup, accurate eviction, adaptive optimization, intelligent memory management and efficient concurrency control, it effectively solves the problems of low cache space utilization, long-term space occupation by cold data and low eviction accuracy caused by traditional cache eviction strategies, thereby improving the overall efficiency and resource utilization of the cache system. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the overall architecture of the present invention; Figure 2 This is a schematic diagram of the data structure of the cuckoo filter of the present invention; Figure 3 This is a schematic diagram of the non-uniform heat level classification and elimination data structure of the present invention. Detailed Implementation

[0030] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading this invention, any modifications of the invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.

[0031] This invention proposes a Redis cache eviction middleware based on a cuckoo filter, which solves the problems of low cache space utilization, long-term space occupation by cold data, and low eviction accuracy caused by traditional cache eviction strategies. Figure 1 As shown, this middleware is deployed between Redis and the application layer and contains 6 core modules, including: hot tracking module, cold data cleanup module, precise eviction module, adaptive tuning module, memory management module, and concurrency control module. Figure 2 This is a schematic diagram of the data structure of the cuckoo filter in this invention, which is the core data support for heat tracking and cold data cleaning; Figure 3 This is a schematic diagram of the non-uniform heat level classification and elimination data structure of the present invention, which provides a structural basis for the precise elimination module.

[0032] The following example of a single cache access illustrates the specific implementation of this invention.

[0033] The complete workflow of the Redis cache eviction middleware based on the Cuckoo Filter includes the following six stages, and the detailed implementation process of each stage is as follows: ① Popularity Tracking Phase: This phase is executed by the popularity tracking module. Its core is based on a cuckoo filter, accurately tracking the popularity of cached data to provide a data foundation for subsequent eviction and cleanup. Its detailed implementation strictly follows the technical solution described in the invention. Specifically, the implementation process is as follows: A cuckoo filter is used as the core data structure. Each entry contains four fields: ID (a unique identifier for cached data), clock (the time elapsed since the data entered the cache; a larger value indicates newer data), frequency (records the number of times the data has been accessed), and ptr (a pointer to the LRU list position in the eviction data structure). The popularity calculation formula is: Popularity = α·clock + β·frequency, where α is the clock weight factor and β is the frequency weight factor, both with a default value of 1. The update mechanism combines periodic updates and on-access updates: Periodic updates involve the middleware decrementing the clock value by one, performed once every 2^b-1 operations, where b is the bit length of the clock; on-access updates occur when data is accessed again, the middleware updates the data's frequency (increments by 1) and clock (sets it to the current value C), indicating that the data has been refreshed. Simultaneously, a sliding window mechanism is adopted, and the window length is dynamically calculated as: window_length = base_length ×(cache_size / 64MB), where window_length is the operation count length of the sliding window, base_length is the base window length (default is 120000), and cache_size is the cache capacity parameter used in the formula calculation; when the operation count reaches the window length, the global clock is triggered to decrement, and the clock value of all entries is decremented by 1 simultaneously, realizing the sliding of the time window; ② Cold Data Cleaning Phase: This phase is executed by the cold data cleaning module. Its core is to employ a distributed strategy to efficiently identify and clean cold data, avoiding the occupation of cache space. Its detailed implementation strictly follows the technical solution described in the invention. The specific implementation process is as follows: A cleanup operation distributed strategy is adopted. Between two periodic updates and cleanups, a pointer is maintained for each bucket to mark where the next round of updates and heat checks will begin. During data insertion and querying, when traversing the corresponding two bucket entries, a random entry is updated sequentially, and the heat of the updated entry is checked. The pointer moves to the next unscanned entry. If the heat of an entry is lower than a preset cold / hot threshold, the module will remove the entry from the cache. The cold data determination criterion is: is_cold_data = (hotness_value)<cold_threshold) AND (last_access_time> The cache structure is defined as follows: `is_cold_data` indicates whether the current cached data is cold data, `hotness_value` is the popularity value of the cached data, `cold_threshold` is the cold data popularity threshold, `last_access_time` is the last access time of the cached data, and `time_threshold` is the time threshold. `cold_threshold` is adjusted based on the cache hit rate, `time_threshold` is adjusted based on system load, and personalized adjustments are made considering business characteristics. Cleanup trigger conditions include data access operations, cache space utilization exceeding the threshold, and preventative cleanup when system load is low. Entries with a popularity below the threshold will be removed from the cache. ③ Precise Elimination Stage: This stage is executed by the precise elimination module. Its core is based on non-uniform heat level classification to achieve refined elimination of cold data. Its detailed implementation strictly follows the technical solution described in the invention. The specific implementation process is as follows: A non-uniform heat level classification method is adopted. Level 0 manages data with a heat value of 1, Level 1 manages data with heat values ​​between 2 and 3, and Level n manages data with heat values ​​between 2^n and 2^(n+1)-1. Each heat level maintains an LRU list, storing all data belonging to the corresponding heat range in order of last access time. When cache space is insufficient, the lowest heat level and non-empty LRU list is found, and data at the end of that list is eliminated. This module also includes an elimination prediction mechanism, which predicts future changes in data heat by analyzing data access pattern changes and calculating access frequency decay rates. The eviction policy is dynamically switched based on the system status, specifically including: a precise eviction policy, which determines that the system load is low when the system CPU utilization is below 30%, and prioritizes eviction of the coldest data; a batch eviction policy, which determines that the system load is high when the system CPU utilization is not less than 60%, and reduces the frequency of eviction operations; and an aggressive eviction policy, which determines that the memory pressure is high when the proportion of Redis's used memory to the maximum configured memory is not less than 85%, and increases the eviction ratio. ④ Adaptive Tuning Phase: This phase is executed by the adaptive tuning module. Its core is real-time monitoring of system status and dynamic adjustment of key middleware parameters to ensure optimal operation. Its detailed implementation strictly follows the technical solution described in the invention. Specifically, the system status information is obtained in real-time through Redis's INFO command, including memory usage via INFO MEMORY, statistics via INFO STATS, and persistence-related information via INFO PERSISTENCE. Based on this real-time monitoring data, key performance indicators such as cache hit rate, memory utilization, and operation latency are calculated. Simultaneously, a multi-dimensional tuning strategy is adopted, encompassing time, business, and system dimensions. System performance data is collected in real-time, trends are analyzed periodically, tuning history is recorded, and parameter rollback is supported. Specifically, parameters are adjusted based on time periods (peak / off-peak); strategies are adapted based on read / write ratios and data characteristics; and parameters are optimized based on hardware configuration and network latency at the system level, ensuring a high degree of match between the tuning strategy and the actual operating scenario. ⑤ Memory Management Phase: This phase is executed by the memory management module. Its core is intelligent memory management, improving utilization and reducing garbage collection pressure. Its detailed implementation strictly follows the technical solutions described in the invention. The specific implementation process is as follows: An intelligent memory management mechanism is implemented, including memory pool management, compression optimization, and dynamic memory adjustment. Memory pool management uses a pre-allocated fixed-size memory pool and an object pool mode to reuse memory blocks, adjusting the memory pool size according to access frequency. The compression strategy is as follows: a high compression ratio algorithm is used for cold data with a popularity value below 5; a balanced compression algorithm is used for warm data with a popularity value between 5 and 20; and no compression is performed on hot data with a popularity value not lower than 20. An incremental compression algorithm is used to periodically compress the memory usage of low-population data, dynamically adjusting the compression frequency according to system load. The dynamic memory adjustment mechanism dynamically adjusts memory allocation based on cache hit rate. When the proportion of used memory to total configured memory reaches a preset upper limit threshold, additional memory is automatically requested from the system; when the memory usage rate falls below a preset lower limit threshold, excess memory is released to avoid cache overflow and memory waste.

[0034] ⑥ Concurrency Control Phase: This phase is executed by the concurrency control module. Its core is the use of segmented locks and read-write lock optimizations to achieve efficient concurrent access control and provide concurrent services to other modules. Its detailed implementation strictly follows the technical solutions described in the invention. Specifically, a segmented lock strategy is used, dividing the hash table of the Cuckoo filter into 2^n segments, where n is a configurable parameter (default is 4). Each segment contains a contiguous range of buckets. The segment to which data belongs is determined by the high-order bits of the hash value, achieving uniform distribution. Read-write lock optimization supports concurrent execution of multiple read operations, while write operations use mutex locks to ensure data consistency. The fixed lock acquisition order avoids deadlock issues. Simultaneously, lock-free operation design and batch operation optimization are employed to reduce lock overhead, improve concurrency performance, and ensure data consistency and system stability across modules in high-concurrency access scenarios.

[0035] Within the current time window, the middleware monitors cache access in real time, quickly calculates data popularity using a cuckoo filter, and proactively cleans up cold data using a cleanup operation amortization mechanism. After intelligent selection by the precise eviction module, an eviction command is finally sent to Redis, achieving intelligent management of cache space. The entire eviction process is transparent to upper-layer applications, and the eviction operation is typically completed within a short time.

[0036] This invention enables intelligent eviction and dynamic management of Redis cache space. Through precise heat tracking, distributed cleanup, precise eviction, adaptive tuning, intelligent memory management, and efficient concurrency control, it effectively solves the problems of low cache space utilization, long-term space occupation by cold data, and low eviction accuracy caused by traditional cache eviction strategies, thereby improving the overall efficiency and resource utilization of the caching system.

Claims

1. A Redis cache eviction middleware based on a cuckoo filter, deployed between Redis and the application layer, including the following modules: (1) Heat Tracking Module: Based on the Cuckoo Filter, the heat of data is accurately tracked. A two-dimensional heat evaluation model is adopted. The clock value records the time characteristics of the data, and the frequency value records the access frequency of the data. The heat calculation formula is: Heat = α·clock + β·frequency, where α is the weight factor of clock and β is the weight factor of frequency. (2) Cold data cleaning module: The cleaning operation is distributed to achieve efficient cold data cleaning. The cleaning work is distributed to the normal data access process. A pointer is maintained for each bucket to mark the starting position of the next round of cleaning operation. When traversing the corresponding bucket entries during data insertion and query, the random entries are updated sequentially and the hotness value of the updated entries is checked. If the hotness value is lower than the preset coldness threshold, the entry is cleared from the cache. (3) Precise elimination module: Based on the non-uniform heat level division, the precise elimination of cold data is realized. Level 0 manages data with a heat value of 1, Level 1 manages data with a heat value between 2 and 3, and Level n manages data with a heat value between 2^n and 2^(n+1)-1. Each heat level maintains an LRU list and saves data in order of last access time. When the cache space is insufficient, the lowest heat level and non-empty LRU list is found and the data at the end of the LRU list is eliminated. (4) Adaptive tuning module: Based on changes in system operating status, business access mode and performance indicators, the key parameter configuration of the middleware is dynamically adjusted. The key parameters include dynamic threshold adjustment, weight factor optimization, performance monitoring feedback and multi-dimensional tuning strategy. (5) Memory management module: The memory allocation strategy is dynamically adjusted according to the data popularity. The memory pool management and object reuse mechanism are adopted, combined with incremental compression and dynamic memory adjustment to improve memory utilization. (6) Concurrency control module: The hash table is divided into multiple segments using a segmented locking strategy and read-write lock optimization. Each segment uses an independent read-write lock for concurrency control to ensure data consistency and operational performance in a high-concurrency environment.

2. The Redis cache eviction middleware based on the cuckoo filter according to claim 1, characterized in that: The heat tracking module uses a cuckoo filter as its core data structure. Each entry contains four fields: ID, which is a unique identifier for the cached data; clock, which indicates the time elapsed since the data entered the cache (the larger the value, the newer the data); frequency, which records the number of times the data has been accessed; and ptr, which is a pointer to the LRU list position in the eviction data structure.

3. The Redis cache eviction middleware based on the cuckoo filter according to claim 1, characterized in that: The update mechanism of the heat tracking module includes: periodic updates, where the middleware decrements the clock value by one and performs the update once every 2^b-1 operations, where b is the bit length of the clock; and on-access updates, where when data is accessed again, the middleware increments the frequency of the data by 1 and sets the clock to the current value C, indicating that the data has been refreshed.

4. A Redis cache eviction middleware based on a cuckoo filter according to claim 1, characterized in that: The heat tracking module adopts a sliding window mechanism. The window length, window_length, is dynamically calculated as: window_length = base_length × (cache_size / 64MB), where base_length is the base window length, which defaults to 120000, and cache_size is the cache capacity parameter. When the operation count reaches the window length, the global clock is triggered to decrement, and the clock value of all entries is decremented by 1 at the same time, thus realizing the sliding of the time window.

5. A Redis cache eviction middleware based on a cuckoo filter according to claim 1, characterized in that: The cold data (is_cold_data) determination criterion of the cold data cleaning module is: is_cold_data = (hotness_value)<cold_threshold) AND (last_access_time> The cache hit rate is adjusted based on the cache hit rate, and the time threshold is adjusted based on the system load. The cache hit rate is adjusted based on the cache hit rate, and the time threshold is adjusted based on the system load. The cache hit rate is hotness_value, which is the overall popularity assessment result of the data; cold_threshold, the cold data hit rate threshold, is the threshold value used to distinguish between cold and non-cold data; last_access_time, the last access time of the cached data, represents the time when the data was most recently accessed; and time_threshold, the time threshold, is the time threshold value used to determine whether data has not been accessed for a long time.

6. The Redis cache eviction middleware based on the cuckoo filter according to claim 1, characterized in that: The precise eviction module has three eviction mechanisms: precise eviction strategy, batch eviction strategy, and aggressive eviction strategy. The precise eviction strategy determines that the system load is low when the system CPU utilization is lower than a first preset threshold, and prioritizes eviction of the coldest data. The batch eviction strategy determines that the system load is high when the system CPU utilization is not lower than a second preset threshold, and reduces the execution frequency of eviction operations. The aggressive eviction strategy determines that the system memory pressure is high when the proportion of Redis used memory to the maximum configured memory is not lower than a third preset threshold, and increases the data eviction ratio.

7. A Redis cache eviction middleware based on a cuckoo filter according to claim 1, characterized in that: The adaptive tuning module obtains system status information in real time through Redis's INFO command, including memory usage through INFO MEMORY command, statistical information through INFO STATS command, and persistence-related information through INFO PERSISTENCE command. Based on the above real-time monitoring data, it calculates cache hit rate, memory utilization, and operation latency performance indicators.

8. The Redis cache eviction middleware based on the cuckoo filter according to claim 1, characterized in that: The compression strategy of the memory management module is as follows: a high compression ratio algorithm is used for cold data with a popularity value below the fourth preset threshold; a balanced compression algorithm is used for warm data with a popularity value between the fourth and fifth preset thresholds; and no compression is performed on hot data with a popularity value not lower than the fifth preset threshold. Memory allocation is dynamically adjusted according to the cache hit rate. When the proportion of used memory to total configured memory reaches a preset upper limit threshold, additional memory is automatically requested from the system. When the memory usage rate is lower than a preset lower limit threshold, excess memory is released.

9. The Redis cache eviction middleware based on the cuckoo filter according to claim 1, characterized in that: The concurrency control module divides the hash table into 2^n segments, where n is a configurable parameter with a default value of 4. Each segment contains a contiguous range of buckets, and the segment to which the data belongs is determined by the high-order bits of the hash value. A read-write lock mechanism is used to support the concurrent execution of multiple read operations, while a mutex lock is used for write operations to ensure data consistency. The lock acquisition order is fixed to avoid deadlock problems.

Images