Read/write splitting instances of ApsaraDB for Redis are suitable for read-heavy workloads. These instances ensure high availability and high performance, and support multiple specifications. The read/write splitting architecture allows a large number of concurrent requests to read hot data from read replicas. This helps reduce the loads on the master node and minimize operations and maintenance costs.

Overview

A read/write splitting instance of ApsaraDB for Redis consists of a master node, a replica node, read replicas, proxy servers, and a high-availability system.

Note Read/write splitting instances of ApsaraDB for Redis are classified into non-cluster and cluster instances. The following figure shows the architecture of a non-cluster read/write splitting instance. A cluster read/write splitting instance contains more shards than a non-cluster read/write splitting instance.
Architecture of a read/write splitting instance of ApsaraDB for Redis
Service Description
Master node The master node processes only write requests and handles read requests together with the read replicas.
Replica node As a hot standby node, the replica node does not provide services.
Read replica Read replicas process only read requests. The read/write splitting architecture supports chain replication. This allows you to scale out read replicas to increase the read capacity. Optimized binlog files are used to replicate data. This way, full synchronization can be avoided.
Proxy server When a client is connected to a proxy server, the proxy server automatically identifies the type of requests and forwards the requests to different nodes based on the weights of the nodes. You cannot change the weights of the nodes. For example, the proxy server forwards write requests to the master node and forwards read requests to the master node or read replicas.
Note
  • Clients must connect to proxy servers. Clients cannot directly connect to the nodes.
  • The system evenly distributes read requests among the master node and read replicas. You cannot change the weights of these nodes. For example, if you purchase an instance with three read replicas, the weights of the master node and three read replicas are all 25%.
High-availability system The high-availability system monitors the status of each node. If a master node fails, the high-availability system performs a failover between the master node and the replica node. If a read replica fails, the high-availability system creates another read replica to process read requests. During this process, the high-availability system updates the routing and weight information.

Key features

  • High availability
    • Alibaba Cloud has developed a high-availability system for read/write splitting instances. The high-availability system monitors the status of all nodes on an instance to ensure high availability. If a master node fails, the high-availability system switches the workloads from the master node to the replica node and updates the instance topology. If a read replica fails, the high-availability system creates another read replica. The high-availability system synchronizes data and forwards read requests to the new read replica, and suspends the failed read replica.
    • The proxy server monitors the service status of each read replica in real time. If a read replica is unavailable due to an exception, the proxy server reduces the weight of this read replica. If a read replica fails to be connected for a specified number of times, the system suspends the read replica and forwards read requests to available read replicas. If the unavailable read replica recovers, the system enables the read replica and continues to monitor the read replica.
  • High performance

    The read/write splitting architecture supports chain replication. This allows you to scale out read replicas to increase the read capacity and improve the usage of physical resources for each read replica. The replication process is optimized based on the Redis source code to maximize workloads stability during replication.

Scenarios

  • High QPS

    Standard instances of ApsaraDB for Redis do not support high queries per second (QPS). If your application is read-heavy, you must deploy multiple read replicas. This allows you to resolve the performance bottleneck issue caused by the single-threading feature of Redis. You can configure one, three, or five read replicas for a cluster instance of ApsaraDB for Redis. The cluster instance has the QPS performance five times higher than a standard instance supports.

  • Support for more Redis-native features

    Read/write splitting instances of ApsaraDB for Redis are compatible with Redis-native commands. You can migrate data from a self-managed Redis database to a read/write splitting instance. You can also upgrade a standard master-replica instance to a read/write splitting instance.

    Note Read /write splitting instances have limits on some commands. For more information, see Limits on the commands supported by read/write splitting instances.
  • Use ApsaraDB for Redis instances to persist data

    Read/write splitting instances support data persistence, backup, and recovery. This ensures data reliability.

Usage notes

  • If a read replica fails, requests are forwarded to another read replica. If all read replicas are unavailable, requests are forwarded to the master node. Read replica failures may result in an increased amount of workloads on the master node and an increased response time. If a large number of read requests must be processed, we recommend that you use multiple read replicas.
  • If an error occurs on a read replica, the high availability module suspends the read replica and creates another read replica. This failover process involves resource allocation, data synchronization, and service loading. The amount of time that is required by a failover is based on the system workloads and data volume. ApsaraDB for Redis does not specify a time period within which a failed read replica can recover.
  • Full synchronization between read replicas is triggered in specific scenarios, for example, when a failover occurs on the master node. During full synchronization, read replicas are unavailable. If your requests are forwarded to the read replicas, the following error message is returned: -LOADING Redis is loading the dataset in memory\r\n.
  • The master node conforms to the Service Level Agreement of ApsaraDB for Redis.