Redis Interview Questions and High‑Availability Distributed System Overview

1. What are the benefits of using Redis?

(1) Fast speed because data resides in memory, similar to a HashMap with O(1) lookup and operation complexity.

(2) Supports rich data types: string, list, set, sorted set, hash.

(3) Supports transactions; operations are atomic, meaning changes are either fully applied or not at all.

(4) Rich features: can be used for caching, messaging, key‑based expiration, and automatic deletion after expiration.

2. What advantages does Redis have over Memcached?

(1) Memcached only stores simple strings, while Redis supports richer data structures.

(2) Redis is generally faster than Memcached.

(3) Redis can persist data to disk.

3. How to ensure that only hot data is kept in Redis when MySQL holds 10 million rows but Redis stores only 100,000 rows?

Redis provides six eviction policies to manage memory when the dataset grows:

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

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

volatile‑random: evicts random keys with an expiration set.

allkeys‑lru: evicts least recently used keys among all keys.

allkeys‑random: evicts random keys among all keys.

no‑eviction: disables eviction.

4. Differences between Memcached and Redis

1) Storage method

Memcached stores all data in memory; data is lost on power failure and cannot exceed memory size.

Redis can persist part of the data to disk, ensuring durability.

2) Supported data types

Memcached supports only simple data types.

Redis supports complex data structures.

3) Underlying implementation

The two use different communication protocols and internal models.

Redis implements its own VM mechanism to reduce system call overhead.

4) Value size limits

Redis values can be up to 1 GB, while Memcached limits values to 1 MB.

5. What problems do Redis features solve?

Refer to the linked article for a detailed discussion.

6. Advantages and disadvantages of Redis persistence methods

Refer to the linked article for a comparison of RDB and AOF persistence.

7. Handling Redis connection timeout in production

Refer to the linked article for troubleshooting steps.

8. Optimizing Redis memory usage

Refer to the linked article for memory‑optimization techniques.

High‑Availability Distributed Cluster

1. What is a distributed system?

A distributed system consists of multiple interconnected nodes (servers) that cooperate to provide a unified service to users, appearing as a single powerful system.

Examples include large e‑commerce platforms like Taobao, where many servers handle requests, storage, and computation collaboratively.

Key characteristics of using distributed systems

1) Increased system capacity – horizontal scaling is needed to handle large workloads.

2) Improved availability – eliminating single points of failure through redundancy.

3) Higher module reuse due to modularization.

4) Faster development and release cycles through parallel work.

5) Better scalability.

6) Enhanced team collaboration.

Three types of distributed systems

1) Distributed processing with a single global database.

2) Layered processing where each layer has its own database.

3) Fully decentralized networks without a central control, using various connection patterns (loose, tight, dynamic, broadcast).

2. High Availability

High Availability (HA) means that the failure of a single server does not affect business or users.

(1) Solving single‑point failures

Active‑Passive (master‑backup) : One primary server and one or more backups; the primary handles traffic and synchronizes data to backups. If the primary fails, a backup takes over, often via a virtual IP (VIP) managed by tools like keepalived.

Pros: No impact on clients; Cons: Backups are idle most of the time.

Active‑Active (master‑slave) : One master with multiple slaves; data is replicated to slaves. Upon master failure, a slave is elected as the new master (using Paxos, Raft, etc.). This also enables read‑write separation.

Cons: Client IP may change after failover, requiring notification mechanisms.

(2) Data synchronization

Synchronous replication : The master waits for slaves to acknowledge writes before confirming success to the client, ensuring strong consistency but reducing performance.

Asynchronous replication : The master returns success immediately and replicates to slaves in the background, offering higher performance but weaker consistency (possible data loss on crash).

Redis master‑slave replication is asynchronous, so a small amount of data loss is possible. Weak consistency can also be expressed as eventual consistency (see CAP theorem).

(3) Choosing a solution

keepalived is simple and low‑cost, suitable for small data volumes and low pressure.

For larger data sets and more custom failover handling (alerts, logging, migration), master‑slave with a monitoring system (e.g., Redis Sentinel) is recommended.

Sentinel provides automatic failover, notifications, and other HA features.

Logical diagram:

3. How does a Redis distributed lock handle lock timeout?

Refer to the linked article for detailed lock‑timeout handling strategies.

4. Common implementations of Redis distributed locks

Refer to the linked article for various lock implementation patterns.