Read/write splitting instances of ApsaraDB for Redis can process a large number of reads and writes where there are more read than write requests. The instance supports multiple specifications to meet different needs.

Description

Read/write splitting instances of ApsaraDB for Redis are suited for workloads with large number of reads and writes where there are more read than write requests. Read/write splitting instances provide high availability (HA) and high performance. Multiple specifications are available. The read/write splitting architecture allows a large number of concurrent requests to read hot data from read replicas. This mechanism can reduce the load on the master node and minimize operation and maintenance costs.

Components

A read/write splitting instance of ApsaraDB for Redis consists of multiple proxy servers, a master node, a replica node, and one or more read replicas.

As a hot standby node, the replica node does not provide services. Read replicas only process read requests. Proxy servers forward write requests to the master node, and forward read requests to either the master node or one of the read replica nodes based on their weights. The weight of each node is determined by the system and cannot be customized.

Note The system evenly distributes read requests among the master node and read replicas. For example, if you purchase an instance with three read replicas, the read weight is 25% for the master node and for each read replica.

The HA system monitors the status of each node. If a master node fails, the HA system performs a failover between the master and replica nodes. If a read replica fails, the HA system creates a new read replica to process read requests. During this process, the HA system will update the routing and weighting information.

The read/write splitting architecture supports chain replication to allow you to scale out read replicas to increase the read capacity. The source code of the replication process has been customized and optimized by by specialists at Alibaba Cloud to maximize workload stability during replication.

When an application is connected to the read/write splitting instance, a proxy server identifies read and write requests, performs load balancing, and forwards the requests to different nodes based on their weights. Write requests are forwarded to the master node, and read requests are equally distributed among the master node and read replicas.

Cluster instances of ApsaraDB for Redis are developed based on native Redis protocols and are compatible with all Redis commands. You can upgrade a standard master-replica instance to a read/write splitting instance with just a few clicks. You can also migrate data from an on-premises Redis database to a read/write splitting instance of ApsaraDB for Redis. Both instance upgrades and data migrations can be performed without disrupting services.

Features

  • High availability
    • Alibaba Cloud has developed an HA system for read/write splitting instances. The HA system monitors the status of all nodes on an instance to guarantee high availability. If a master node fails, the HA system will switch the workload from the master node to the replica node and update the instance topology. If a read replica fails, the HA system will enable another read replica. It will then synchronize data and forward read requests to this enabled read replica and suspend the failed read replica.
    • The proxy server module detects the service status of each read replica in real time. If a read replica has an error, the proxy server module will reduce the weight of the faulty read replica. After a read replica has been found to be faulty for a specified number of times, the system will suspend the read replica and forward its read requests to available read replicas. The system will continue to monitor the faulty read replica. If the read replica recovers, the system will enable the read replica again.
  • High performance

    Read/write splitting instances support chained replication to allow you to scale out read replicas to increase read capacity and optimize the usage of physical resources for each read replica.

Scenarios

  • High QPS

    Standard instances of ApsaraDB for Redis cannot support high-QPS scenarios. If your workloads process a large number of reads and writes where there are more read than write requests, you must deploy multiple read replicas. This will help resolve the performance bottleneck caused by a single-threading model. You can attach one, three, or five read replicas to a cluster instance of ApsaraDB for Redis. Compared with standard instances, cluster instances have the QPS performance improved by approximately five times.

  • More native Redis features

    Read/write splitting instances are compatible with all Redis commands. You can migrate data to such instances without disrupting services.

  • Persistent storage on ApsaraDB for Redis instances

    Read/write splitting instances support data persistence, backup, and recovery to ensure data reliability.