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 and handle special commands. This helps you design more effective business systems.

Overview of proxy servers

Figure 1. Architectures of cluster instances and read/write splitting instances
Architectures of cluster instances and read/write splitting instances

A proxy server is a component that runs in the standalone architecture in an ApsaraDB for Redis instance. Proxy servers do not occupy resources of data shards. An ApsaraDB for Redis instance uses multiple proxy servers to balance loads and perform failovers.

Capability Description
Balance loads and route commands Proxy servers establish persistent connections with backend data shards to balance loads and route commands. For more information about routing methods, see Route commands.
Manage the traffic to read replicas Proxy servers monitor the status of each read replica in real time. If a read replica is in one of the following states, proxy servers stop routing traffic to the node:
  • Abnormal: If a read replica is abnormal, proxy servers reduce the weight of traffic to the read replica. If the read replica fails to be connected for the specified number of times, the proxy servers stop routing traffic to the read replica until it is recovered.
  • Full data synchronization: If proxy servers detect that full data is being synchronized on a read replica, the proxy servers stop routing traffic to the read replica until the synchronization is complete.
Cache information about hotkeys After you enable the proxy query cache feature, proxy servers cache the request and response data of hotkeys. If a proxy server receives a duplicate request within the validity period of cached data, the proxy server directly returns a response to the client without the need to interact with backend data shards. This prevent skewed requests caused by hotkeys. For more information, see Use proxy query cache to address issues caused by hotkeys.
Note This feature is supported only by performance-enhanced instances of ApsaraDB for Redis Enhanced Edition (Tair) in the cluster architecture.
Note As proxy servers develop, the capabilities of the proxy servers in clusters are no longer based only on the number of proxy servers. Alibaba Cloud ensures that the number of proxy servers meets the requirements described in the cluster specifications.

Route commands

Note For more information about commands, see Overview.
Architecture Routing method Description
Cluster 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.
Routing method for specific commands
  • Publish and subscription commands

    When proxy servers receive publish or subscription commands such as PUBLISH and SUBSCRIBE, the proxy servers hash the channel names and route the commands to related data shards.

    Note To view the information about the publish and subscription commands in a data shard, you can select Data Node on the performance monitoring page in the console and set the custom monitoring item to Pub/Sub Monitoring Group. By default, the publish and subscription commands of the first data shard are displayed. For more information, see Display only specified metrics (previous).
  • Redis commands developed by Alibaba Cloud

    When proxy servers receive commands that are developed by Alibaba Cloud, such as IINFO and ISCAN, and the data shard IDs are specified in the idx parameter, the proxy servers route the commands to the specified data shards. For more information, see Redis commands developed by Alibaba Cloud.

Read/write splitting Basic routing method
  • Proxy servers route write commands to the master node.
  • The system evenly distributes read requests among the master node and read replicas. You cannot change the weights of these nodes. For example, if you purchase an instance with three read replicas, the weights of the master node and three read replicas are all 25%.
    Note SLOWLOG and DBSIZE are read commands.
Routing method for specific commands
  • SCAN commands

    Proxy servers route the HSCAN, SSCAN, and ZSCAN commands to the first read replica. If exceptions occur on all read replicas, these commands are routed to the master node.

  • Redis commands developed by Alibaba Cloud

    When proxy servers receive commands that are developed by Alibaba Cloud, such as RIINFO and RIMONITOR, the proxy servers route the commands to the read replicas specified by the ro_slave_idx parameter and the data shards specified by the idx parameter. For more information, see Redis commands developed by Alibaba Cloud.

  • Other commands

    Proxy servers route transaction commands, such as MULTI and EXEC, Lua script commands, such as EVAL and EVALSHA, SCAN commands, INFO commands, and publish and subscription commands, such as PUBLISH and SUBSCRIBE, to the master node.

Number of connections

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, the proxy servers create additional connections to the data shards to process subsequent requests. Use the following commands with caution and make sure that the number of connections to each data shard does not exceed the upper limit.

Note In proxy mode, Community Edition allows up to 10,000 connections to each data shard, whereas Enhanced Edition (Tair) allows up to 30,000 connections to each data shard.
  • 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.
  • SCAN command: scans multiple databases at the same time.

FAQ

  • Q: Can proxy servers route an Lua script command that only reads data to a read replica?

    A: Yes, proxy servers can route an Lua script command that only reads data to a read replica. For this purpose, you must set the readonly_lua_route_ronode_enable parameter for your ApsaraDB for Redis instance to 1, which indicates that Lua script commands that only read data are routed to read replicas. For more information, see Modify the parameters of an ApsaraDB for Redis instance.

  • Q: What is the difference between the proxy mode and the direct connection mode? Which mode do you recommend?
    A: We recommend that you use the proxy mode. The following items describe the difference between the proxy mode and the direct connection mode:
    • By default, cluster instances and read/write splitting instances provide proxy endpoints. Requests of clients are routed to data shards by proxy servers. Proxy servers help implement rich features such as load balancing, read/write splitting, failover, proxy cache query, and persistent connection.
    • If you use a cluster instance, you can use a direct endpoint to bypass proxy servers. This way, you can directly access backend data shards. This is similar to the connection to a native Redis cluster. Compared with the proxy mode, the direct connection mode saves the forward time and accelerates the response of ApsaraDB for Redis.
  • 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 corresponding optimization methods.
    Scenario Impact and optimization
    Figure 2. Commands that manage multiple keys
    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, such as MGET, that manage multiple keys or reduce the number of keys that are managed by a request. This prevents that all requests fail when only a single data shard is abnormal.
      • Reduce the frequency of transaction commands or reduce the transaction size. This prevents that the entire transaction fails when only a single subtransaction fails.
    Figure 3. Single connection
    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 case, Request 1 failed because it uses the same connection as Request 2.

    • Optimization methods:
      • Do not use pipelines as much as possible.
      • Do not use clients, such as Lettuce, that support only a single connection. We recommend that you use clients, such as Jedis client, that support connection pools. In this case, you must configure a reasonable timeout period and connection pool size.