Comparing Redis Cluster Architectures: Codis‑Style, Alibaba, Baidu BDRP, JD, and Official Redis Cluster

Codis‑style Architecture

This architecture partitions the key space using a slot‑hash algorithm. Each group consists of an independent master instance and multiple slave instances. Routing metadata (slot‑to‑instance mapping) is stored in an external coordination service such as Zookeeper or etcd, and sidecar health‑check processes monitor component availability. The design is employed by Alibaba Cloud ApsaraCache, RedisLabs, JD, Baidu and other large‑scale services.

Codis Implementation Details

Slots: The proxy layer manages 1024 logical slots. Each Redis instance maintains a local slot map that records which keys belong to which slot.

Migration workflow (key‑level granularity):

Client sends a request to the source node.

If the key has not been migrated, the source processes the request normally.

If the key is currently being migrated, read requests are served from the source, while write requests receive a RETRY response.

After migration, the source returns a MOVED reply; the client retries the request against the target node.

Alibaba Cloud ApsaraCache

The open‑source single‑node version does not contain the slot‑sharding logic; the cluster implementation details are not publicly disclosed.

Baidu BDRP 2.0

Key components:

Proxy : Modified Twemproxy that supports dynamic routing tables.

Redis core : Based on the Redis 2.x slots scheme.

Metaserver : Implemented with Redis, stores topology information, performs health checks, and can manage up to 1 000 nodes.

Slot scheme: The Redis core divides the database into 16 384 logical databases (slots). Each request first selects the appropriate slot.

Data migration operates at slot granularity. During migration a whole slot is locked for reads only (writes are rejected). This slot‑level migration is faster than key‑level migration used by some other solutions.

JD Solution

Key components:

Proxy : Custom implementation written in Go.

Redis core : Based on Redis 2.8 configServer.

Scala service : Triggers deployment, scaling and migration operations.

MySQL : Persists all metadata and configuration.

Sentinel (Go) : Monitors proxies and Redis instances and initiates failover.

Slot implementation maintains an in‑memory map of slot‑to‑instance mappings.

Migration process (slot granularity):

The Scala component notifies the destination instance that it will receive a specific slot.

The source instance dumps the entire slot data (read‑only dump) and streams it to the destination.

Write requests for keys in the migrating slot are buffered in a separate area; after the dump completes the buffered writes are flushed to the destination.

Once the slot transfer finishes, routing tables are updated and the source removes the slot from its map. Clients that receive a MOVED reply retry the request against the new owner.

Cross‑region deployment uses a master‑slave topology; there is no active‑active multi‑region setup.

Official Redis Cluster‑Based Solution

All functions—slot routing, topology storage, health checking—are built into Redis Cluster and communicate via a gossip protocol. This reduces external dependencies and works well for clusters up to roughly 400 nodes (≈1.6 million reads per second assuming 80 k reads per instance). Beyond that size the gossip traffic becomes a bottleneck.

Adopted by AWS ElastiCache and Baidu Tieba.

AWS ElastiCache

Provides both primary‑replica (single‑node) and cluster modes with read‑write separation. The cluster mode uses the open‑source Redis Cluster without additional customizations.

Baidu Tieba ksarch‑saas

Implemented as Redis Cluster plus a Twemproxy smart‑client layer. After being merged into BDRP, Twemproxy continues to provide the proxy functionality.

Benefits of the proxy layer:

Clients do not need to be upgraded to a smart client; the proxy handles the smart‑client logic.

Platform‑wide policies can be enforced centrally, e.g., large‑key detection, hot‑key monitoring, slow‑query tracking, access control, and request filtering.

Redis 5.0 plans to add a native proxy feature for Redis Cluster.

The Twemproxy modification for ksarch‑saas is open‑source at the following URL:

https://github.com/ksarch-saas/r3proxy