Redis Interview Questions and Answers: Persistence, Caching Issues, Data Types, Clustering, and More

Redis Persistence Mechanism

Redis supports persistence by synchronizing in‑memory data to disk, allowing data recovery after a restart. The default RDB snapshot method saves data periodically to a binary dump file, while AOF appends every write command to a log for replay on restart; when both are enabled, AOF takes precedence.

Cache Problems (Avalanche, Penetration, Pre‑heat, Update, Degradation)

Cache Avalanche

Occurs when many keys expire simultaneously, causing a sudden surge of database queries that can overload the DB and crash the system.

Solution

Distribute expiration times, use locking or queuing to limit concurrent DB access.

Cache Penetration

When a request queries a non‑existent key, it bypasses the cache and hits the DB each time.

Solution

Use Bloom filters to filter impossible keys, or cache empty results with a short TTL.

Cache Penetration vs. Cache Breakdown

Cache breakdown (or “击穿”) happens when a hot key expires and massive concurrent requests hit the DB; using SETNX to create a short‑lived lock can mitigate this.

Cache Pre‑heat

Load frequently accessed data into the cache proactively during system startup or via scheduled jobs.

Cache Update

Two common strategies: periodic cleanup of expired entries, or on‑demand validation and refresh when a request finds stale data.

Cache Degradation

When the system is under heavy load or a service fails, degrade gracefully by returning default values or disabling cache reads for non‑critical data.

Hot Data vs. Cold Data

Hot data is accessed frequently and benefits from caching; cold data is rarely accessed and may be evicted quickly.

Differences Between Memcached and Redis

Redis offers persistence, richer data types (list, set, sorted set, hash), larger value size (up to 512 MB), replication, and more features, whereas Memcached stores only simple strings in memory without persistence.

Why Redis Is Fast with a Single Thread

Because it performs pure in‑memory operations, avoids context switches, and uses non‑blocking I/O multiplexing.

Redis Data Types and Use Cases

String

Simple key/value, often used for counters.

Hash

Stores structured objects, useful for session‑like data.

List

Implements queues and pagination.

Set

Provides deduplication and set operations.

Sorted Set

Supports ranking and leaderboard scenarios.

Redis Internal Structures

dict – hash table for key‑value mapping.

sds – dynamic string implementation.

skiplist – efficient ordered data structure.

quicklist, ziplist – compact list representations.

Expiration Strategies and Memory Eviction

Redis uses periodic and lazy deletion; when memory is full, configurable eviction policies (volatile‑lru, volatile‑ttl, volatile‑random, allkeys‑lru, allkeys‑random, no‑eviction) determine which keys to discard.

maxmemory-policy volatile-lru1<br/>

Why Redis Is Single‑Threaded

CPU is not the bottleneck; memory and network dominate, so a single thread simplifies design and avoids contention.

Redis Cluster Solutions

Options include Twemproxy (proxy with consistent hashing), Codis (proxy with data migration support), and native Redis Cluster (hash slots and built‑in replication).

Multi‑Machine Deployment and Data Consistency

Master‑slave replication provides read‑write separation and eventual consistency.

Handling High Request Volumes

Redis leverages I/O multiplexing (select, epoll, kqueue) to serve many clients concurrently despite its single‑threaded core.

Common Performance Issues and Solutions

Avoid persistence on the master.

Enable AOF on a slave for critical data.

Place master and slaves in the same LAN.

Limit the number of slaves on a heavily loaded master.

Prefer linear replication chains over complex topologies.

Redis Thread Model

File event handlers manage socket I/O, dispatch events, and process them sequentially using the I/O multiplexer.

Atomicity in Redis

All commands are atomic because Redis processes them in a single thread; transactions (MULTI/EXEC) guarantee atomic execution of a batch of commands.

Redis Transactions

Implemented via MULTI, EXEC, DISCARD, and WATCH; commands are queued and executed atomically, with limited rollback capabilities.

Distributed Lock with Redis

Use SETNX to acquire a lock and DEL to release it; add an expiration (EXPIRE) to avoid deadlocks, or combine SETNX with GETSET for safer lock renewal.