Master Redis Interview: Persistence, Caching Strategies, Clustering & More

Redis Persistence Mechanism

Redis is an in‑memory database that supports persistence by synchronizing data to disk. It forks a child process that copies the parent’s data and writes it to a temporary file, which then replaces the previous snapshot.

RDB is the default snapshot‑based persistence, creating dump.rdb according to the save schedule. AOF appends every write command to a log file, similar to MySQL binlog; on restart Redis replays the log. When both are enabled, AOF recovery takes precedence.

Cache Problems and Solutions

Cache Avalanche : When many cached keys expire simultaneously, a flood of requests hits the database, potentially causing a crash. Solution : Use staggered expiration times or lock/queue mechanisms to limit concurrent database access.

Cache Penetration : Requests for nonexistent data bypass the cache and repeatedly hit the database. Solution : Deploy a Bloom filter to filter impossible keys, or cache empty results with a short TTL (e.g., five minutes).

Cache Pre‑warming : Load hot data into the cache before the system goes live, either manually, at startup, or via scheduled refreshes.

Cache Update : Besides Redis’s built‑in expiration policies, you can implement timed cleanup or on‑demand validation to refresh stale entries.

Cache Degradation : During traffic spikes or service degradation, return default values for non‑critical data to keep core services available.

Hot vs. Cold Data

Hot data is accessed frequently and benefits from caching (e.g., birthday lists, navigation info). Cold data is rarely accessed and may be evicted quickly, offering little caching value.

Memcached vs. Redis

1) Storage: Memcached stores data only in memory; Redis can persist to disk. 2) Data Types: Memcached handles simple strings, while Redis supports strings, lists, sets, sorted sets, hashes, etc. 3) Architecture: Different underlying implementations and protocols. 4) Value Size: Redis supports values up to 512 MB; Memcached limits to 1 MB. 5) Performance: Redis is generally faster. 6) Replication: Redis offers master‑slave replication.

Why Single‑Threaded Redis Is Fast

Redis performs pure memory operations, avoids context switches with a single thread, and uses non‑blocking I/O multiplexing (select/epoll/kqueue).

Redis Data Types and Use Cases

String : Basic get/set, suitable for simple values and counters. Hash : Stores structured objects; useful for session‑like data. List : Implements simple queues, pagination, or ordered streams. Set : Provides global deduplication and set operations (union, intersection). Sorted Set : Enables ranking and top‑N queries with scores.

Redis Internal Structures

dict – hash table for key‑value mapping.

sds – simple dynamic string storing binary data with length.

skiplist – high‑performance ordered list used by sorted sets.

quicklist – linked list of ziplist nodes for efficient list storage.

ziplist – compact sequential encoding for small collections.

Expiration and Eviction Policies

Redis uses a combination of periodic and lazy deletion. Every 100 ms it randomly samples keys with expiration times and removes expired ones; when a key is accessed, its TTL is checked (lazy deletion).

When memory is full, the maxmemory-policy setting determines eviction:

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

volatile‑ttl : evicts keys that are about to expire.

volatile‑random : evicts random keys with an expiration.

allkeys‑lru : evicts least‑recently‑used keys regardless of expiration.

allkeys‑random : evicts random keys.

noeviction : disables eviction; writes fail when memory is exhausted.

Redis Thread Model

Redis relies on an I/O multiplexing engine to monitor multiple sockets. Events such as accept, read, write, and close are dispatched to handlers sequentially, ensuring only one operation runs at a time.

Atomicity in Redis

All Redis commands are atomic because the server processes them in a single thread. Transactions (MULTI/EXEC) guarantee atomic execution of a batch, while Lua scripts can provide complex atomic operations.

Redis Transactions

Transactions are built from four primitives:

MULTI – starts a transaction queue.

EXEC – executes all queued commands.

DISCARD – aborts the transaction.

WATCH – monitors keys for changes to implement check‑and‑set semantics.

Distributed Lock with Redis

Use SETNX (or SET key value NX EX ttl) to acquire a lock; DEL releases it. To avoid deadlocks, set an expiration on the lock key.

Redis Cluster Solutions

1) twemproxy : a proxy that forwards requests using consistent hashing; limited by a single port and manual data migration.

2) codis : similar to twemproxy but supports automatic data rebalancing when nodes change.

3) Redis Cluster 3.0 : native clustering with hash slots and built‑in replica support.

Multi‑Machine Deployment and Consistency

Master‑slave replication provides read‑write separation; the master handles writes and propagates changes to slaves, which serve read traffic.

Handling Massive Requests

Redis processes many client connections via I/O multiplexing (select/epoll/kqueue), allowing a single thread to handle concurrent requests efficiently.

Common Performance Issues and Mitigations

Avoid persisting on the master; use slaves for AOF if needed.

Place master and slaves in the same LAN for low latency.

Do not chain many slaves; a linear replication chain can become a bottleneck.