ApsaraDB for Redis instances of the cluster edition or read/write splitting edition use proxy servers to route commands, balance loads, and perform failover. This topic describes how proxy servers route commands, bring a read-only node offline, and handle special commands.
Route commands in an ApsaraDB for Redis instance of the cluster edition
- Basic routing method
- When receiving a command that operates a single key, proxy servers determine the hash slot to which the key belongs and route the command to the shard server where the hash slot resides.
- When receiving a command that operates two or more keys stored on different shard servers, proxy servers split the command to multiple commands and route them to the corresponding shard servers. For more information about the commands that operate two or more keys, see Redis commands.
- Route Pub/Sub commands
Proxy servers route Pub/Sub commands such as PUBLISH and SUBSCRIBE to the master node of the first shard server in the ApsaraDB for Redis cluster.Warning Use Pub/Sub commands properly to avoid putting too much strain on the master node of the first shard server.
- Route commands with the idx parameter specified
When running cluster commands developed by Alibaba Cloud, such as IINFO, ISCAN, IMONITOR, and IMEMORY, you can set the idx parameter to specify a shard server. Then, proxy servers route the commands to the specified shard server. For more information about the cluster commands developed by Alibaba Cloud, see Redis commands.
Route commands in an ApsaraDB for Redis instance of the read/write splitting edition
- Basic routing method
- Proxy servers route write commands to the master node.
- Proxy servers route read commands to the master node and read-only nodes based on
their weights. All nodes have the same weight by default. For example, if an instance
has five read-only nodes, proxy servers route all read commands evenly to six nodes,
including the master node and read-only nodes. Each node receives one-sixth of the
Note SLOWLOG and DBSIZE are read commands.
- Route commands to the master node
Proxy servers route the following commands to the master node:
- Transaction commands: MULTI and EXEC
- Lua scripting commands: EVAL and EVALSHA
- SCAN and INFO commands
- Pub/Sub commands, including PUBLISH and SUBSCRIBE
- Route commands to the first read-only node
Proxy servers route the HSCAN, SSCAN, and ZSCAN commands to the first read-only node. If no read-only node is running, proxy servers route these commands to the master node.
- Route commands to a specified read-only node
The RIINFO, RIMONITOR, and RIMEMORY commands are exclusive to ApsaraDB for Redis instances of the read/write splitting edition. When receiving these commands, proxy servers route them to the specified read-only node based on the idx and ro_slave_idx parameters. The idx parameter is used in ApsaraDB for Redis clusters of the read/write splitting edition to specify a shard server. The ro_slave_idx parameter is used in both ApsaraDB for Redis clusters and non-cluster instances of the read/write splitting edition to specify a read-only node. For more information about the commands that are exclusive to the read/write splitting edition, see Redis commands.
Bring a read-only node offline
Proxy servers monitor the status of each read-only node in real time. Proxy servers can bring a read-only node offline to temporarily stop routing commands to the read-only node.
- When detecting that a read-only node is abnormal, proxy servers decrease the weight of the read-only node. If proxy servers fail to connect to the read-only node for several consecutive times, proxy servers bring the read-only node offline. Proxy servers bring the read-only node online again after detecting that the read-only node resumes normal functioning.
- When detecting that full data is being synchronized on a read-only node, proxy servers bring the read-only node offline until the synchronization is complete.
Handle special commands
Generally, proxy servers create persistent connections to back-end shard servers to process requests from users. If the requests contain special commands, proxy servers create additional connections to the corresponding shard servers to process subsequent requests. The special commands include:
- 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.
- The maximum number of connections on each shard server is 10,000. Use the preceding commands properly in case that the number of connections exceeds the upper limit.
- If you run the SCAN command to scan multiple databases, a large number of connections are created. Make sure that the number of connections does not reach the upper limit.