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 clients to concurrently read hot data from read replicas. This helps minimize O&M 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 (HA) system.
| Component | Description |
|---|---|
| Master node | The master node processes all write requests. It also processes specific read requests together with read replicas. |
| Replica node | As a hot standby node, the replica node does not provide services. |
| Read replicas | Read replicas process only read requests. The read/write splitting architecture supports chained 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 clients send requests 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 customize 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
|
| HA system | The HA system monitors the status of each node. If the master node fails, the HA system performs a failover between the master node and the replica node. If a read replica fails, the HA system creates another read replica to process read requests. During this process, the HA system updates the routing and weight information. |
Benefits
- 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 ensure high availability. If the master node fails, the HA system switches the workloads from the master node to the replica node and updates the instance topology. If a read replica fails, the HA system creates another read replica. The HA system synchronizes data and forwards read requests to the new read replica, and suspends the failed read replica.
- A 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. The proxy server continuously monitors the status of the unavailable read replica. After the read replica recovers, the proxy server adds it to serviceable replicas and forwards requests to it.
- High performance
The read/write splitting architecture supports chained replication. This allows you to scale out read replicas to increase the read capacity. The replication process is optimized based on the Redis source code to maximize workloads stability during replication and improve the usage of physical resources for each read replica.
Scenarios
- High QPS
Standard instances of ApsaraDB for Redis do not support high queries per second (QPS). If your application is read-heavy, you can deploy multiple read replicas to relieve the stress on the master node. This allows you to resolve the performance bottleneck issue caused by the single-threading architecture of Redis. You can configure one, three, or five read replicas for a cluster instance of ApsaraDB for Redis. The QPS of a cluster instance can be about five times higher than that of a standard instance.Note The read/write splitting architecture adopts chained replication and a latency exists in data synchronization to all read replicas. The longer the chain, the higher the latency at the end of the chain. Therefore, you can choose the read/write splitting architecture only in scenarios that allow dirty data. In scenarios that require high data consistency, we recommend that you choose the cluster architecture.
- Support for more open source Redis features
Read/write splitting instances of ApsaraDB for Redis are compatible with all open source Redis commands. You can smoothly migrate data from a self-managed Redis database to a read/write splitting instance. You can also upgrade a master-replica standard instance to a read/write splitting instance.
Note Read/write splitting instances have limits on specific commands. For more information, see Limits on the commands supported by read/write splitting instances.
Usage notes
- If a read replica fails, requests are forwarded to other available read replicas. If all read replicas are unavailable, requests are forwarded to the master node. Read replica failures may result in an increased number of workloads on the master node and an increased response time. To process a large number of read requests, we recommend that you use multiple read replicas.
- If an error occurs on a read replica, the HA system 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 provide a guarantee on the time period within which a failed read replica can recover.
- Full synchronization between read replicas is triggered in specific scenarios. For
example, it can be triggered 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.