Redis Expiration Key Deletion Strategies: Timed, Lazy, and Periodic

1. Common Deletion Strategies

Redis provides three common expiration‑key deletion strategies: timed deletion, lazy deletion, and periodic deletion.

1.1 Timed Deletion Strategy

When a key is set with an expiration time, a timer is created to delete the key immediately when the time expires.

Advantage: very memory‑friendly.

Disadvantage: consumes a lot of CPU time.

For example, if many commands are waiting to be processed and the server spends excessive CPU time deleting expired keys, response time and throughput suffer, which is why Redis does not use pure timed deletion.

1.2 Lazy Deletion Strategy

Lazy deletion checks a key’s expiration only when the key is accessed; if it is expired, the key is removed, otherwise it is returned.

Advantage: CPU‑time friendly.

Disadvantage: memory‑unfriendly.

If many expired keys are never accessed, they remain in memory and waste resources.

1.3 Periodic Deletion Strategy

Periodic deletion combines timed and lazy approaches: at regular intervals the server scans a portion of keys and deletes the expired ones, limiting the time and frequency of the operation to reduce CPU impact while also reclaiming memory.

2. Deletion Strategies Used by Redis

Redis employs lazy deletion and periodic deletion.

2.1 Implementation of Lazy Deletion

The expireIfNeeded function is invoked before every read/write command; if the key is expired, it is removed, otherwise no action is taken.

The function checks the key and deletes it if expired; otherwise it does nothing.

2.2 Implementation of Periodic Deletion

The activeExpireCycle function is called by serverCron . It randomly samples a subset of keys from each database within a time budget, checks their expiration, and deletes the expired ones.

Each run selects a number of databases and a number of keys from each, checks them, and deletes the expired ones; the next run starts from a different database, ensuring all databases are eventually examined.

The random selection may use an LRU (Least Recently Used) algorithm, though interviewers rarely probe deeper.

3. RDB Handling of Expired Keys

3.1 Generating RDB Files

During SAVE or BGSAVE , Redis checks all keys and omits expired keys from the newly created RDB file.

3.2 Loading RDB Files

If the server runs as a master, only non‑expired keys from the RDB are loaded; expired keys are ignored. If the server runs as a replica, all keys are loaded regardless of expiration because the replica’s data will be overwritten during full synchronization.

4. AOF Handling of Expired Keys

4.1 AOF Writing

When an expired key is removed by lazy or periodic deletion, Redis appends a DEL command to the AOF file to record the deletion.

Example: a client issues GET message on an expired message key; Redis deletes the key, appends DEL message to the AOF, and returns an empty reply to the client.

4.2 AOF Rewrite

During AOF rewrite, Redis checks all keys and does not write expired keys to the new AOF file.

5. Replication and Expired Keys

In master‑slave replication, the master sends explicit DEL commands for expired keys; slaves delete the key only after receiving that command. Slaves do not delete expired keys on their own when serving read requests.

6. References

Huang Jianhong, Redis Design and Implementation