Optimizing Redis In-Memory Eviction Strategies (8090)

Introduction

Redis is the de‑facto standard for high‑throughput, low‑latency caching. When memory pressure hits, the eviction policy determines which keys survive and which are purged. Choosing the wrong policy can cause cache‑miss storms, increased latency, and even OOM kills. This article dissects the eight built‑in eviction strategies, benchmarks them under realistic workloads, and provides a decision framework for production deployments.

Eviction Policies Deep Dive

1. noeviction

Default for Redis < 4.0. Returns errors on write when memory limit reached. Use only when you can guarantee capacity planning.

2. allkeys‑lru

Evicts least recently used keys across the entire keyspace. Ideal for generic caches where access pattern follows temporal locality.

3. volatile‑lru

Applies LRU only to keys with an expire set. Preserves non‑expiring keys (e.g., configuration).

4. allkeys‑lfu

Evicts least frequently used keys. Better for workloads with skewed access frequencies (e.g., hot‑key detection).

5. volatile‑lfu

LFU restricted to keys with TTL. Combines frequency awareness with explicit expiration.

6. allkeys‑random

Random eviction across all keys. Low overhead, but unpredictable cache‑hit ratio.

7. volatile‑random

Random eviction among keys with TTL. Useful when you want a simple policy for expiring data.

8. volatile‑ttl

Evicts keys with the shortest remaining TTL. Guarantees that soon‑to‑expire data is removed first.

Benchmark Methodology

We used a 3‑node Redis Cluster (v7.2) on c5.4xlarge instances (16 vCPU, 32 GiB RAM). Workload generated by memtier_benchmark with 50 M keys, 1 KB values, 80 % GET / 20 % SET, Zipfian distribution (θ=0.99). Each policy ran for 30 min after warm‑up. Metrics: throughput (ops/sec), 99th‑percentile latency, eviction rate, and memory fragmentation ratio.

Results Analysis

Throughput: allkeys-lfu and volatile-lfu delivered the highest sustained ops/sec (~1.2 M ops/s) under Zipfian load because they keep hot keys longer. allkeys-lru trailed by ~8 % due to recency churn. volatile-ttl suffered the lowest throughput (~0.6 M ops/s) as it constantly evicts soon‑to‑expire keys, causing frequent re‑population.

Latency (p99): LFU policies kept p99 under 2 ms; LRU policies hovered around 3.5 ms; random policies spiked to 7 ms due to cache‑miss bursts.

Eviction Rate: allkeys-random evicted 1.8× more keys than LFU, increasing CPU overhead for key expiration processing.

Fragmentation: LFU policies exhibited lower fragmentation (1.12) vs LRU (1.27) because they retain larger, frequently accessed objects.

Decision Framework

1. Access Pattern Known? If you have clear hot‑key sets → allkeys-lfu.
2. TTL‑Driven Expiry? If most keys carry TTL → volatile-lfu or volatile-ttl.
3. Strict Latency SLA? Avoid random policies; prefer LFU/LRU.
4. Memory Headroom? With >30 % free memory, noeviction + proactive scaling works.
5. Operational Simplicity? allkeys-lru is a safe default for generic caches.

Conclusion

Eviction strategy is a lever that directly impacts Redis performance, cost, and reliability. LFU‑based policies consistently outperform LRU and random variants under skewed, real‑world workloads. However, the optimal choice hinges on your key lifecycle (TTL vs persistent), access distribution, and operational constraints. Use the benchmark harness above to validate against your own dataset, and integrate the decision matrix into your capacity‑planning runbooks.