Mastering Redis Cluster: Evolution, Architecture, and Interview Secrets

Introduction

Today I received news that a high‑school classmate, Liu Ma, failed a technical interview because he did not understand how Redis is deployed in production. The story sets the stage for a deep dive into Redis cluster architectures and interview preparation.

Suitable audience: people unfamiliar with production Redis cluster architecture.

Not suitable: experts who already know the architecture.

The article is divided into two parts: the evolution of Redis cluster architectures and a "egg" section with interview tips.

Redis Cluster Evolution

Replication+Sentinel

This early architecture uses the open‑source high‑availability solution Sentinel. Its diagram is shown below.

Monitoring: Sentinel continuously checks the health of master and slave servers.

Notification: When a Redis instance fails, Sentinel sends alerts via API scripts.

Automatic failover: If the master goes down, Sentinel promotes a slave to master and updates the virtual IP (VIP) so clients can reconnect.

The failover process involves electing a new master and dynamically reconfiguring the VIP. The following diagram illustrates the transition.

Drawbacks: (1) Data loss can occur during master‑slave switch; (2) Only a single write point, no horizontal scaling.

Proxy+Replication+Sentinel

This architecture adds a proxy layer (Twemproxy or Codis). The author used Twemproxy because Codis was newer and Redis Cluster was still experimental in 2015.

Working principle:

Twemproxy+KeepAlived acts as a front‑end proxy, distributing keys across multiple Redis instances.

Each shard’s slave is a read‑only replica of its master.

Sentinel monitors each master; on failure it notifies and triggers automatic failover.

Sentinel can run a script (client‑reconfig‑script) to obtain the new master and update Twemproxy configuration.

Drawbacks: (1) Very complex deployment; (2) Poor scalability—manual intervention required for scaling; (3) Operationally cumbersome.

Redis Cluster

By 2017 Redis Cluster had become mature and widely adopted by large companies. The author recommends this architecture.

Working principle: clients connect directly to any master node; the hash slot for a key is calculated as HASH_SLOT = CRC16(key) mod 16384, determining which shard handles the key.

Advantages: no need for Sentinel, automatic master promotion, horizontal scaling, automatic migration of slaves.

Drawbacks: batch operations are problematic, and resource isolation is weak, leading to potential interference between workloads.

Interview Egg (彩蛋)

Common interview questions and high‑level answers that emphasize Redis Cluster:

Question 1: Do you understand Redis transactions? High‑level answer: In Redis Cluster, keys may reside on different nodes, so transactions are ineffective; Redis transactions also lack rollback, making them rarely used.

Question 2: What do you know about Redis multiple databases? High‑level answer: In Redis Cluster there is only a single logical database (db0); the multi‑database feature is not used.

Question 3: Any shortcomings of Redis clustering? High‑level answer: Large hash objects cannot be split across nodes, and batch operations are cumbersome.

Question 4: Do you know Redis batch operations? High‑level answer: In Cluster mode, commands like MSET/MGET are not feasible because keys are distributed across slots.

Question 5: How to perform batch operations in Redis Cluster? High‑level answer: Use hash tags (e.g., {foo}.student1) to force keys onto the same node, or perform serial GETs for a small number of keys.

Keys such as {foo}.student1, {foo}.student2, {foo}student3 share the same hash tag {foo}, guaranteeing they map to the same Redis node.

Question 6: Do you implement read‑write separation for Redis? High‑level answer: Not with Redis Cluster; the architecture already provides sharding and high performance, and adding read‑write separation would increase complexity without significant benefit.

Conclusion

The article reviewed the evolution of Redis clustering architectures and offered interview tips, aiming to help readers understand production‑grade Redis setups and succeed in technical interviews.