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

In both master‑slave and cluster modes of Redis, replicas serve only as hot‑standby nodes and become masters only during high‑availability (HA) events, so all read and write requests are handled by the master, limiting performance as traffic grows.

To meet read‑heavy, write‑light scenarios and reduce costs, the cloud Redis service provides a read/write separation specification that offers transparent, high‑availability, high‑performance, and flexible read/write separation.

Architecture: The read/write separation instance adds a new read‑only replica role. The redis‑proxy forwards read requests to replicas and write requests to the master based on configured weights, while the HA module monitors node health, performs failover, and rebuilds replicas as needed.

Two replication topologies are supported:

Star replication synchronizes each read‑only replica directly with the master, providing low replication latency but increasing CPU and network load on the master as replica count grows, which can become a scalability bottleneck.

Chain replication arranges replicas in a sequential chain, allowing many replicas and near‑linear performance scaling; however, the longer the chain, the greater the latency at the tail and the higher the risk of full‑sync operations if a node fails.

Advantages of the read/write separation service include:

Transparent compatibility with existing Redis cluster specifications.

High availability through HA monitoring and proxy weight adjustments that isolate faulty replicas.

High performance for read‑dominant workloads, offering specifications such as 1 master + 1/3/5 read‑only replicas with up to 600 k QPS and 192 MB/s throughput; users can freely add or remove replicas.

Limitation: Redis uses asynchronous replication, so reads from read‑only replicas may return stale data; future configurations will allow users to set acceptable maximum replication delay.