Databases 11 min read

Understanding Redis Expiration Strategies, RDB, and AOF Implementation

This article explains Redis's cache expiration policies—including timed, periodic, and lazy eviction—details the internal structure and parsing of RDB files, and describes the AOF persistence mechanism with its write‑ahead logging, synchronization options, and rewrite process, providing a comprehensive view of Redis data durability.

Full-Stack Internet Architecture
Full-Stack Internet Architecture
Full-Stack Internet Architecture
Understanding Redis Expiration Strategies, RDB, and AOF Implementation

Preface

Many developers frequently use Redis's expiration feature and rely on RDB and AOF files for data recovery, but few understand how they work; this article introduces the underlying mechanisms to help better manage system reliability.

Table of Contents

Redis cache expiration strategies

RDB implementation principles

AOF implementation principles

Redis Cache Expiration Strategies

Common cache expiration strategies include:

Timed eviction

Periodic eviction

Lazy eviction

Timed Eviction

Timed eviction runs background tasks at fixed intervals to scan keys with expiration times and immediately remove expired keys from memory.

The process traverses the expires dictionary, deletes expired keys from both expires and the main dict . When many keys expire simultaneously, CPU usage can spike, causing Redis to stall, but this method ensures prompt removal of expired keys.

Periodic Eviction

Periodic eviction checks a random subset of keys from expires every 25 ms, deleting those that have expired. This limits CPU usage but may delay removal of some keys; eventually all expired keys are scanned and removed.

Lazy Eviction

Lazy eviction only checks a key’s expiration when the key is accessed; if it is expired, it is removed, otherwise normal read/write proceeds. This reduces CPU load but can keep unused expired keys in memory, wasting space.

Redis combines periodic and lazy eviction to balance CPU usage and timely cleanup.

RDB Implementation Principles

Components Overview

REDIS: magic header of the RDB file.

db_version: version number of the RDB format.

EOF: marker indicating the end of the file.

check_num: checksum calculated from the preceding parts.

data_bases: one or more logical databases, each containing key‑value entries.

Each entry includes TYPE (value type), key (string), and value (parsed according to TYPE). Additional markers such as SELECTDB and db_number indicate which logical database the following data belongs to.

String Structure in RDB

The left side shows an uncompressed string value, while the right side shows its compressed representation.

List Structure in RDB

list_length: number of elements in the list.

value_length: length of each value.

value: actual stored element.

SET, ZSET, and HASH structures are similar to List and are omitted for brevity.

AOF Implementation Principles

AOF (Append‑Only File) records every write command; on restart, Redis replays the AOF to rebuild the dataset.

AOF Write Process

Key Points of the Process

Only write commands are appended to the AOF.

The appendfsync setting controls when data is flushed to disk: appendfsync=always : every command is synchronously written, minimizing data loss but reducing write throughput. appendfsync=everysec : commands are flushed once per second, improving throughput while risking up to one second of data loss. appendfsync=no : the OS decides when to flush, offering highest performance but highest risk of loss.

Continuous appends cause the AOF to grow; Redis rewrites the AOF in a background child process to shrink it, as shown in the diagram below.

Inconsistency During Rewrite

If a new write arrives while the child process is rewriting the AOF, the data written to the AOF may not reflect the latest state, leading to inconsistency.

The child reads key1 = value1 from the database.

Before appending SET key1 value1 to the AOF, a concurrent write changes key1 to value2 . The AOF still contains the old value, causing divergence.

Redis solves this by writing incoming commands to a rewrite buffer; during the rewrite, data from the buffer is merged with the snapshot before being written to the new AOF.

Conclusion

The article explained Redis's cache expiration strategies, emphasizing the combined use of periodic and lazy eviction; described the internal layout of RDB files to clarify how data is restored; and detailed the AOF mechanism, including write synchronization options and rewrite handling, providing a clear understanding of Redis data persistence.

Next, we will discuss how Redis clusters operate in production environments.

CacheDatabaseRedisData PersistenceAOFRDBexpiration
Full-Stack Internet Architecture
Written by

Full-Stack Internet Architecture

Introducing full-stack Internet architecture technologies centered on Java

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.