Evolution of Redis Cluster Architecture and Interview Tips

Introduction

On February 6, 2019, the author learned that a former classmate failed a job interview because he did not understand how Redis is deployed in production. The article is written for readers who are unfamiliar with Redis cluster architecture and aims to explain its evolution and interview considerations.

Content

Replication + Sentinel

This architecture uses the native high‑availability solution provided by the open‑source Redis community. Sentinel performs three main functions: monitoring, notification, and automatic failover. When a master node crashes, Sentinel elects a new master and, using the client-reconfig-script, updates a virtual IP (VIP) so that clients can continue to connect to the VIP.

Drawbacks:

Data loss may occur during master‑slave switch.

Redis can only write to a single master, limiting horizontal scaling.

Proxy + Replication + Sentinel

Two proxy options are discussed: Codis and Twemproxy. The author used Twemproxy because Codis was newer at the time and Redis Cluster was still experimental in 2015.

In this setup, Twemproxy (with KeepAlived) acts as a front‑end proxy that shards multiple Redis instances. Each shard’s slave is read‑only, and Sentinel monitors masters, triggering failover and reconfiguration scripts to update Twemproxy.

Drawbacks:

Complex deployment architecture.

Poor scalability; manual intervention required for scaling.

Operational inconvenience.

Redis Cluster

By 2017 Redis Cluster had matured. The author notes that most earlier shortcomings have been addressed, and major companies such as Baidu Tieba and Meituan use it in production. Tools like Sohu’s CacheCloud can assist with operations.

Operation: clients connect directly to any master node; the slot for a key is calculated as HASH_SLOT = CRC16(key) mod 16384. The cluster automatically handles master failover, horizontal scaling, and some automated slave migration.

Advantages:

No need for Sentinel; automatic failover within the cluster.

Horizontal scalability.

Automatic migration of slaves when needed.

Disadvantages:

Batch operations are cumbersome.

Resource isolation is weak, leading to possible interference between workloads.

Interview Egg (Q&A)

The author provides sample interview questions and model answers, emphasizing the use of Redis Cluster:

Redis transactions are limited in a cluster because keys may reside on different nodes; transactions are therefore not recommended.

Redis Cluster provides only a single logical database (db0); the multi‑database feature of standalone Redis is unavailable.

Limitations of Redis Cluster include inability to shard a large hash object across nodes and difficulty with batch operations.

For batch reads/writes in a cluster, use hash tags (e.g., {foo}.student1) to force keys onto the same node.

Read‑write separation is unnecessary in Redis Cluster because the in‑memory nature of Redis makes I/O bottlenecks minimal, and adding separation would increase complexity.

Conclusion

The article summarizes the evolution of Redis cluster architectures and offers interview tips, hoping readers gain useful insights.