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 cluster instances
- 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 data shard where the hash slot resides.
- When receiving a command that operates two or more keys stored on different shards, proxy servers split the command to multiple commands and route them to the corresponding shards. For more information about the commands that operate two or more keys, see Overview.
- Route Pub/Sub commands
Proxy servers route Pub/Sub commands such as PUBLISH and SUBSCRIBE to the master node of the first data shard 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 data shard.
- Route commands with the idx parameter specified
When you run cluster commands developed by Alibaba Cloud, such as IINFO, ISCAN, IMONITOR, and IMEMORY, if you set the idx parameter to specify a shard, proxy servers route the commands to the specified data shard. For more information about these commands, see Overview.
Route commands in read/write splitting instances
- 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. By default, all nodes have the same weight. 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 cluster read/write splitting instances to specify a data shard. The ro_slave_idx parameter is used in both cluster and non-cluster read/write splitting instances to specify a read-only node. For more information about the commands that are exclusive for the read/write splitting instances, see Overview.
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 a certain number of times, proxy servers bring the read-only node offline. Proxy servers bring the read-only node online again after the read-only node is resumed.
- 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
Typically, proxy servers create persistent connections to back-end data shards to process requests from users. If the requests contain the following special commands, proxy servers create additional connections to corresponding data shards to process subsequent requests.
- 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 data shard 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 exceed the upper limit.