Understanding Redis Memory Eviction and Expiration Strategies

Redis cache is widely used to improve system performance, but managing memory limits requires understanding its eviction policies and expiration strategies.

Memory Eviction Policies

When a Redis node reaches its maxmemory limit, it triggers one of several eviction policies (pre‑Redis 4.0: noeviction, allkeys‑lru, allkeys‑random, volatile‑lru, volatile‑random, volatile‑ttl; Redis 4.0+: allkeys‑lfu, volatile‑lfu). Policies prefixed with allkeys- consider all keys, while those with volatile- affect only keys with an explicit TTL.

noeviction – never evict, operations fail when memory is exhausted.

allkeys‑lru – evict least‑recently‑used keys (LRU).

allkeys‑random – evict random keys.

volatile‑lru – evict LRU among keys with TTL.

volatile‑random – evict random keys with TTL.

volatile‑ttl – evict keys with the nearest expiration time.

allkeys‑lfu – evict least‑frequently‑used keys (LFU).

volatile‑lfu – evict LFU among keys with TTL.

The eviction policy is set via the maxmemory-policy directive in redis.conf .

Expiration Strategies

Redis also defines how expired keys are removed: lazy deletion (checked on access) and periodic deletion (background scans, default 10 Hz, configurable via the hz setting).

Lazy Deletion

When a client accesses a key, Redis checks its TTL; if expired, the key is deleted and null is returned.

Periodic Deletion

Redis periodically scans a sample of keys to delete expired ones, balancing CPU usage and memory reclamation.

Understanding both eviction policies and expiration strategies helps prevent memory exhaustion and ensures efficient cache usage.