Redis Deep Dive: 20 Classic Interview Questions Explained

What is Redis?

Redis (Remote Dictionary Server) is an open‑source, ANSI‑C key‑value store that can keep data entirely in memory or persist it to disk. Because all reads and writes operate on RAM, a single instance can handle >100 000 operations per second, making it ideal for caching, distributed locks, sessions, counters, and more.

Data Types and Internal Encodings

Basic Types

String – binary‑safe, up to 512 MiB. Commands: SET key value, GET key. Internal encoding chooses the most efficient representation: int for 8‑byte integers, embstr for strings ≤39 bytes, otherwise raw. Redis implements strings with SDS (simple dynamic string) which stores length in a header, giving O(1) length retrieval versus O(n) for C char[].

Hash – a map of field/value pairs. Commands: HSET key field value, HGET key field. Small hashes (< 512 fields and each value < 64 bytes) use a ziplist; larger ones use a hashtable. Use HSCAN or HMGET instead of HGETALL on large hashes to avoid blocking.

List – ordered collection of strings (max 2³²‑1 elements). Commands: LPUSH key value [value …], LRANGE key start end. Encoding: ziplist when < 512 elements and each element < 64 bytes; otherwise a doubly‑linked list. Typical patterns: LPUSH+LPOP (stack), LPUSH+RPOP (queue), LPUSH+LTRIM (capped collection), LPUSH+BRPOP (blocking queue).

Set – unordered collection of unique strings. Commands: SADD key member [member …], SMEMBERS key. Encoding: intset for small integer sets, otherwise hashtable. Use SSCAN for large sets.

Sorted Set (zset) – unique strings ordered by a floating‑point score. Commands: ZADD key score member [score member …], ZRANK key member. Encoding: ziplist when ≤128 elements and each element < 64 bytes; otherwise a skiplist (see below).

Special Types

Geospatial (Redis 3.2+) – stores latitude/longitude and provides radius queries.

HyperLogLog – probabilistic cardinality estimator (e.g., UV counting).

Bitmap – bit‑level mapping built on top of strings, useful for massive boolean flags.

Why Redis Is Fast

In‑Memory Storage

All data resides in RAM, eliminating disk I/O latency that dominates relational databases such as MySQL.

Optimized Data Structures

Redis uses structures that give O(1) or O(log N) complexity:

SDS – O(1) length, pre‑allocated free space, lazy free, binary safety.

Dictionary (hash table) – O(1) key lookup for the global keyspace.

Skiplist – underlying implementation of sorted sets; average O(log N) search, worst‑case O(N), and efficient range traversal.

Smart Encoding Rules

String:   int   (numeric) / embstr (≤39 B) / raw   (>39 B)
List:     ziplist (≤512 elems & each ≤64 B) else linkedlist
Hash:     ziplist (≤512 fields & each ≤64 B) else hashtable
Set:      intset (small integer set) else hashtable
Zset:     ziplist (≤128 elems & each ≤64 B) else skiplist

Thread Model

Redis executes commands in a single thread, avoiding context‑switch overhead and lock contention. I/O multiplexing (epoll) lets one thread handle thousands of connections. Since Redis 6.0 a small thread pool handles socket read/write and protocol parsing; command execution remains single‑threaded.

Virtual Memory

Redis can swap cold keys to disk via its own virtual‑memory mechanism, freeing RAM for hot data without invoking the OS page cache.

Cache Pitfalls and Mitigations

Cache Penetration

Repeated queries for non‑existent keys bypass the cache and hit the database each time.

Validate request parameters at the API gateway.

Cache a placeholder (e.g., empty string) for missing DB results with a short TTL.

Use a Bloom filter to pre‑check existence before querying Redis.

Cache Avalanche

Massive simultaneous expiration of many keys causes a sudden DB surge.

Stagger TTLs by adding a random offset (e.g., base 5 h + random 0‑1800 s).

Deploy Redis clusters with high availability.

Cache Breakdown (Hot‑Key Expiration)

When a hot key expires, many concurrent requests fall back to the DB.

Mutex lock pattern (e.g., SETNX) to serialize DB loads.

“Never expire” pattern – keep the key alive and refresh asynchronously.

Hot‑Key Problem

Hot keys receive disproportionate traffic, potentially saturating a single Redis node.

Detection: operational experience, client‑side statistics, or proxy reports.

Remedies: add shards/replicas, distribute hot keys across nodes, introduce a second‑level local cache.

Expiration Strategies and Memory Eviction

Expiration Strategies

Active (timed) expiration – a timer per key; CPU‑intensive.

Lazy expiration – TTL checked only on access; may leave dead keys in memory.

Periodic expiration – Redis samples a subset of keys every 100 ms, balancing CPU and memory.

Redis combines lazy and periodic expiration.

Eviction Policies (when maxmemory is reached)

volatile-lru

,

allkeys-lru

volatile-lfu

, allkeys-lfu (Redis 4.0+) volatile-random,

allkeys-random

volatile-ttl

noeviction

(default)

Typical Use Cases

Cache layer

Leaderboard (zset)

Counter

Shared session

Distributed lock

Social graph (sets, sorted sets)

Message queue (pub/sub, blocking list)

Bit operations (online/offline flags)

Leaderboard Example

ZADD user:ranking:2021-03-03 Jay 3
ZINCRBY user:ranking:2021-03-03 Jay 1
ZREM user:ranking:2021-03-03 John
ZREVRANGE user:ranking:2021-03-03 0 2

Persistence Mechanisms

RDB (Snapshot)

Periodically forks a child ( BGSAVE) that writes a dump.rdb file. On restart, Redis loads the snapshot.

Advantages: fast full backups, suitable for replication. Disadvantages: not real‑time, version‑compatibility issues.

AOF (Append‑Only File)

Every write command is appended to an AOF log; on restart the log is replayed.

Advantages: higher durability. Disadvantages: larger files, slower recovery.

High Availability

Master‑Slave Replication

Full sync flow (Redis 2.8+ uses PSYNC instead of SYNC for efficiency):

Slave sends SYNC / PSYNC to master.

Master runs BGSAVE to create an RDB snapshot.

Master buffers writes that occur during snapshot generation.

Master streams the RDB file to the slave.

Slave loads the snapshot.

Master replays the buffered writes to the slave.

Sentinel

Multiple Sentinel instances monitor masters and slaves. If a master is marked subjectively down, Sentinels vote; a majority promotes a slave, updates clients via Pub/Sub, and the new master takes over.

Cluster

Data is sharded across 16 384 hash slots. Nodes communicate via a Gossip protocol (messages: meet, ping, pong, fail) over a cluster bus (service port + 10000). Each node owns a subset of slots; on node failure the slots are reassigned after a majority vote.

Distributed Locks

Common patterns: SETNX + EXPIRE (unsafe if the process crashes between the two commands).

Store an absolute expiration timestamp as the value and use GETSET to acquire an expired lock (requires synchronized clocks).

Extended SET with NX EX (still vulnerable to premature expiry).

Extended SET with a unique token and delete via a Lua script for atomicity.

Lua script example (atomic check‑and‑delete):

if redis.call('get',KEYS[1]) == ARGV[1] then
  return redis.call('del',KEYS[1])
else
  return 0
end

Redisson Watchdog

Redisson starts a background watchdog thread that periodically extends the lock TTL while the owning thread is alive, preventing lock expiry before work finishes.

Redlock Algorithm

To avoid a single‑point failure, a client attempts to acquire the same lock on N independent Redis masters (e.g., N = 5). If it obtains the lock on a majority (⌊N/2⌋ + 1) within the lock’s TTL, the lock is considered acquired. On failure the client must release any partial locks.

Skiplist (Underlying Zset Structure)

Skiplist provides average O(log N) search, worst‑case O(N), and supports range queries by sequential traversal of the bottom level.

MySQL‑Redis Consistency Strategies

Delayed Double Delete

Delete the cache.

Update the DB.

Sleep ≈ (DB read time + a few hundred ms) and delete the cache again.

Delete‑Retry via Message Queue

Update the DB.

If cache deletion fails, push the key to a MQ.

Consumer retries deletion until success.

Binlog‑Based Async Deletion

Capture MySQL binlog events with tools such as Alibaba Canal, push change events to a queue, and delete the corresponding Redis keys after ACK.

Why Redis Added Multithreading in 6.0?

Network I/O, not CPU, was the bottleneck. Redis 6.0 introduces a small thread pool for socket read/write and protocol parsing, while command execution stays single‑threaded, improving overall throughput.

Transactions

Redis supports atomic command batches via MULTI / EXEC / WATCH: MULTI – start transaction (commands are queued). EXEC – execute queued commands sequentially. DISCARD – abort transaction. WATCH key … – abort EXEC if any watched key changes before execution.

Hash Collisions

Redis stores the global keyspace in a hash table with chaining. When the table grows, Redis performs incremental rehashing using a secondary table to keep lookups O(1).

RDB Generation Concurrency

SAVE

blocks the server; BGSAVE forks a child process to write the RDB, allowing the parent to continue serving clients.

Redis Serialization Protocol (RESP)

RESP is a simple, fast, human‑readable protocol introduced in Redis 1.2 and standardized in 2.0. It encodes commands and replies as bulk strings, arrays, integers, etc.

Bloom Filter for Cache Penetration

A Bloom filter uses a bit array and multiple hash functions to test set membership with a low false‑positive rate. Example with a 16‑bit array and a single hash function:

Insert elements d1, d2, d3 → set bits 2, 5, 2.

Query an element: if any of its hashed bit positions is 0, the element is definitely absent.

Adding more hash functions and a larger bit array reduces false positives.

Open‑source implementations include Google Guava, Twitter Algebird, or a custom implementation using Redis SETBIT / GETBIT commands.

References

[1] Redis 高可用解决方案总结 – https://www.jianshu.com/p/5de2ab291696

[2] Redis 集群高可用 – https://www.cnblogs.com/leeSmall/p/8414687.html