Choosing the Right Distributed Cache: Redis Cluster Deep Dive

Choosing Distributed Cache Systems

Caching improves concurrency, throughput and response latency. When data volume exceeds a single‑machine capacity, a distributed cache is required.

Cache System Types

CDN cache – caches content at edge nodes of a content‑delivery network.

Reverse‑proxy cache – e.g., Nginx cache.

Local cache – e.g., EhCache, Guava Cache.

Distributed cache – dedicated cache solutions such as Redis, Memcached, Tair, etc.

Among distributed caches, Redis is generally preferred for its stability, rich ecosystem and active community.

Redis Cluster Solutions

Master‑Slave Replication

This classic architecture provides read‑write separation: the master handles reads/writes, slaves replicate data for backup. It is simple to set up but suffers from complex failover, limited horizontal scaling and constrained write capacity.

Redis Sentinel

Sentinel is the native high‑availability solution in the community edition. One or more sentinel instances monitor masters and automatically promote a slave to master if the current master fails, ensuring continuity. The main challenge is guaranteeing seamless master failover.

Redis Cluster (True Distributed)

Introduced in Redis 3.0, Redis Cluster provides a decentralized solution. The keyspace is split into 16,384 hash slots; each node owns a subset of slots. Nodes maintain two TCP connections: one for client traffic and one for inter‑node communication.

CAP trade‑offs are explicit: the design prioritises high performance, availability and scalability, while sacrificing strict consistency. Asynchronous replication may cause data loss on master failure, but the WAIT command can enforce synchronous writes when needed.

Consistency – asynchronous replication may lose writes; WAIT reduces the risk.

Availability – the cluster continues serving reads/writes despite partial node failures.

Performance & scaling – keys are redirected directly to the owning node, avoiding extra proxy hops. Multi‑key operations require all keys to reside in the same slot, which can be forced with hash tags {}.

Scalability – linear scaling up to ~1,000 nodes; new nodes are added by rebalancing slots via CLI commands.

Cluster emphasizes high availability; distributed systems emphasize collaboration.

Common Cache Problems and Mitigations

Cache Penetration

Empty‑key caching – store a placeholder for non‑existent data to avoid repeated DB hits (suitable for low‑cardinality keys).

Bloom filter – a probabilistic structure that quickly filters out requests for absent keys, trading a small false‑positive rate for memory efficiency.

Cache Breakdown

Mutex lock – use SETNX to acquire a lock before loading from DB; other requests wait or retry.

Never‑expire strategy – either keep the key permanently or store an expiration timestamp and refresh asynchronously.

Cache Avalanche

Staggered expiration – add a random offset to TTL so that keys expire gradually.

Background refresh – let a scheduled thread refresh expired entries.

Rate‑limit + local cache – combine a local cache (e.g., EhCache) with circuit‑breaker limits.

Dual cache – maintain a primary and a secondary cache; the secondary never expires.

Cache Consistency Strategies

Cache‑Aside – on miss, fetch from DB and populate cache; on write, update DB then invalidate or update cache.

Write‑Back – write only to cache; cache asynchronously flushes changes to DB.

Write‑Through – write updates both cache and DB synchronously.

Read‑Through – cache reads from DB on miss and writes the result back to cache.

Hot Data Handling

Split complex structures – break large objects into smaller keys distributed across nodes.

Hot‑slot migration – move the slot containing hot keys to a dedicated node.

Multiple replicas – replicate hot data to several nodes to spread read load.

Cache Warm‑up

Pre‑load frequently accessed data into the cache before traffic spikes to avoid sudden DB pressure.

Cache Degradation

When the system is under extreme load or a non‑critical service fails, gracefully degrade functionality by disabling optional features or switching to a simpler cache strategy.

Using Redis Cluster

Create a cluster after deploying N Redis instances that can communicate with each other:

redis-cli --cluster create IP1:port1 IP2:port2 IP3:port3 IP4:port4 IP5:port5 IP6:port6 ... --cluster-replicas 1

Check cluster and node status:

redis-cli cluster node
redis-cli cluster info

For Java back‑ends, Spring Data Redis (since 1.7) supports Redis Cluster. Configure the master node addresses (and password if needed) like:

spring.redis.cluster.nodes=ip1:port1,ip2:port2,ip3:port3

Add the Maven dependency:

compile("org.springframework.boot:spring-boot-starter-data-redis")

Use RedisTemplate to interact with the cluster.