Cluster instances or read/write splitting instances of ApsaraDB for Redis use proxy servers to route commands, balance loads, and perform failovers. This topic describes how proxy servers route commands, bring read replicas offline, and handle special commands.
Route commands in cluster instances
- Basic routing method
- When proxy servers receive a command that manages an individual key, the 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 proxy servers receive a command that manages two or more keys stored in different shards, the proxy servers split the command into multiple commands and route the commands to the shards. For more information about the commands that are used to manage two or more keys at a time, see Overview.
- Route Pub/Sub commands
When proxy servers receive Pub/Sub commands such as PUBLISH and SUBSCRIBE, the proxy servers hash the channel names and route the commands to related data nodes.Note To view the information about Pub/Sub commands in a data shard, you can select Data Node on the performance monitoring page of the console and set the custom monitoring items to Pub/Sub Monitoring Group. By default, the Pub/Sub commands of the first data shard are displayed. For more information, see Customize metrics.
- Route commands in which the idx parameter is specified
If you run cluster commands developed by Alibaba Cloud, such as IINFO, ISCAN, IMONITOR, and IMEMORY, and set the idx parameter to specify a data shard in the commands, proxy servers route the commands to the specified data shard. For more information about the cluster commands developed by Alibaba Cloud, 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 replicas based on their
weights. By default, all nodes have the same weight. For example, if an instance has
five read replicas, proxy servers evenly route read commands to six nodes. The six
nodes include the master node and read replicas. 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: PUBLISH and SUBSCRIBE
- Route commands to the first read replica
Proxy servers route the HSCAN, SSCAN, and ZSCAN commands to the first read replica. If no read replica is running, proxy servers route the commands to the master node.
- Route commands to a specified read replica
The RIINFO, RIMONITOR, and RIMEMORY commands are exclusive to read/write splitting instances of ApsaraDB for Redis. When proxy servers receive these commands, the proxy servers route them to the specified read replica based on the idx and ro_slave_idx parameters. The idx parameter is used to specify a data shard in cluster read/write splitting instances. The ro_slave_idx parameter is used to specify a read replica in cluster and non-cluster read/write splitting instances. For more information about the commands that are exclusive to read/write splitting instances, see Overview.
Bring a read replica offline
Proxy servers monitor the status of each read replica in real time. Proxy servers can bring a read replica offline to temporarily stop routing commands to the read replica.
- If proxy servers detect that a read replica is abnormal, the proxy servers decrease the weight of the read replica. If proxy servers fail to connect to a read replica for a specific number of times, proxy servers bring the read replica offline. The proxy servers bring the read replica online when the proxy servers are connected to the read replica.
- If proxy servers detect that full data is being synchronized on a read replica, the proxy servers bring the read replica offline until the synchronization is complete.
Handle special commands
In most cases, proxy servers create persistent connections to backend data shards to process requests from users. If the requests contain the following special commands, proxy servers create additional connections to the 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.
- Subscription commands: SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, and PUNSUBSCRIBE.
- Each data shard allows up to 10,000 connections. Use the preceding commands with caution and make sure that the number of connections to each data shard does not exceed 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.