Understanding Redis Eviction Policies: maxmemory, LRU, LFU, and Expiration Strategies

Overview

Redis is a popular in‑memory data store often used as a cache. When its memory fills up, Redis provides a configurable maxmemory setting to limit usage and several eviction policies to decide which keys to discard.

The maxmemory parameter can be set in redis.conf or via the command line, for example:

// Get the current maxmemory value
127.0.0.1:6379> config get maxmemory
// Set maxmemory to 100mb
127.0.0.1:6379> config set maxmemory 100mb

If the stored data exceeds the configured limit, Redis applies an eviction strategy to free space for new keys.

Eviction Policies

Redis offers six eviction policies, with noeviction as the default:

noeviction – When memory is full, write commands return an error.

allkeys-lru – All keys are evicted using the LRU (Least Recently Used) algorithm.

volatile-lru – Only keys with an expiration time are evicted using LRU.

allkeys-random – All keys are evicted randomly.

volatile-random – Only keys with an expiration time are evicted randomly.

volatile-ttl – Keys with an expiration time are evicted based on their remaining TTL (shorter TTL evicted first).

Choosing a policy depends on the workload. For mixed hot and cold data, allkeys-lru is often suitable; if all keys have similar access frequency, allkeys-random may be used. The policy can be set in redis.conf or via:

// Get the current eviction policy
127.0.0.1:6379> config get maxmemory-policy
// Set the eviction policy to allkeys-lru
127.0.0.1:6379> config set maxmemory-policy allkeys-lru

LRU Algorithm

LRU (Least Recently Used) evicts the key that has not been accessed for the longest time. Redis implements an *approximate* LRU: it randomly samples five keys and evicts the least recently used among them. The sample size can be configured (default 5) to improve accuracy.

Each key stores a 3‑byte timestamp to support this algorithm. Since Redis 3.0, the sample pool size is 16, and keys with timestamps smaller than the current minimum are added to the pool. When the pool is full, the key with the largest timestamp is removed, ensuring that the eviction decision is based on the most recent usage data.

One drawback of LRU is that a key that was never accessed before but is accessed once becomes a “hot” key and may avoid eviction, while a previously hot key that becomes idle may be evicted prematurely.

LFU Algorithm

LFU (Least Frequently Used) was introduced in Redis 4.0. It evicts keys that have been accessed the fewest times within a recent time window, reducing the chance of mistakenly evicting hot data. Redis supports volatile-lfu and allkeys-lfu policies.

Expiration Deletion Strategies

Redis provides three ways to delete expired keys:

Timed deletion – A timer periodically removes expired keys, which is memory‑friendly but adds CPU overhead.

Lazy deletion – Keys are checked for expiration only when accessed, saving CPU but potentially leaving expired keys in memory.

Periodic deletion – A hybrid approach that runs at configurable intervals to balance CPU and memory usage.

RDB and AOF Persistence Handling

Redis offers two persistence mechanisms: RDB snapshots and AOF logs. Both SAVE / BGSAVE (for RDB) and REWRITEAOF / BGREWRITEAOF (for AOF) omit expired keys, effectively cleaning them during persistence.

When loading an RDB file, the master instance skips expired keys, while a replica may load them. In AOF mode, the rewrite commands also exclude expired keys, ensuring that the persisted data remains clean.

Overall, understanding and configuring maxmemory , selecting an appropriate eviction policy, and tuning expiration strategies are essential for maintaining Redis performance and reliability.