20 Essential Redis Interview Questions Every Engineer Should Know

Preface

Hello, I am a small boy who collects snails. With the golden‑nine and silver‑ten season approaching, I have compiled 20 classic Redis interview questions hoping they help you.

1. What is Redis and what is it used for?

Redis (Remote Dictionary Server) is an open‑source, ANSI‑C written, network‑enabled, in‑memory (with optional persistence) key‑value store that provides APIs for many languages.

Unlike MySQL, Redis stores data in memory, offering sub‑millisecond read/write speed (over 100k ops/s). It is widely used as a cache, distributed lock, and supports transactions, persistence, Lua scripts, LRU eviction, and various clustering solutions.

2. Basic Redis data structures

Redis provides five core types:

String

Hash

List

Set

Zset (sorted set)

And three special types:

Geospatial

HyperLogLog

Bitmap

2.1 Five basic data types

String

Overview: binary‑safe, can store images or serialized objects, max size 512 MB.

Simple usage: set key value, get key Use cases: shared session, distributed lock, counters, rate limiting.

Internal encoding: int (8‑byte), embstr (≤39 bytes), raw (>39 bytes).

Redis implements strings with SDS (simple dynamic string). The source code is:

struct sdshdr{<br/>  unsigned int len;   // length of buf<br/>  unsigned int free;  // free space in buf<br/>  char buf[];          // actual data<br/>}

Why does Redis prefer SDS over native char[]? Because SDS can obtain the string length in O(1) time, while C strings require O(n) traversal.

In SDS, getting the length is O(1), whereas a C string needs to scan the whole buffer (O(n)).

Hash

Overview: a value that itself is a key‑value map.

Simple usage: hset key field value, hget key field Internal encoding: ziplist (compressed list) or hashtable.

Use cases: caching user information.

Note: using hgetall on large hashes may block; prefer hscan or hmget for partial fields.

String vs Hash comparison diagram:

List

Overview: ordered collection of strings, up to 2^32‑1 elements.

Simple usage: lpush key value [value ...], lrange key start end Internal encoding: ziplist or linkedlist.

Use cases: message queue, article list.

Insertion and removal illustration:

lpush + lpop = Stack lpush + rpop = Queue lpush + ltrim = Capped collection lpush + brpop = Message queue

Set

Overview: collection of unique strings.

Simple usage: sadd key element [element ...], smembers key Internal encoding: intset (integer set) or hashtable.

Note: smembers and lrange / hgetall are heavy; use sscan for large sets.

Use cases: user tags, random draw, social features.

Sorted Set (zset)

Overview: ordered set of unique strings.

Simple usage: zadd key score member [score member ...], zrank key member Internal encoding: ziplist or skiplist.

Use cases: leaderboards, social likes.

2.2 Three special data types

Geo: introduced in Redis 3.2 for geolocation storage and queries.

HyperLogLog: cardinality estimator for unique visitor counting.

Bitmap: bit‑level mapping built on top of the string type, useful for massive boolean arrays.

3. Why is Redis so fast?

3.1 In‑memory storage

Memory read/write is far faster than disk I/O, so Redis avoids the disk bottleneck that MySQL suffers.

3.2 Efficient data structures

MySQL uses B+ trees for indexes; Redis uses purpose‑built structures that make operations faster.

SDS (Simple Dynamic String)

String length: O(1) in Redis vs O(n) in C. Pre‑allocation reduces memory‑allocation overhead. Lazy free: freed space is kept for future writes. Binary safety: can store data containing '\0'.

Dictionary

All keys are stored in hash tables, giving O(1) lookup.

Skiplist

Skiplist is a Redis‑specific structure built on linked lists with multi‑level indexes. Average O(log N), worst O(N) lookup.

3.3 Reasonable data encoding

Redis chooses the most efficient internal encoding for each data type based on size and content (e.g., int, embstr, raw for strings; ziplist vs hashtable for hashes; intset vs hashtable for sets; ziplist vs skiplist for zsets).

String: int for numbers; embstr for ≤39 bytes; raw for larger. List: ziplist if <512 elements and each <64 bytes; otherwise linkedlist. Hash: ziplist if <512 fields and each <64 bytes; otherwise hashtable. Set: intset if all integers and <512 elements; otherwise hashtable. Zset: ziplist if <128 elements and each <64 bytes; otherwise skiplist.

3.4 I/O multiplexing

I/O multiplexing

Redis uses epoll for efficient I/O multiplexing, converting connections, reads, writes, and closures into events, minimizing time spent on network I/O.

What is I/O multiplexing?

I/O: network I/O Multiplex: multiple connections Reuse: same thread handles all. It blocks only when no file descriptor is ready.

3.5 Single‑thread model

Redis runs a single thread for command execution, avoiding context switches and lock contention. Long‑running commands (e.g., hgetall) can block the server.

Redis 6.0 introduced optional worker threads for I/O and protocol parsing, while command execution remains single‑threaded.

3.6 Virtual memory mechanism

Redis swaps cold data to disk to free memory, keeping hot data in RAM. This prevents out‑of‑memory crashes.

4. Cache penetration, avalanche, and breakdown

4.1 Cache penetration

Typical cache flow: read → cache hit returns; miss → query DB → write back to cache → return.

Cache penetration occurs when a request queries a non‑existent key; the cache miss leads to a DB query each time, exhausting DB resources.

In plain terms, both cache and DB miss for a key, causing every request to hit the DB.

Common causes:

Unreasonable business design (e.g., querying a guard flag for every user when most users have none).

Operational mistakes (accidental deletion of cache and DB data).

Malicious attacks that deliberately request non‑existent keys.

How to avoid it? Three typical methods:

Validate request parameters at the API gateway to filter illegal values.

Cache a placeholder (null or default) when DB returns empty, with a proper TTL, and update it on writes.

Use a Bloom filter to quickly test existence before hitting DB.

Bloom filter: a bit array plus multiple hash functions; if all bits are 1 the element probably exists, otherwise it definitely does not.

4.2 Cache avalanche

Cache avalanche happens when many keys expire simultaneously, causing a massive surge of DB queries and possible downtime.

Mitigation: stagger expiration times (e.g., add a random offset to a base TTL).

Ensure high‑availability Redis clusters to survive node failures.

4.3 Cache breakdown

Cache breakdown occurs when a hot key expires and a flood of concurrent requests directly hit the DB.

It is essentially a subset of avalanche focused on a single hot key.

Solutions (two common approaches):

Mutex lock: when a key expires, acquire a lock (e.g., setnx) before loading from DB; other requests retry.

“Never expire”: keep the key without TTL and proactively refresh it before expiration.

5. Hot key problem and solutions

A hot key is a key accessed at very high frequency, potentially overwhelming a single Redis node.

Causes:

Read‑heavy, write‑light scenarios (e.g., flash sales, hot news). Key hash slot concentration causing a single node to receive disproportionate traffic.

Identification methods:

Experience‑based judgment. Client‑side statistics reporting. Proxy‑layer monitoring.

Mitigation strategies:

Scale the Redis cluster (add shards/replicas) to distribute load. Distribute hot keys across different nodes (e.g., using different prefixes). Introduce a second‑level cache (local JVM cache) to reduce Redis reads.

6. Expiration and memory‑eviction policies

6.1 Expiration strategies

When setting a key (e.g., set key), you can assign an expiration with expire key 60. Redis provides three strategies:

Timed expiration

Each key with TTL creates a timer; when it fires, the key is removed immediately. Fast memory reclamation but CPU‑intensive.

Lazy expiration

Key is checked for expiry only when accessed. Saves CPU but may leave many expired keys in memory.

Periodic expiration

Redis randomly samples a subset of keys with TTL at regular intervals and deletes the expired ones, balancing CPU and memory usage.

Redis combines lazy and periodic expiration.

Scanning all 300k keys every 100 ms would overload CPU.

Instead, Redis samples a limited number of keys every 100 ms.

If a key is missed by periodic scans, lazy deletion cleans it on next access.

6.2 Memory‑eviction policies

volatile‑lru – LRU among keys with an expiration. allkeys‑lru – LRU among all keys. volatile‑lfu – LFU among keys with an expiration (Redis 4.0+). allkeys‑lfu – LFU among all keys (Redis 4.0+). volatile‑random – Random eviction among keys with an expiration. allkeys‑random – Random eviction among all keys. volatile‑ttl – Evict keys with the nearest expiration time. noeviction – Reject writes when memory is full.

7. Common Redis use cases

Cache

Leaderboard

Counter

Shared session

Distributed lock

Social network features

Message queue

Bit operations

7.1 Cache

Cache hot data to improve response time and reduce DB load. Redis offers richer data structures and persistence (RDB/AOF) compared to Memcached.

7.2 Leaderboard

Sorted sets ( zset) enable efficient ranking, e.g., daily video likes:

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

7.3 Counter

Atomic increment operations ( INCR, INCRBY) support high‑throughput counting for views, likes, etc.

7.4 Shared session

Store user session data centrally in Redis to avoid repeated logins across distributed web servers.

7.5 Distributed lock

Use setnx or the extended SET key value NX EX ttl command to acquire a lock; release with a Lua script that checks ownership.

7.6 Social network

Features like likes, followers, mutual friends can be modeled with sets, sorted sets, and hash maps.

7.7 Message queue

Redis provides Pub/Sub and blocking list commands to build simple queues, though dedicated MQs (Kafka, RabbitMQ) are more robust.

7.8 Bit operations

Bitmaps enable massive‑scale boolean tracking (e.g., user sign‑in, online status) with SETBIT, GETBIT, BITCOUNT.

8. Persistence mechanisms

Redis is in‑memory; to avoid data loss it offers persistence.

8.1 RDB (snapshot)

Periodically forks a child process ( bgsave) to write a snapshot ( dump.rdb) to disk. Advantages: fast backup, suitable for full replication. Disadvantages: not real‑time, version compatibility issues.

8.2 AOF (append‑only file)

Logs every write operation; on restart, Redis replays the AOF to rebuild state. Provides higher durability but larger files and slower recovery.

9. High availability

Redis is rarely deployed as a single node; HA is achieved via replication and failover.

9.1 Master‑slave replication

Master handles reads/writes; slaves replicate data for read‑only queries. Replication includes full sync (RDB + buffered writes) and incremental sync.

9.2 Sentinel

Sentinel monitors masters and slaves; upon master failure, it promotes a slave to master and notifies clients. Multiple Sentinels avoid single‑point failure.

9.3 Cluster

Redis Cluster shards data across 16384 hash slots, each node responsible for a subset. Nodes communicate via the Gossip protocol (PING, PONG, MEET, FAIL) and a cluster bus on port +10000.

MEET – node joins cluster. PING – health check. PONG – response. FAIL – broadcast node down.

Slots are allocated via CRC16 modulo 16384; clients can connect to any node; if a key maps to a different node, Redis redirects the request.

10. Distributed lock implementations

Common patterns and pitfalls: setnx + expire (risk of dead lock if process crashes before setting TTL).

Store expiration timestamp as value (requires synchronized clocks, no owner ID).

Extended SET key value NX EX ttl (still vulnerable to lock release by others).

Extended SET with unique value + Lua script for safe release.

10.1 setnx + expire

if (jedis.setnx(key, lock_value) == 1) {<br/>    expire(key, 100);<br/>    try { /* business */ } finally { jedis.del(key); }<br/>}

If the process crashes after setnx but before expire, the lock never expires.

10.2 setnx with timestamp value

long expires = System.currentTimeMillis() + ttl;<br/>if (jedis.setnx(key, String.valueOf(expires)) == 1) return true;<br/>String cur = jedis.get(key);<br/>if (cur != null && Long.parseLong(cur) < System.currentTimeMillis()) {<br/>    String old = jedis.getSet(key, String.valueOf(expires));<br/>    if (old != null && old.equals(cur)) return true;<br/>}<br/>return false;

Problems: clock drift, no owner identifier, race conditions on expiration.

10.3 SET with NX EX

if (jedis.set(key, lock_value, "NX", "EX", 100) == 1) {<br/>    try { /* business */ } finally { jedis.del(key); }<br/>}

Issues: lock may expire before business finishes; other threads may delete it.

10.4 SET with unique value + Lua release

if (jedis.set(key, uniqId, "NX", "EX", 100) == 1) {<br/>    try { /* business */ } finally {<br/>        if (uniqId.equals(jedis.get(key))) { jedis.del(key); }<br/>    }<br/>}

Better to use an atomic Lua script:

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

11. Redisson watch‑dog

Redisson starts a background thread that periodically (every 10 s) extends the lock TTL while the owning thread holds the lock, preventing premature expiration.

12. Redlock algorithm

To avoid single‑master failure, Redlock acquires locks on multiple independent Redis masters (e.g., 5). Steps:

Record start time. Try to lock each master with SET NX PX ttl , respecting a short network timeout. If locks are obtained on a majority (N/2+1) and total elapsed time < ttl, consider the lock successful. Adjust effective TTL by subtracting elapsed time. On failure, unlock all masters.

13. Redis skiplist

Skiplist is one of the underlying implementations for zset, offering average O(log N) lookup and O(N) worst‑case.

14. MySQL‑Redis consistency

14.1 Delayed double delete

Workflow: delete cache → update DB → sleep (≈ read‑time + few hundred ms) → delete cache again.

If the second delete fails, data may become inconsistent; a short TTL can mitigate but not eliminate the risk.

14.2 Delete‑retry mechanism

On delete failure, push the key to a message queue; a consumer retries deletion until success.

14.3 Binlog‑based async delete

Capture MySQL binlog (e.g., via Canal), send update events to MQ, and asynchronously delete corresponding Redis keys, ensuring eventual consistency without code intrusion.

15. Why Redis 6.0 introduced multithreading?

Pre‑6.0 Redis handled all I/O, parsing, execution, and networking in a single thread.

CPU is rarely the bottleneck; network I/O dominates.

Redis 6.0 adds optional worker threads for I/O and protocol parsing, while command execution stays single‑threaded, improving throughput.

16. Transactions

Redis supports transactions via MULTI, EXEC, WATCH, etc. Commands are queued after MULTI and executed atomically on EXEC. WATCH aborts the transaction if watched keys change.

Command

Description

EXEC

Execute all queued commands.

DISCARD

Cancel the transaction.

MULTI

Start a transaction block.

UNWATCH

Remove all watches.

WATCH

Watch keys for modifications.

17. Hash collisions

Redis stores all keys in a global hash table. Collisions are resolved with chaining (linked list per bucket). To keep lookup O(1), Redis performs rehashing by allocating a larger table and gradually moving entries.

18. Can Redis handle writes while generating RDB?

Yes. SAVE blocks the main thread; BGSAVE forks a child process to write the snapshot, allowing the parent to continue serving requests.

19. Redis protocol

Redis uses RESP (Redis Serialization Protocol), a simple, fast, and human‑readable protocol introduced in version 2.0.

20. Bloom filter

Bloom filters are space‑efficient probabilistic structures for membership testing, using a bit array and multiple hash functions. They have false‑positive probability but no false negatives. Adding more hash functions or increasing the bit array size reduces error.

Implementation libraries include Google Guava, Twitter Algebird, or custom Redis‑based bitmaps.

References

[1] Redis high‑availability solutions summary – https://www.jianshu.com/p/5de2ab291696

[2] Redis cluster high‑availability – https://www.cnblogs.com/leeSmall/p/8414687.html