How Redis Handles Expired Keys: Periodic vs Lazy Deletion Strategies

Periodic Deletion Strategy

Redis stores the expiration time of each key in a dedicated expiration dictionary. A server‑cron task runs at a frequency defined by the hz setting in redis.conf (default 10 scans per second, i.e., every 100 ms) to clean up expired keys.

During each scan Redis does not traverse the whole dictionary; instead it randomly selects a small batch of keys (20 by default), checks their expiration, and deletes the ones that have expired. After the batch is processed, Redis checks the ratio of expired keys; if it exceeds 25 % the scan repeats immediately, otherwise it waits until the next scheduled interval.

The hz parameter can be set from 1 to 500. Setting it too high may cause excessive CPU usage because deletion operations become frequent and long; setting it too low may let expired keys linger, wasting memory. In most cases a value above 100 is unnecessary unless the workload demands ultra‑low latency.

1) Server‑cron triggers based on the hz frequency.

2) Randomly pick 20 keys from the expiration dictionary.

3) Delete the selected expired keys.

4) If the expired‑key ratio remains above 25 %, repeat steps 2–3; otherwise finish the current cycle.

Lazy Deletion Strategy

When a client issues a read or write command, Redis first checks whether the target key has expired. If it has, the key is immediately removed and no value is returned to the client. This on‑demand cleanup is CPU‑friendly because it only runs when a key is accessed.

The downside is that expired keys that are rarely accessed may remain in memory for a long time, increasing overall memory consumption. Therefore lazy deletion is most effective when keys expire shortly after their last use.

In a master‑slave replication setup, care must be taken because a slave that falls behind may not receive the master's expiration‑deletion events. Consequently, expired keys can persist on the slave, leading to memory leaks and potential consistency issues.