ApsaraDB for Redis cluster instances and read/write splitting instances use proxy nodes to route commands, balance loads, and perform failovers. If you know how proxy nodes route commands and handle specific commands, you can understand how to design more effective business systems.
Overview of proxy nodes

A proxy node is a component that runs in the standalone architecture in an ApsaraDB for Redis instance. Proxy nodes do not occupy resources of data shards. An ApsaraDB for Redis instance uses multiple proxy nodes to balance loads and perform failovers.
Capability | Description |
---|---|
Enable architecture changes | Proxy nodes allow you to use a cluster instance the same manner as you would use a standard instance. If your business requirements grow beyond the capabilities that can be provided by a standard instance, you can migrate the data of the standard instance to a cluster instance that has proxy nodes without having to modify code to reduce costs. |
Balance loads and route commands | Proxy nodes establish persistent connections with backend data shards to balance loads and route commands. For more information, see Routing methods of proxy nodes. |
Manage the traffic to read replicas | Proxy nodes monitor the state of each read replica in real time. If a read replica is in one of the following states, proxy nodes stop routing traffic to the read replica:
|
Cache hotkey data | After you enable the proxy query cache feature, proxy nodes cache the request and response data of hotkeys. If a proxy node receives a duplicate request during the validity period, the proxy node directly returns a response to the client without interacting with backend data shards. This prevents skewed requests caused by hotkeys that send a large number of read requests. For more information, see Use proxy query cache to address issues caused by hotkeys. Note This feature is supported only by performance-enhanced cluster instances of the ApsaraDB for Redis Enhanced Edition (Tair). For more information about performance-enhanced instances, see DRAM-based instances. |
Support multiple databases | In cluster mode, multiple databases are not supported by open source Redis and Redis cluster clients. In this case, only the default 0 database can be used and the SELECT command is not supported. You can use proxy nodes to access ApsaraDB for Redis cluster instances. In this case, multiple databases can be used and the SELECT command is supported. By default, 256 databases can be specified for a single cluster instance. |
Routing methods of proxy nodes
Architecture | Routing method | Description |
---|---|---|
Cluster | Basic routing method |
|
Routing method for specific commands |
| |
Read/write splitting | Basic routing method |
|
Routing method for specific commands |
|
Number of connections
In most cases, proxy nodes establish persistent connections with backend data shards to process requests from users. If the requests contain the following special commands, the proxy nodes establish additional connections with the data shards to process subsequent requests. Run the following commands with caution and make sure that the number of connections to each data shard does not exceed the upper limit.
- Blocking commands: BRPOP, BRPOPLPUSH, BLPOP, BZPOPMAX, and BZPOPMIN.
- Transaction commands: MULTI, EXEC, and WATCH.
- Monitoring commands: MONITOR, IMONITOR, and RIMONITOR.
- Sub commands: SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, and PUNSUBSCRIBE.
- SCAN command: scans multiple databases.
FAQ
- Q: What cross-slot commands that manage multiple keys can I run in proxy mode?
A: You can run the following cross-slot commands that manage multiple keys in proxy mode: DEL, EXISTS, MGET, MSET, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SUNION, SUNIONSTORE, and UNLINK.
- Q: Can I forward Lua scripts that only read data to read replicas? A: Yes, you can forward Lua scripts that only read data to read replicas. The following requirements must be met.
- A read-only account is used. For more information, see Create and manage database accounts.
- The readonly_lua_route_ronode_enable parameter is set to 1 for your Tair instance. A value of 1 indicates that Lua scripts that only read data are routed to read replicas. For more information, see Modify the values of parameters for an instance.
- Q: What is the difference between the proxy mode and the direct connection mode? Which mode is recommended? A: We recommend that you use the proxy mode. The following items describe the difference between the proxy mode and the direct connection mode:
- Proxy mode: Proxy nodes forward requests from clients to the data shards in the instance. This mode provides features such as load balancing, read/write splitting, failover, proxy query cache, and persistent connection.
- Direct connection mode: In this mode, you can use private endpoints to bypass proxy nodes and connect to ApsaraDB for Redis instances from clients in the same manner as you connect to native Redis clusters. Compared with the proxy mode, the direct connection mode reduces the routing time and accelerates the response speed.
- Q: How does an abnormal data shard affect data reads and writes? A: Each data shard runs in a high-availability master-replica architecture. If the master node fails, the system switches the workloads to the replica node to ensure high availability. The following table describes the impacts of abnormal data shards on data reads and writes in specific scenarios and provides optimization methods for each scenario.
Scenario Impact and optimization Figure 2. Commands that manage multiple keys - Impact:
The client sends four requests over four connections. If Data Shard 2 is abnormal, timeout errors are returned for the requests that are routed to Data Shard 2. The queried data is returned only for Request 1 GET Key1.
- Optimization methods:
- Reduce the frequency of the commands that manage multiple keys such as MGET or reduce the number of keys that are managed by a request. This ensures that not all requests fail just because a single data shard is abnormal.
- Reduce the frequency of transaction commands or reduce the transaction size. This way, when a subtransaction fails, it does not cause the entire transaction to fail.
Figure 3. Single connection - Impact:
The client sends two requests over the same connection. If Data Shard 2 is abnormal, timeout errors are returned for Request 1 GET Key1 and Request 2 GET Key2. In this example, Request 1 fails because it uses the same connection as Request 2.
- Optimization methods:
- Use pipelines as little as possible.
- Do not use clients that support only a single connection such as Lettuce. We recommend that you use clients that support connection pools such as Jedis. If you use Jedis, you must configure a reasonable timeout period and connection pool size. For more information about Jedis, see Jedis client.
- Impact: