Tackling Redis Cluster’s Limitations: Architecture Optimizations and Practical Solutions

In a previous article we detailed the shortcomings of the current Redis Cluster design; this piece presents macro‑level architectural optimization proposals to address those issues.

1. P2P Architecture Side Effects

1.1 Gossip Communication Overhead

Redis Cluster uses a dedicated TCP channel for gossip messages. Nodes exchange binary PING / PONG heartbeats; the cluster-node-timeout setting determines how many nodes are pinged each second, and each heartbeat also carries information about roughly one‑tenth of the cluster, creating significant traffic.

Only nodes that have received a MEET can join the gossip.

1.2 Rolling Upgrade Difficulty

Unlike Nginx, which can replace workers without downtime, Redis Cluster lacks a proven zero‑downtime upgrade path comparable to systems like Cassandra.

1.3 Inability to Distinguish Hot/Cold Data

Because all nodes are peers, there is no central place to store data‑temperature statistics, making hierarchical storage (e.g., swapping cold keys to disk) hard. A common workaround is to insert a proxy layer that performs statistics, swapping, and L1 caching.

2. Client Challenges

2.1 Cluster Protocol Support

Java’s Jedis client supports the cluster protocol but struggles with failover handling; it updates slot‑to‑node mappings on MOVED messages but fails to refresh connection pools and IP lists.

2.2 Connection and Routing Table Maintenance

A smart client must cache the 16384 slot‑to‑node map and maintain a separate connection pool per node, leading to a large number of connections on multi‑core servers.

2.3 Limited MultiOp and Pipeline Support

Cluster sharding forces all keys in a multi‑key command to reside in the same slot; overcoming this requires command splitting and result aggregation, typically implemented in a proxy.

3. Redis Implementation Issues

3.1 No Automatic Discovery

Cluster nodes do not use multicast discovery; new nodes must be added manually via the CLUSTER MEET command.

3.2 Manual Resharding

Operators must manually decide which slots move to which nodes; a dashboard could automate this based on load.

3.3 No Monitoring UI

Redis provides no official UI; a custom dashboard can invoke CLUSTER commands to display status.

3.4 Split‑Brain Problem

Network partitions must be handled by the official Redis solution.

3.5 Slow Migration Speed

Using pipelines to speed up MIGRATE helps but does not change the fact that migration operates at the key level, not the slot level.

3.6 Migration Failure Recovery

Because progress information is not stored centrally, failures leave slots in an indeterminate state; solutions include re‑introducing ZooKeeper or a dedicated Redis instance for global state.

3.7 Slave Cold Standby

Slaves are not used for reads, causing “cold standby”; a proxy can implement read‑write splitting at the cost of some consistency.

4. Optimization Summary

4.1 Architectural Changes

Introduce three components—Proxy, Dashboard, and Agent—to handle protocol parsing, security filtering, load balancing, result aggregation, read/write splitting, hierarchical storage, and monitoring.

Benefits of retaining Redis Cluster include automatic failover, built‑in slot handling, consistency guarantees, and data access during migration.

Proxy Component

Protocol Parsing : implements cluster protocol and shields clients.

Security Filtering : command whitelists and permission checks.

Load Balancing : pre‑sharding hash, slot cache, resharding control.

Result Aggregation : supports MultiOp and Pipeline.

Read/Write Splitting : offloads read pressure from slaves.

Hierarchical Storage : swaps cold data to slower storage, provides L1 cache.

Monitoring : status metrics, historical reports, thresholds, alerts.

Dashboard Component

A user‑friendly UI can replace redis‑trib, offering automatic deployment and resharding algorithms.

Agent Component

Handles deployment, lifecycle management (start/stop/restart/upgrade) of Redis instances and acts as a high‑availability coordinator similar to Sentinel.

4.2 ZooKeeper Replacement

In a peer‑to‑peer cluster, slot‑to‑node mappings are distributed, eliminating the need for a central ZooKeeper; redirection messages (MOVED/ASK) handle updates, but global migration tasks still require external storage.

4.3 Reducing Operational Cost

Examples include AliRedis’s master‑worker model (multi‑threaded master with worker processes) and Reborndb’s agent‑based deployment, both lowering manual effort and improving scalability.

5. The Ideal Redis

5.1 Next‑Generation Codis

Future directions: embed Raft in the proxy to replace ZooKeeper, abstract storage engine management to proxy/agent, and implement replication‑based migration for faster, less intrusive data moves.

5.2 Redis Enterprise (RLEC)

Redis Labs Enterprise Cluster provides a zero‑latency proxy, cluster manager, and management UI, delivering automatic scaling, high availability, hot‑cold tiering, and rack‑aware clustering.