Redis Expiration Explained: Lazy vs Periodic Deletion and Memory Eviction

Redis's expiration strategy determines how keys with a time‑to‑live (TTL) are handled. It includes two primary expiration methods—lazy (passive) deletion and periodic (active) deletion—plus an auxiliary memory‑eviction mechanism.

Lazy Deletion (Passive Deletion)

Principle: When a client accesses a key, Redis checks if the key has expired; if so, it deletes the key immediately and returns a null value.

Advantages:

On‑demand cleanup reduces CPU overhead because deletion occurs only during key access.

Disadvantages:

Expired keys that are never accessed continue to occupy memory, potentially causing memory leaks.

Simultaneous access to many expired keys can cause sudden load spikes.

Suitable Scenarios: Works well when memory usage is not tightly constrained and expired keys are frequently accessed.

Periodic Deletion (Active Deletion)

Principle: Redis periodically scans a random sample of keys and removes those that have expired. The process repeats if more than 25% of the sampled keys are expired, respecting a time limit.

Procedure:

Random Sampling: Select a configurable number of keys from each database (default 20).

Deletion Decision: If over 25% of sampled keys are expired, repeat sampling and deletion until the ratio falls below 25% or the time budget is exhausted.

Frequency Control: The hz parameter sets how many times per second the periodic task runs (default 10). Example configuration:

hz 10  # default, can be adjusted between 1 and 500 (usually not above 100)

Advantages:

Timely memory reclamation by regularly removing expired keys.

Disadvantages:

Memory usage may fluctuate, especially when many keys expire at once.

Periodic scans consume CPU resources.

Suitable Scenarios: Ideal when memory usage must be kept under control and expired keys need to be freed promptly.

Memory Eviction Strategies (Auxiliary Mechanism)

Principle: When the configured maxmemory limit is reached, Redis evicts keys based on the selected eviction policy, even if some keys have not yet expired. Common policies include:

volatile-ttl: Evicts keys with the shortest remaining TTL.

volatile-lru: Evicts least‑recently‑used keys among those with an expiration.

volatile-lfu: Evicts least‑frequently‑used keys among those with an expiration.

allkeys-lru / allkeys-lfu: Evicts LRU/LFU keys from the entire dataset.

volatile-random / allkeys-random: Randomly evicts keys.

noeviction: (default) Rejects new writes until enough memory is freed.

Example configuration:

maxmemory 4gb               # set Redis max memory to 4GB
maxmemory-policy volatile-ttl  # prioritize eviction of keys with shortest TTL

Advantages:

Active memory management prevents out‑of‑memory failures.

Flexible policy selection allows tailoring to specific workload requirements.

Disadvantages:

Complex configuration and management.

Risk of unintentionally evicting important but unexpired data.

Suitable Scenarios: Suitable for environments with limited memory where proactive eviction is needed, such as high‑concurrency, large‑scale distributed systems.