Redis Cluster: Application Cases, Pros & Cons, and Technical Analysis

5. Application Case Collection

5.1 Youdao – Redis Cluster Experience The design requires an external Ruby script for cluster operations, which only accepts IP addresses and not hostnames, leading to usability issues. Two major drawbacks are identified: (1) heavy reliance on the client driver’s maturity, and (2) the Redis process handling both data storage and cluster coordination, turning a simple in‑memory NoSQL into a distributed system that is hard to upgrade.

5.1.2 Decentralization vs. Proxy While Gossip/P2P decentralization is not inherently problematic, the lack of a central node makes automatic rebalancing and rapid failure detection difficult. A proxy‑based approach can hide storage details, allow tiered data placement, and provide better consistency and cost control.

5.2 Qihoo 360 – Redis Cluster vs. Bada Bada partitions work at the partition level, achieving more balanced load compared to Redis Cluster’s node‑level master‑slave model. Both provide eventual consistency, but Bada’s binlog‑merge mechanism mitigates write loss during failures, a problem Redis Cluster faces. Bada also forwards mis‑routed requests internally, avoiding client‑side redirection.

5.3 Mango TV – Redis Service Solution Mango TV built two open‑source components on top of Redis Cluster: a Python‑based monitoring web app (Redis‑ctl) and a C++11 lightweight request proxy (cerberus). The proxy offers automatic request distribution, retry mechanisms, unified node management, stateless failover, and does not require application code changes.

6. Pros & Cons Summary

6.1 Lack of Centralized Architecture Gossip messaging incurs network overhead; the master‑slave backup is coarse‑grained, leaving slaves idle and concentrating write load on masters.

6.2 Client Challenges Clients must implement cluster protocol support, handle network overhead from redirections, maintain connections to all nodes, cache and update slot routing tables, and manage memory for these structures. Multi‑key operations are limited to keys within the same slot, and migrations can cause failures.

6.3 Redis Implementation Issues Redis Cluster lacks auto‑discovery, automatic resharding, and embeds many management tasks in an external Ruby script (redis‑trib). It also provides no built‑in monitoring UI and only guarantees eventual consistency, requiring manual WAIT commands for stronger guarantees.

6.4 Performance Overhead Simple VM‑based benchmarks using YCSB show throughput drops of ~18% during data loading, 3.5‑7.9% for read‑heavy workloads, and 3.3‑5.5% for mixed workloads, with the Jedis client consuming an additional ~380 MB of memory.

6.5 Final Thoughts Compared with Sentinel or Codis, Redis Cluster’s advantages are limited to its built‑in slot mechanism and the elimination of a separate Sentinel cluster. It lacks many features of systems like Cassandra, Hazelcast, or GridGain, such as automatic node discovery, fine‑grained partition backup, fault‑tolerant role adjustment, result aggregation, split‑brain recovery, and multi‑primary writes. Nonetheless, its design goals of high performance, horizontal scalability, and availability remain valid.