Mastering Redis Architecture: From Data Models to Persistence Strategies

Why Build a Redis Architecture First

Redis is a complex system; diving straight into low‑level details like connection pools or specific data structures can lead to getting lost in minutiae. Understanding the overall architecture provides a framework for deeper exploration.

Key Considerations for a KV Database

Data Model : Determines what kind of data can be stored. For example, a user ID mapping to name, age, gender, etc., is a typical KV use case.

Operation Interface : Defines how data can be manipulated. Simple CRUD operations are supported, but complex aggregations (e.g., computing average age across users) are not.

Data Model

Redis supports multiple value types beyond simple strings, such as hashes, lists, and sets, making it more versatile than Memcached, which only supports string values.

Operation Interface

PUT – create or update a key‑value pair.

GET – retrieve the value for a given key.

DELETE – remove a key‑value pair.

SCAN – iterate over a range of keys.

Memory vs. Disk Storage

In‑memory storage offers nanosecond‑level latency but data is lost on power failure.

Disk‑based storage prevents data loss but incurs millisecond‑level latency, reducing overall performance.

Access Pattern Selection

Embedding the KV store in a library (e.g., libsimplekv.so) for direct programmatic use.

Exposing the KV store via a network service (e.g., Memcached, Redis) using socket communication.

I/O Model Design

A single thread handling network I/O, request parsing, and data access can become a bottleneck when any step blocks. Using multiple threads isolates blocking operations but introduces thread‑contention when accessing shared resources.

KV Pair Positioning and Indexing

Redis and Memcached use hash tables for indexing, while RocksDB uses skip lists. Hash tables provide O(1) lookup for in‑memory KV stores, matching their random‑access characteristics.

Specific Operation Logic

GET/SCAN – locate the value and return it.

PUT – allocate memory for the new KV pair.

DELETE – free the memory occupied by the KV pair.

Fast Service Recovery After Restart

Memory fragmentation can degrade performance when KV pairs vary in size. Redis includes multiple memory allocators to mitigate this. Persistence mechanisms (full snapshot, periodic AOF) balance durability against write performance.

Persistence Strategies

Persist every KV pair immediately – high durability but low performance.

Periodically flush in‑memory data to disk – better performance with some risk of data loss.

Redis combines these techniques to provide a fast, durable KV store suitable for a wide range of applications.

PUT java edge