How Redis Read‑Write Separation Boosts Performance and Cuts Costs

Background

In both master‑slave and cluster deployments, Redis replica nodes act only as hot‑standby copies. They do not accept client traffic unless a high‑availability (HA) failover promotes a replica to master. Consequently, all read‑write operations are forced onto the master, which limits scalability despite providing strong consistency.

To serve read‑heavy, write‑light workloads more efficiently and reduce cost, Alibaba Cloud’s Redis service introduced a dedicated read‑write separation specification. This adds a transparent, highly available, and high‑performance read‑only replica role while keeping full compatibility with existing Redis clients.

Architecture Overview

A Redis cluster consists of redis-proxy, master, replica, and an HA module. In a read‑write separation instance a new read‑only replica is added to handle read traffic; the traditional replica remains a hot standby for failover.

The redis-proxy routes requests based on configured weights: write commands are sent to the master, read commands are sent to one of the read‑only replicas. The HA component continuously monitors the health of all DB nodes. If the master fails, HA promotes a suitable replica to master; if a read‑only replica fails, HA rebuilds it and updates the proxy’s routing weights accordingly.

Replication Topologies

Star Replication

Each read‑only replica synchronizes directly from the master. The replication chain is short, so latency between master and replica is minimal. However, the master’s CPU and network usage grow linearly with the number of replicas because every replica receives a full data stream.

When many read‑only replicas are added, the master can become a bottleneck for both write throughput and outbound bandwidth, limiting overall cluster scalability.

Chain Replication

Read‑only replicas are arranged in a linear chain. The master replicates only to the first replica; each subsequent replica receives data from its upstream neighbor. This topology removes the master’s scaling bottleneck, allowing the number of replicas to increase almost linearly with overall read capacity.

The trade‑off is increased replication lag for replicas farther from the master. A failure of any node in the chain can cause downstream replicas to fall behind, potentially triggering a full‑sync operation that propagates to the chain’s tail.

Alibaba Cloud mitigates the full‑sync risk by using an optimized binlog‑based replication engine that reduces the probability and duration of full‑sync events.

Advantages of Redis Read‑Write Separation

Transparent Compatibility – The same redis-proxy used by standard clusters forwards requests, so existing client libraries require no code changes. Weight‑based routing can be tuned without modifying application logic.

High Availability – HA continuously checks all DB nodes. On master failure it automatically promotes a new master; on read‑only replica failure it rebuilds the replica and adjusts proxy weights to isolate the unhealthy node.

High Performance for Read‑Heavy Workloads – Multiple read‑only replicas can be added per shard, scaling read QPS without affecting write capacity. Current offerings support configurations such as 1 master + 1/3/5 read‑only replicas per shard, delivering up to 600,000 QPS and 192 MB/s bandwidth while remaining fully compatible with all Redis commands.

Consistency Considerations

Redis replication is asynchronous. Reads served by a read‑only replica may return stale data that has not yet been propagated from the master. Applications must tolerate eventual consistency, or design their logic to handle possible replication lag. Future releases plan to expose a configurable maximum acceptable replication delay, allowing users to enforce stricter consistency guarantees when needed.