How Redis Read‑Write Separation Boosts Performance and Scalability

Background

Redis, whether in primary‑replica or cluster mode, does not expose replicas for external read/write traffic; replicas only become masters during high‑availability failover. All read and write requests go through the master, providing strong consistency but limiting performance by the number of masters. Users with small data sets but high traffic often have to upgrade to larger clusters.

To meet read‑heavy, write‑light scenarios and reduce costs, Alibaba Cloud Database Redis offers a read‑write separation specification that provides transparent, highly available, high‑performance, and flexible read‑write separation services.

Architecture

Redis cluster includes redis‑proxy, master, replica, and HA components. In read‑write separation instances a new read‑only replica role handles read traffic while the traditional replica remains a hot standby. redis‑proxy forwards 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.

Two replication topologies are used: star replication and chain replication.

Star Replication

All read‑only replicas sync directly with the master, each operating independently, resulting in short replication latency.

Because Redis is single‑process, single‑threaded, increasing the number of read‑only replicas raises CPU consumption on the master and outbound bandwidth, which can offset the low‑latency advantage and limit cluster scalability.

Chain Replication

Read‑only replicas are organized into a chain; the master syncs only to the first replica, which forwards data downstream.

This solves the scalability issue of star replication, allowing near‑linear performance growth as replicas increase. However, longer chains increase end‑to‑end latency, and a failure in any node can delay downstream replicas and trigger full synchronizations. Alibaba Cloud mitigates this with an optimized binlog replication to reduce full‑sync probability.

Advantages of Redis Read‑Write Separation

Transparent Compatibility

Read‑write separation uses the same redis‑proxy as standard clusters, fully compatible with all commands and clients. Users simply purchase a read‑write separation instance and can start using it without code changes.

High Availability

The HA module monitors all DB nodes; if the master fails, it automatically switches to a new master. If a read‑only replica fails, HA detects it, rebuilds a new replica, and redis‑proxy adjusts weights to minimize impact.

High Performance

For read‑heavy workloads, adding read‑only replicas scales read capacity while preserving write performance. Single‑shard offerings provide 1 master plus 1/3/5 read‑only replicas, delivering up to 600 k QPS and 192 MB/s. Future plans will remove replica limits, allowing dynamic scaling based on traffic.

Since replication is asynchronous, reads from read‑only replicas may return stale data; the service will later allow configurable maximum latency to suit different consistency requirements.