Redis Data Structures and Underlying Implementation

Tue, 25 Aug 2026 00:00:00 +0000

Redis exposes five common types to users, but underneath there are multiple encodings (encoding). Automatically switching encodings based on data size is the key to balancing memory and performance.

Core Underlying Structures

SDS (Simple Dynamic String): records length and pre-allocates space compared to C strings, avoiding buffer overflow and supporting binary safety.
ziplist / listpack: compact contiguous-memory lists that save space and suit small data volumes.
linkedlist: a doubly-linked list that replaces ziplist when there are many elements.
dict (dictionary): a hash table using chaining for collisions, with progressive rehash to avoid blocking.
skiplist (skip list): a multi-level ordered linked list, combined with dict to implement zset for efficient range queries.

Encodings and Conversions per Type

Type	Small-data encoding	Large-data encoding	Conversion threshold (illustrative)
string	int / embstr	raw	length > 44 bytes becomes raw
hash	ziplist/listpack	hashtable	element count or single value exceeds threshold
list	quicklist (ziplist segments)	quicklist	—
set	intset	hashtable	contains non-integers or too many elements
zset	ziplist	skiplist+dict	element count or value length exceeds threshold

Taking zset as an example, small data uses a compact ziplist (member and score adjacent); when the element count or a single member length exceeds the threshold it converts to skiplist + dict, ensuring ordered traversal and member lookup are O(1)/O(log n).

Redis Cache Design

Tue, 25 Aug 2026 00:00:00 +0000

Introducing a cache dramatically reduces database pressure, but poor design introduces the classic problems of penetration, breakdown and avalanche. We break down the causes and countermeasures below.

The Three Classic Problems

Cache penetration: querying data that does not exist, so neither cache nor DB returns it and every request hits the DB. Mitigate with caching empty values (short TTL) or a Bloom filter to block illegal keys.
Cache breakdown: the moment a hot key expires, many concurrent requests all fall back to the DB at once. Mitigate with a mutex (only one thread rebuilds), logical expiration (async refresh), or never-expire hot keys.
Cache avalanche: a large number of keys expire simultaneously, or Redis becomes entirely unavailable, overwhelming the DB. Mitigate with random jitter on expiration times, multi-level caching, and Redis high availability (Sentinel/Cluster).

Cache-Aside and Consistency