This topic describes how to use the proxy query cache feature. ApsaraDB for Redis provides the proxy query cache feature to address skewed requests caused by hotkeys that receive a large number of read requests. After you enable this feature, proxy nodes cache the request and response data of hotkeys. When a proxy node receives a duplicate request within the validity period of the cached data, the proxy node directly returns the response of the request to the client without the need to interact with backend data shards.
Prerequisites
- The instance is a performance-enhanced instance of ApsaraDB for Redis Enhanced Edition (Tair). For more information about performance-enhanced instances, see Performance-enhanced instances.
- The instance uses the cluster architecture. For more information about the cluster architecture, see Cluster master-replica instances.
- The instance and the proxy nodes of the instance are updated to the latest minor version. For more information, see Update the minor version and Upgrade proxy servers.
Scenarios
The proxy query cache feature can be used to address or prevent skewed requests caused by hotkeys. Hotkeys are keys that receive a large number of read requests, which keep the CPU utilization and traffic usage of some data shards at a high level, even 100%.
How the feature works

ApsaraDB for Redis uses effective sorting and statistical algorithms to identify hotkeys, which are keys that receive more than 3,000 queries per second (QPS). After you enable the proxy query cache feature, proxy nodes cache request and response data of hotkeys based on the rules you set. Proxy nodes cache only request and response data of a hotkey, instead of the entire key. If a proxy node receives a duplicate request within the validity period of the cached data, the proxy server directly returns the response of the request to the client without the need to interact with backend data shards. This improves the read speed, reduces the impacts of hotkeys on the performance of data shards, and prevents skewed requests.
Parameter configurations
To manage this feature, modify the instance parameters described in the following table. For more information, see Modify parameters of an instance.
Parameter | Description |
---|---|
query_cache_enabled | Specifies whether to enable the proxy query cache feature. Default value: 0. Valid
values:
Notice The query results of hotkeys that are cached on proxy nodes are not updated within
the validity period of the cached data. Therefore, make sure that your business supports
eventual consistency.
|
query_cache_mode | Specifies the proxy query cache mode. Default value: 0. Valid values:
Notice For proxy nodes, the maximum amount of cache space per thread is 100 MB. If this parameter
is set to 1, the proxy nodes evict data based on the LRU algorithm. In this case, the cache hit
ratio may be reduced and the overall performance may be compromised.
|
query_cache_expire | Specifies the validity period of cached data. Unit: milliseconds. Default value: 1000. Valid values: 100 to 60000.
|
Commands
ApsaraDB for Redis provides commands to help you check the usage of the proxy query cache. You can use the proxy mode to connect to an instance and run the following commands. For more information, see Use redis-cli to connect to an ApsaraDB for Redis instance.
- querycache keys: queries all hotkeys cached on proxy nodes.
Sample output
1) 1) (integer) 0 2) "key:000000000003" 2) 1) (integer) 0 2) "key:000000000001" 3) 1) (integer) 0 2) "key:000000000002" 4) 1) (integer) 0 2) "key:000000000000"
Sample output description
The information about a hotkey consists of two lines:
- The first line is the name of the database.
- The second line is the name of the hotkey.
- querycache info: queries the status of the proxy query cache.
Sample output
1) "put_qps:4.00" 2) "get_qps:16570.00" 3) "hit_rate:99.98" 4) "memory_size:180" 5) "query_count:4"
Sample output description- put_qps: the number of data node writes to the cache per second.
- get_qps: the number of client reads from the cache per second.
- hit_rate: the cache hit ratio.
- memory_size: the memory consumed by cached data. Unit: bytes.
- query_count: the number of cached requests.
- querycache listall: queries all cached requests.
Sample output
1) 1) (integer) 0 2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000000\r\n" 3) (integer) 668 2) 1) (integer) 0 2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000001\r\n" 3) (integer) 668 3) 1) (integer) 0 2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000003\r\n" 3) (integer) 668 4) 1) (integer) 0 2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000002\r\n" 3) (integer) 667
Sample output description
The information about each request consists of three lines:
- The first line is the name of the database.
- The second line is the content of the request. The format follows the Redis protocol. For more information about the Redis protocol, see Redis Protocol specification.
- The third line is the remaining time to live of the request. Unit: milliseconds.