Mastering Redis: Key Design and Data‑Type Use Cases

Redis Core Characteristics

All data resides in memory, providing sub‑millisecond read/write latency.

Supports a rich set of data structures: string , hash , set , sorted set , bitmap , hyperloglog .

Persistence via AOF (Append‑Only File) and RDB snapshots prevents data loss on restart.

Every command is atomic; multi‑command transactions are also atomic.

Key Naming Convention

Use colon‑separated segments to encode the logical hierarchy of a key. A typical pattern is: table:primaryKeyField:primaryKeyValue:field For a user table this yields keys such as:

SET user:id:1:email [email protected]
SET user:id:2:email [email protected]

String Type

Overview

Binary‑safe key‑value pairs. The value can be plain text, JSON, or any binary payload (e.g., JPEG).

Typical Use Cases

Cache a single column – store a MySQL field directly in Redis: SET user:id:1:email [email protected] Store a JSON object – useful for small objects when a hash is not required:

SET user:id:1 {"id":1,"name":"zj","email":"[email protected]"}

Atomic counters – when the string holds an integer, INCR and DECR are lock‑free and safe across clients:

INCR page:views

Hash Type

Overview

A hash stores a map of field‑value pairs under a single key, analogous to a row in a relational table.

Example Model

Given a relational user table (id, name, email), the same data can be represented as:

HSET user:1 name "zj" email "[email protected]"
HSET user:2 name "ai" email "[email protected]"

Hashes are more memory‑efficient than storing the same data as a JSON string because each field is stored separately without the overhead of parsing.

List Type

Overview

Lists are ordered collections implemented as doubly linked lists. LPUSH / RPUSH insert elements at the head or tail in O(1) time. When a list becomes empty Redis automatically deletes the key.

Common Scenarios

Message queue – push new messages to the head and pop from the tail:

LPUSH queue "msg1"
RPOP queue

Recent‑content feed – keep the newest items at the head; optionally trim with LTRIM queue 0 99 to retain only the latest 100 entries.

Set Type

Overview

Sets store unique, unordered elements. All basic operations (add, remove, membership test) run in O(1). Redis provides native set algebra: intersection, union, and difference.

Use Cases

Common friends list – store each user's friends in a set and compute mutual friends with SINTER:

SADD user:wade james melo paul kobe
SADD user:james wade melo paul kobe
SINTER user:wade user:james

Tag intersection – intersect tag sets to retrieve articles that share multiple tags.

Sorted Set (ZSet) Type

Overview

Each member is associated with a floating‑point score; Redis keeps the members sorted by score automatically.

Examples

Friend intimacy ranking – store a score that reflects closeness and retrieve the ranking in descending order:

ZADD user:kobe 80 james
ZADD user:kobe 90 wade
ZREVRANGE user:kobe 0 -1

Content ranking – use view count, likes, or any metric as the score to sort articles, videos, etc.