Redis Interview Guide: Databases, Keyspace, Expiration, and Memory Eviction Strategies

1. Redis Database

1.1 Understanding Redis Databases

Interviewer: Do you know about Redis databases?

Redis databases are analogous to MySQL databases; each database is isolated, so a key set in database 1 is invisible in database 2.

# 示例命令
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> set name JavaGetOffer
OK
127.0.0.1:6379[1]> select 2
OK
127.0.0.1:6379[2]> get name
(nil)
127.0.0.1:6379[2]> select 1
OK
127.0.0.1:6379[1]> get name
"JavaGetOffer"

Redis creates 16 databases by default, allowing developers to separate data for different business domains.

# 查询一共有几个数据库
127.0.0.1:6379> config get databases
1) "databases"
2) "16"

The database consists of two dictionaries: the dict (keyspace) and the expires dictionary (expiration data).

1.2 Database Keyspace

Interviewer: What about the keyspace?

The keyspace is the container that stores all keys; it is implemented as a dictionary (dict) inside Redis.

Do not confuse this low‑level dict with the higher‑level hash data type that Redis exposes to users.

The keyspace diagram shows that each key in the dict points to the address of its value.

All CRUD operations on Redis keys are based on the keyspace: Redis first looks up the key in the dict, then accesses the associated value.

1.3 Key Expiration Time

Interviewer: How do you set an expiration time for a key?

First set the key, then use the EXPIRE command (seconds) to define its TTL.

127.0.0.1:6379> set name0 JavaOffer训练营
OK
127.0.0.1:6379> expire name0 66
(integer) 1
127.0.0.1:6379> ttl name0
(integer) 66
127.0.0.1:6379> get name0
"JavaOffer训练营"

You can also use SETEX to set the value and expiration in one step.

127.0.0.1:6379> setex name 66 JavaGetOffer
OK
127.0.0.1:6379> ttl name
(integer) 66
127.0.0.1:6379> get name
"JavaGetOffer"

When answering interview questions, mentioning the Java Jedis client method setex adds practical depth.

public String setex(String key, int seconds, String value) {
    this.checkIsInMultiOrPipeline();
    this.client.setex(key, seconds, value);
    return this.client.getStatusCodeReply();
}

1.4 Expiration Dictionary

Interviewer: How is the expiration time stored?

Expiration times are kept in a separate dictionary whose keys point to the same entries in the keyspace, while the values are UNIX timestamps (long long).

2. Memory Reclamation Strategies

2.1 Expired‑Key Deletion Strategies

Interviewer: What are the strategies for deleting expired keys?

Redis provides three deletion strategies: timed deletion, lazy deletion, and periodic deletion. Timed and periodic are proactive; lazy is reactive.

Each strategy has trade‑offs and fits different scenarios.

1. Timed deletion creates a timer for each key with an expiration, which frees memory promptly but can consume CPU when many timers fire.

2. Lazy deletion frees memory only when an expired key is accessed, saving CPU but potentially leaving many expired keys in memory.

3. Periodic deletion scans a subset of keys at configurable intervals, deleting expired ones; it requires careful tuning of frequency and duration.

In practice, Redis combines lazy deletion and periodic deletion to balance CPU load and memory usage.

2.2 Memory Eviction Policies

Interviewer: How does Redis release memory when it reaches the max‑memory limit?

When memory reaches the configured limit, Redis applies an eviction policy defined by the maxmemory-policy setting.

127.0.0.1:6379> config set maxmemory 1GB
OK
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "1073741824"

The six built‑in policies are:

noeviction : refuse writes when memory is full.

volatile-lru : evict least‑recently‑used keys with an expiration.

allkeys-lru : evict LRU keys regardless of expiration.

allkeys-random : evict random keys.

volatile-random : evict random keys that have an expiration.

volatile-ttl : evict keys with the nearest expiration time.

These policies are implemented with approximated LRU/LFU or random algorithms; if no suitable key exists, Redis returns an error on write operations.

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory is reached.
# volatile-lru -> Evict using approximated LRU among the keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key among the ones with an expire set.
# allkeys-random -> Remove a random key, any key.
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL).
# noeviction -> Don't evict anything, just return an error on write operations.
# The default is: maxmemory-policy noeviction