Lazy Deletion ​

Redis is often perceived as a single-threaded system, which simplifies code and allows for a variety of data structures. However, it actually employs several asynchronous threads to handle time-consuming operations.

Why Lazy Deletion? ​

The DEL command directly frees the memory of an object, which is generally quick. However, if the key being deleted is a large object (e.g., a hash with millions of elements), the deletion can cause significant delays and potentially block the main thread.

To mitigate this issue, Redis introduced the UNLINK command in version 4.0. This command performs lazy deletion by offloading the memory reclamation process to a background thread.

> unlink key
OK

If you have experience with multithreading, you might worry about thread safety. When the UNLINK command is issued, it can be thought of as cutting a branch from a tree. Once the branch (the key) is severed, it can no longer be accessed by the main thread, ensuring no concurrent modifications occur.

Flush Commands ​

Redis provides FLUSHDB and FLUSHALL commands to clear databases, which can also be slow. With version 4.0, these commands gained asynchronous functionality by adding the ASYNC option, allowing for the entire database to be cleared by a background thread.

> flushall async
OK

Asynchronous Queue ​

After the main thread removes an object's reference, it wraps the memory reclamation task in a job and places it in an asynchronous task queue. This queue is accessed by both the main and background threads, necessitating a thread-safe design.

Not every UNLINK operation is deferred; if the memory occupied by the corresponding key is small, it will be immediately reclaimed, similar to DEL.

AOF Sync ​

To ensure messages are not lost, Redis synchronizes the AOF (Append Only File) log to disk at configurable intervals, which can be time-consuming and impact the efficiency of the main thread. Redis also moved this operation to a separate asynchronous thread, distinct from the lazy deletion thread, with its own task queue for AOF Sync tasks.

Additional Asynchronous Deletion Points ​

In addition to DEL and FLUSH, memory reclamation occurs during key expiration, LRU eviction, the RENAME command, and when a slave completes the RDB file during full synchronization.

Redis 4.0 introduced asynchronous deletion mechanisms for these points, which require additional configuration options:

• slave-lazy-flush: For flush operations after a slave receives an RDB file.
• lazyfree-lazy-eviction: For evictions when memory reaches maxmemory.
• lazyfree-lazy-expire: For lazy deletion of expired keys.
• lazyfree-lazy-server-del: For deletion of keys during the RENAME operation.