Redis Read‑Write Separation: Star vs Chain Replication Explained

Background : In both master‑slave and cluster modes, Redis replicas serve only as hot backups and do not handle client traffic; they become masters only during HA failover, so all read‑write operations go through the master, limiting performance by the number of masters.

Architecture

Redis cluster includes roles such as redis‑proxy, master, replica, and HA. In read‑write separation instances, a new read‑only replica role handles read traffic while remaining a hot standby, preserving compatibility with existing cluster specifications. The redis‑proxy forwards requests to either 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 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‑threaded, each additional replica increases CPU load on the master for data synchronization, reducing write performance and increasing outbound bandwidth proportionally. The higher CPU and network load on the master can offset the low latency advantage, making the cluster’s overall performance constrained by the master.

Chain Replication

Read‑only replicas are arranged in a chain; the master only syncs data to the first replica, which then propagates it downstream.

Chain replication solves the scalability issue of star replication, theoretically allowing unlimited read‑only replicas and near‑linear performance growth as nodes increase.

However, longer chains increase synchronization latency between the master and the downstream replica, which is acceptable for scenarios with low consistency requirements. If a node in the chain fails, all downstream replicas experience significant lag, and a full sync may propagate to the chain’s end, impacting service. To mitigate this, Alibaba Cloud’s optimized binlog replication is used to minimize full‑sync probability.

Redis Read‑Write Separation Advantages

Transparent Compatibility : Uses the same redis‑proxy as regular clusters, allowing seamless upgrade from single‑shard to multi‑shard read‑write separation without code changes.

High Availability : HA monitors all DB nodes, automatically failing over the master or rebuilding read‑only replicas when failures occur. redis‑proxy also adjusts replica weights to isolate problematic nodes.

High Performance : Ideal for read‑heavy, write‑light workloads; multiple read‑only replicas can be added to scale reads, offering up to 600,000 QPS and 192 MB/s per shard while maintaining full command compatibility.

Users can purchase a read‑write separation instance and use any client without modification, enjoying near‑zero integration cost. The service currently offers configurations such as 1 master + 1/3/5 read‑only replicas per shard, with plans to remove fixed limits and allow dynamic scaling of replicas.

Note: Redis master‑slave replication is asynchronous, so read‑only replicas may return stale data; applications must tolerate some inconsistency, and future configurations will allow specifying maximum acceptable latency.