Best Redis Cluster Options: Client Sharding, Proxy, Codis, Official

Redis, a widely used NoSQL database, supports rich data types and offers clear performance advantages over relational databases, making it a popular choice for high‑throughput hot data.

A single‑node Redis on a typical server handles about 50,000 operations per second, or up to 200‑300 k ops with pipelining, which suffices for many small‑to‑medium companies.

Why a cluster is needed:

Redis processes requests sequentially in a single thread, so a long operation blocks subsequent ones.

Memory on a single machine is limited.

Some workloads generate high bandwidth pressure.

Single‑point‑of‑failure reduces availability.

Dynamic scaling is not possible.

The goal of a Redis cluster is high availability, avoidance of performance bottlenecks, dynamic scaling, and easier monitoring and alerting.

Client Sharding

Requires a smart client that routes requests based on predefined rules, enabling distributed access to multiple Redis instances.

Popular in small companies because libraries like Jedis for Java provide high performance without an extra proxy layer.

Pros: reduces network hop compared to proxy solutions.

Cons: scaling or switching instances requires code changes and client version maintenance; fault diagnosis can be difficult.

Proxy Sharding

Uses a unified proxy program (e.g., Twemproxy or Codis) to access multiple Redis instances.

Pros: application code accesses a simple API; components are decoupled, easing upgrades and reducing the number of long connections.

Cons: adds an extra network and processing layer, decreasing performance.

Twemproxy

Twemproxy is an open‑source Redis proxy from Twitter. Clients send requests to Twemproxy, which routes them to the appropriate Redis instance and aggregates responses.

Advantages:

Clients connect to Twemproxy like a regular Redis instance, no code changes needed.

Automatically removes unavailable Redis instances.

Reduces the number of client‑to‑Redis connections.

Disadvantages:

Each request passes through the proxy, incurring performance loss.

Lacks a friendly monitoring UI.

Cannot smoothly add Redis instances, making scaling operations cumbersome.

Codis

Codis, developed by WanDouJia, addresses Twemproxy’s scaling limitation. It consists of four components:

Codis Proxy – a stateless proxy implementing the Redis protocol; multiple proxies can be deployed for high availability.

CodisRedis – a Redis fork with slot support and atomic migration commands.

Codisconfig – a management tool with an HTTP server for cluster monitoring and operations.

ZooKeeper – provides consistent configuration storage and coordination.

Codis uses pre‑sharding with 1024 slots; each slot maps to a Redis Server Group. Slots can be reassigned manually via Codisconfig or automatically using its rebalance feature.

Official Redis Cluster

Supported since Redis 3.0, the native cluster aims for performance, linear horizontal scaling (up to 1000 nodes), and high availability with automatic failover.

Data distribution uses 16 384 pre‑allocated slots; keys are mapped to slots via CRC16(key) mod 16384. The architecture is fully decentralized, with each node storing the full cluster state and communicating via a gossip protocol.

Key points:

Each node can have master and slave replicas; masters fail over to slaves.

Asynchronous replication may lead to data loss.

Gossip protocol detects node failures and propagates state.

Clients may need to support slot caching and redirection.

Limitations include the need for client upgrades, higher communication overhead, and lack of mature monitoring tools.

Cloud‑Based Redis Cluster Services

Chinese cloud providers such as Alibaba Cloud and UCloud offer managed Redis services with features like dynamic scaling, automatic failover, data replication, and cost‑effective resource utilization, relieving backend developers from operational burdens.