How Redis Read/Write Separation Boosts Performance and Cuts Costs

In both master‑slave and cluster modes, Redis replicas serve only as hot‑standby nodes and do not handle client traffic; they become masters only during failover. This design limits read/write operations to the master, causing performance to be constrained by the number of masters.

To address read‑heavy, write‑light scenarios and lower costs, the cloud Redis service offers a read/write separation specification that provides transparent, highly available, high‑performance, and flexible read/write separation.

Architecture

Redis cluster includes roles such as redis‑proxy, master, replica, and HA. In a read/write separation instance, a new read‑only replica role handles read traffic while the replica remains a hot‑standby, preserving compatibility with existing cluster specifications. The redis‑proxy forwards read/write requests to the master or a read‑only replica based on weight, and HA monitors node health, performing failover or rebuilding read‑only replicas as needed.

Based on the data synchronization method between master and read‑only replicas, two architectures are possible: star replication and chain replication.

Star Replication

All read‑only replicas synchronize directly with the master, operating independently; a failure of one replica does not affect others, and the short replication chain keeps latency low.

Because Redis is single‑process and single‑threaded, each additional read‑only replica increases CPU load on the master for data synchronization, reducing write performance. Moreover, the master’s outbound bandwidth grows with more replicas, so the master can become a bottleneck, limiting overall cluster scalability.

Chain Replication

Read‑only replicas are organized into a replication chain; the master only synchronizes data to the first replica in the chain.

This design solves the scalability issues of star replication, allowing the number of read‑only replicas to increase virtually without bound, and the cluster’s performance can grow roughly linearly with added nodes.

However, longer chains increase replication latency for downstream replicas, and a failure in any node can cause downstream replicas to fall behind, potentially triggering full‑sync operations that affect the entire chain. To mitigate this, Alibaba Cloud’s optimized binlog replication is used to minimize full‑sync occurrences.

Redis Read/Write Separation Advantages

Transparent Compatibility

Both read/write separation and standard cluster specifications use redis‑proxy for request routing. Users can upgrade from a single‑shard master‑slave to a read/write separation instance, or from a cluster to a multi‑shard read/write separation cluster, with full command compatibility.

The client connects to redis‑proxy, which identifies read or write operations and forwards them to the appropriate backend node (writes to master, reads to read‑only replicas). The master can also serve reads, controllable via weight settings.

High Availability

The HA module monitors all DB nodes; if the master fails, it automatically promotes a new master. If a read‑only replica fails, HA rebuilds it and removes the faulty node from routing. redis‑proxy also adjusts replica weights in real time, temporarily shielding unhealthy replicas.

High Performance

For read‑heavy, write‑light workloads, read/write separation offers more suitable options than a standard cluster, allowing users to fully utilize each read‑only replica’s resources. Single‑shard instances are sold with configurations such as 1 master + 1/3/5 read‑only replicas, delivering up to 600,000 QPS and 192 MB/s throughput while maintaining full command compatibility.

Since replication from master to read‑only replicas is asynchronous, reads may return slightly stale data; therefore, applications must tolerate some inconsistency. Future enhancements will provide configurable maximum lag tolerances for greater flexibility.