Redis Read‑Write Separation Architecture: Star vs. Chain Replication

Redis in both primary‑replica and cluster modes does not expose replicas to external traffic; replicas only serve when promoted to master during high‑availability (HA) failover. This design ensures strong consistency but limits performance to the number of masters, prompting users with low data volume but high traffic to upgrade to larger clusters.

To address read‑heavy, write‑light scenarios and reduce costs, Alibaba Cloud's Redis service offers a read‑write separation specification that provides transparent, highly available, high‑performance, and flexible read‑write separation.

In a read‑write separation instance, a new read‑only replica role handles read traffic while the traditional replica remains a hot standby. The architecture remains compatible with existing cluster specifications. redis‑proxy forwards requests to masters or read‑only replicas based on weighted routing, and HA monitors node health, performing master promotion or rebuilding read‑only replicas as needed.

Star Replication : All read‑only replicas synchronize directly with the master, operating independently. This short replication chain yields low latency, but each additional replica increases CPU load on the master and multiplies outbound bandwidth, limiting scalability and overall cluster performance.

Chain Replication : Read‑only replicas are organized into a chain; the master replicates to the first replica, which in turn replicates to the next, and so on. This design solves the scalability issues of star replication, allowing virtually unlimited replicas and near‑linear performance growth as nodes increase.

However, longer chains increase synchronization delay for downstream replicas, and a failure in any node can cause downstream replicas to lag significantly. To mitigate full‑sync risks, Alibaba Cloud uses an optimized binlog replication version that minimizes full‑sync probability.

Advantages of Redis Read‑Write Separation

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

High Availability : HA monitors all DB nodes; if the master fails, a new master is elected. If a read‑only replica fails, HA rebuilds it and updates routing, while redis‑proxy adjusts node weights and temporarily shields unhealthy replicas.

High Performance : For read‑heavy workloads, read‑write separation offers multiple specifications (e.g., 1 master + 1/3/5 read‑only replicas) delivering up to 600,000 QPS and 192 MB/s, breaking single‑node resource limits and allowing dynamic scaling of replicas.

Note that Redis asynchronous replication means read‑only replicas may return stale data; users must tolerate some inconsistency, and future configurations will allow specifying acceptable maximum latency.

Author: Zhu Xiaosi’s Blog Source: juejin.cn/post/6955355686108659726