For scenarios with very high read/write ratios, Tair (Redis OSS-compatible) lets you dynamically enable or disable read/write splitting. This feature provides a high-availability, high-performance, and flexible read/write splitting service that is ideal for scenarios that require centralized hot spot data and high-concurrency reads. A read/write splitting instance uses a proxy component developed by the Alibaba Cloud Tair team. This component automatically identifies and routes read and write requests and handles services such as failover. You do not need to manage business code for read/write splitting or handle failover at the application layer. This feature significantly reduces integration complexity.
Enable read/write splitting for a standard architecture
A standard architecture instance with read/write splitting enabled consists of a primary node, read-only nodes, proxy nodes, and a high availability system. The following figures show the architecture.
Figure 1. Cloud-native edition
Figure 2. Classic edition (Discontinued)
Component | Cloud-native read/write splitting instance | Classic read/write splitting instance (Discontinued) |
Primary node (Master node) | Handles write requests. It also handles read requests together with the read-only nodes. | |
Read-only nodes (Read replicas) | Handle read requests. Features:
| Handle read requests. Features:
|
Replica node | Any read-only node can serve as a replica node. If the primary node becomes abnormal, the high availability system selects the read-only node with the most complete data to be the new primary node. After the failover is complete, a new read-only node is immediately added. Because this component is not required, a cloud-native read/write splitting instance is less expensive for the same level of performance. | A cold replica node used for data backup. It does not serve requests. If the primary node becomes abnormal, requests are switched to this node. |
Proxy server | After a client connects to the proxy server, the proxy server automatically identifies the request type. It distributes traffic based on weights and forwards requests to different data nodes. All nodes have the same weight, and custom weights are not supported. For example, write requests are forwarded to the primary node. Read requests are forwarded to the primary node and read-only nodes. Note
| |
High availability (HA) system |
| |
Cloud-native read/write splitting instance (Recommended) | Classic read/write splitting instance (Discontinued) |
Both the primary and secondary zones provide services. Minimum configuration:
Separate endpoints are provided for the primary and secondary zones. Both endpoints support read and write operations. Read requests to the primary zone are routed only to the primary node or read-only nodes in the primary zone. Read requests to the secondary zone are routed only to the read-only nodes in the secondary zone. This enables access to the nearest node. All write requests are routed to the primary node in the primary zone. The following figure shows the architecture:  Note We recommend that you configure two or more nodes in both the primary and secondary zones:
| The primary node and read-only nodes are deployed in the primary zone. Only the cold replica node is deployed in the secondary zone for data backup. The cold replica node does not serve requests. If the primary node becomes abnormal, requests are switched to this node. |
Features
Dynamic switching and ease of use
You can enable read/write splitting directly for a standard architecture instance. The proxy intelligently identifies and forwards read and write requests from clients. After you enable this feature, you can use any Redis-compatible client to access the read/write splitting instance. This improves read performance without requiring changes to your application. Read/write splitting instances are compatible with Redis protocol commands, but some commands are restricted on proxy nodes. For more information, see Command restrictions for read/write splitting instances.
High availability
The Alibaba Cloud high availability (HA) system automatically monitors the health of all data nodes to ensure the availability of the entire instance. If the primary node becomes unavailable, a new primary node is automatically selected and the replication topology is rebuilt. If a read-only node fails, the HA system automatically detects the issue, starts a new node to complete data synchronization, and takes the failed node offline.
The proxy node monitors the service status of each read-only node in real time. If a read-only node fails, the proxy node automatically reduces its service weight. If the proxy detects that a read-only node has failed a certain number of consecutive times, it stops sending requests to the failed node. The proxy continues to monitor the node and resumes sending requests after the node recovers.
High performance
You can scale out the read-only nodes of a read/write splitting instance to linearly increase its overall performance. The Redis replication process is optimized at the source code level. This greatly improves the stability of the replication system and makes full use of the physical resources of each read-only node.
Scenarios
This feature is ideal for scenarios with high read pressure, measured in queries per second (QPS). If your application has a high read-to-write ratio, a standard architecture instance may not meet your high QPS requirements. In this case, you can deploy multiple read-only nodes to overcome the performance bottleneck of a single node. After you enable read/write splitting, the read QPS of the instance can be increased by up to 9 times.
Because Redis uses an asynchronous synchronization mechanism, data latency may occur if the write volume is large. When you use this architecture, your application must be able to tolerate a certain degree of dirty data.
Enable read/write splitting for a cluster architecture
In a cluster architecture, you can enable read/write splitting only for cloud-native instances that run in proxy mode. The following figure shows an example of the service architecture.
Component description
Component | Description |
Proxy server | After a client connects to the proxy server, the proxy automatically identifies the requests initiated by the client. It then forwards the requests to the corresponding data shards and read/write nodes. For example, write requests are forwarded to primary nodes, and read requests are balanced among primary nodes and read-only nodes. |
Data shards | Each data shard consists of one primary node (Master) and up to four read-only nodes (Read Replicas).
|
High availability (HA) service |
|
If the instance is deployed in a single zone, all nodes are in the primary zone, and the instance provides only the endpoint for the primary zone.
If the instance is deployed in two zones, separate endpoints are provided for the primary and secondary zones. Both endpoints support read and write operations. Read requests to the primary zone are routed to the primary nodes or read-only nodes in the primary zone. Read requests to the secondary zone are routed only to the read-only nodes in the secondary zone. This enables access to the nearest node. All write requests are routed to the primary nodes in the primary zone. In extreme cases where all read-only nodes in the secondary zone are unavailable, read requests to the secondary zone are routed to the primary nodes. This ensures that your application is not affected.
Suggestions and notes
If a read-only node fails, requests are forwarded to other nodes. If all read-only nodes are unavailable, all requests are forwarded to the primary node. A failed read-only node can increase the load on the primary node and lengthen the response time. Therefore, we recommend that you use multiple read-only nodes for scenarios with high read loads.
If a read-only node fails, the HA system pauses services on the failed node and mounts an available read-only node. This process involves resource allocation, instance creation, data synchronization, and service loading. The time required depends on the service payload and data volume. Tair (Redis OSS-compatible) does not provide a service level objective (SLO) for the recovery time of read-only nodes.
For multi-zone read/write splitting, the primary zone must have at least one primary node and one read-only node. Before you enable read/write splitting for a multi-zone standard architecture instance that has one primary node in the primary zone and one replica node in the secondary zone, you must add a replica node to the primary zone. This ensures that the primary zone has two nodes. Then, you can enable read/write splitting.
In some scenarios, a full data synchronization is triggered for read-only nodes. For example, this can happen after an HA failover is triggered on the primary node. During a full data synchronization, the read-only node is unavailable and returns the
-LOADING Redis is loading the dataset in memory\r\nmessage.For more information about routing and forwarding rules, see Tair proxy features.
Prerequisites
The instance is deployed in cloud-native mode.
The instance is a Redis Open-Source Edition or Tair (Enterprise Edition) DRAM-optimized or persistent memory-optimized instance.
The instance comes with at least 1 GB of memory.
The instance is a high availability instance.
User guide
If you have not created an instance, you can enable read/write splitting when you create an instance.
If you have already created a cloud-native instance, you can directly enable read/write splitting.
FAQ
Q: Can enabling read/write splitting for a standard architecture instance increase the overall bandwidth of the instance?
A: Yes, it can. After you enable read/write splitting, the theoretical overall bandwidth of the instance can reach Bandwidth of the instance type × Total number of nodes. For example, 96 MB/s × 3 nodes = 288 MB/s. The added proxy nodes forward most read requests to the read-only nodes, which reduces the bandwidth pressure on the primary node. However, the actual bandwidth is affected by factors such as service requests and clients. The actual bandwidth is subject to the results of stress testing.
Q: After I enable read/write splitting for a standard architecture instance, can I upgrade the instance to a cluster architecture?
A: Yes, you can. First, you must disable read/write splitting and then upgrade/downgrade the instance architecture.
Q: How do I confirm that read/write splitting is enabled?
A: You can go to the Node Management page of the instance and check whether the Read/Write Splitting option is enabled.
Q: Why do the read-only nodes not receive read requests?
A: In a dual-zone read/write splitting architecture, the primary and secondary zones have independent endpoints. Read requests are routed only to the primary node or read-only nodes in the same zone. If you use only the endpoint of the primary zone, no read requests are routed to the read-only nodes in the secondary zone. Therefore, you must distinguish between the endpoints of the primary and secondary zones in your application code. Then, direct requests for the secondary zone to the endpoint of the secondary zone. This enables access to the nearest node and load balancing.