As a high-performance in-memory database, Redis's efficient management of memory resources is directly related to the stability and performance of the system. When Redis's memory usage reaches the configured maximum value (maxmemory), a new write operation triggers the memory elimination mechanism (Eviction Policy) to free up space to store new data. This article will explore Redis's memory elimination strategy, implementation principles, applicable scenarios and best practices in depth.
1. Overview of memory elimination strategy
Redis's memory elimination strategy determines how to choose the keys to be deleted to free up space when memory is insufficient. These strategies can be divided into two categories:
- Expiration time-based elimination (volatile-*): Only for keys whose expiration time is set.
- Global Elimination (allkeys-*): For all keys, whether or not the expiration time is set.
Redis supports the following 8 memory elimination strategies：
noeviction: Default policy, prohibits writing of new data, and directly returns an error.
volatile-lru: Eliminate the key that sets the expiration time that is least used recently (LRU).
volatile-lfu: Eliminate the least frequently used (LFU) key that sets the expiration time.
volatile-random: Random elimination key sets the expiration time.
volatile-ttl: Prioritize the shortest remaining survival time (TTL) keys.
allkeys-lru: Eliminates the least recently used key of all keys.
allkeys-lfu: The least frequently used key of all keys is eliminated.
allkeys-random: Randomly eliminate any key.
2. Detailed explanation of the memory elimination strategy
2.1 noeviction (not eliminated)
Behavior: When memory is insufficient, all write commands (such as SET, LPUSH) are rejected, but read operations are allowed.
Applicable scenarios: Suitable for scenarios where data cannot be lost (such as persistent storage), it is necessary to ensure sufficient memory or cooperate with the persistence mechanism.
shortcoming: If the memory is insufficient and there is no persistence, the service may be unavailable.
2.2 LRU（Least Recently Used）
Principle: Eliminate the key that has not been accessed recently.
Redis implementation: Redis uses an approximate LRU algorithm to select the longest unused keys by random sampling (by default, 5 keys), rather than traversing all keys to reduce computational overhead.
Applicable scenarios: Suitable for caching scenarios, and priority is given to retaining hotspot data.
Command Example：
CONFIG SET maxmemory-policy volatile-lru # For keys with expiration timeCONFIG SET maxmemory-policy allkeys-lru # For all keys
2.3 LFU（Least Frequently Used）
Principle: The key with the lowest access frequency was eliminated (introduced by Redis 4.0).
Redis implementation: Count the access frequency of keys through the counter and decay historical counts over time to avoid long-term accumulation, resulting in the inability to eliminate old keys.
Applicable scenarios: Suitable for long-term cache, such as high-frequency access to static data.
Command Example：
CONFIG SET maxmemory-policy volatile-lfu # For keys with expiration timeCONFIG SET maxmemory-policy allkeys-lfu # For all keys
2.4 TTL（Time To Live）
Principle: Prioritize the shortest remaining survival time (TTL) keys.
Applicable scenarios: Suitable for scenarios where the key life cycle is clearly known (such as temporary session data).
limit: Only effective for keys that have the expiration time set.
Command Example：
CONFIG SET maxmemory-policy volatile-ttl
2.5 Random (Random Elimination)
Principle: Randomly select keys to eliminate.
Applicable scenarios: When memory pressure is high and data importance is equal, memory will be released quickly.
Command Example：
CONFIG SET maxmemory-policy volatile-random # For keys with expiration timeCONFIG SET maxmemory-policy allkeys-random # For all keys
3. The underlying implementation of memory elimination
3.1 LRU/LFU approximation algorithm
- Redis maintains candidate elimination keypools through the evictionPoolEntry structure. Each time it is eliminated, a set of keys is randomly sampled, its access time or frequency information is updated, and the most inactive key is selected to delete.
- LRU Clock: Redis records the last access time of the key using a global 24-bit clock (precision in seconds). Each object in memory stores the difference (lru field) from the global clock, rather than the exact timestamp.
- LFU counter: The lru field of each key is split into two parts:
- High 16 bits: minute-level accuracy of the most recent visit time.
- Low 8 bits: Access frequency counter (0~255), increasing probability, decays with time.
3.2 Elimination Process
- The client executes a write command to trigger a memory check.
- Redis Checks if maxmemory has been exceeded.
- Select the to-elimination key according to the configured policy.
- Delete the key and trigger related events (such as evicted notifications).
4. How to choose the appropriate memory elimination strategy?
4.1 Cache Scenario
Recommended strategy: allkeys-lru or allkeys-lfu
Reason: Priority is given to retaining hotspot data to maximize cache hit rate.
4.2 Permanent storage
Recommended policy: noeviction (must ensure sufficient memory or persistence is enabled).
Alternative: If partial data is allowed to be lost, volatile-lru can be used in combination with expiration time.
4.3 Temporary data scenarios
Recommended strategy: volatile-ttl
Reason: Automatically clean up data with clear life cycle (such as verification codes, session information).
4.4 Mixed data
Recommended strategy: allkeys-lru + partial keys set the expiration time.
Example: In the e-commerce system, product details are cached using allkeys-lru, and shopping cart data is set to TTL.
5. Best practices and precautions
5.1 Configuration Recommendations
Set a reasonable maxmemory: usually 80%~90% of physical memory, avoiding OOM.
Monitor memory usage:
INFO memory # Check memory metrics (used_memory, maxmemory)INFO stats # Check evicted_keys（Number of elimination keys）
5.2 Avoid mass elimination
Shash design: Decentralize data through clusters to reduce the memory pressure of a single node.
Preheated cache: Preload high-frequency data after restart to avoid centralized elimination during cold startup.
5.3 Common Mistakes
volatile-ttl does not depend on lazy deletion: This policy is only triggered when memory is insufficient and still needs to rely on periodic/lazy deletes to clean up expired keys.
LFU counters are not exact values: access frequency is incremented through probability, suitable for relative comparison rather than absolute counting.
6. Summary
Redis's memory phasing strategy is a key mechanism for balancing memory usage and performance. Understanding the principles and applicable scenarios of different strategies and reasonable configurations based on business needs can significantly improve the stability and efficiency of the system. In high concurrency scenarios, it is recommended to track memory and elimination indicators in real time through monitoring tools (such as RedisInsight, Prometheus), and dynamically adjust policies and resource configuration.
Through the in-depth analysis of this article, I hope you can master the core mechanism of Redis memory elimination, and flexibly apply it in practice to build efficient and reliable Redis services.
References
Redis official documentation: /docs/reference/eviction/
"Redis Design and Implementation" - Huang Jianhong
Redis source code analysis (,)
This is the end of this article about the in-depth analysis of Redis memory elimination strategy. For more related content of Redis memory elimination strategy, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!