This topic describes how to use the proxy query cache feature. Tair provides the proxy query cache feature to address access skew issues 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 that you want to manage is an ApsaraDB for Redis Enhanced Edition (Tair) DRAM-based or persistent memory-optimized instance.
The instance uses the read/write splitting architecture or the cluster architecture in proxy mode.
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%.
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.
How it works
Figure 1. How the proxy query cache feature works 
Tair uses effective sorting and statistical algorithms to identify hotkeys, which are keys that receive more than 5,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 node 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.
You can use the instance diagnostics feature to analyze whether an instance receives skewed requests. You can also use the real-time key statistics feature to query the statistics about hotkeys in an instance. For more information, see Create a diagnostic report and Use the real-time key statistics feature.
Parameter configurations
To manage this feature, modify the instance parameters described in the following table. For more information, see Configure instance parameters.
Parameter | Description |
query_cache_enabled | Specifies whether to enable the proxy query cache feature. Valid values:
Important 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 | The proxy query cache mode. Valid values:
Important 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 | The validity period of cached data. Unit: milliseconds. Valid values: 100 to 60000. Default value: 1000.
|
Commands
You can connect to the Tair instance and run the following command to check the query cache usage. For more information, see Use redis-cli to connect to a Tair instance.
QUERYCACHE KEYS
Command syntax: QUERYCACHE KEYS.
Command description: This command is used to query all hotkeys cached on a proxy node. It returns information about each hotkey, including the name of the associated database and the name of the hotkey itself.
Sample command:
QUERYCACHE KEYSSample 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"QUERYCACHE INFO
Command syntax: QUERYCACHE INFO.
Command description: This command is used to query the operational status of the proxy query cache.
Sample command:
QUERYCACHE INFOSample output:
1) "put_qps:4.00"
2) "get_qps:16570.00"
3) "hit_rate:99.98"
4) "memory_size:180"
5) "query_count:4"
6) "bandwidth_limit_query_cnt:0"
7) "qps_limit_query_cnt:0"Sample output description:
put_qps: the number of times that data nodes write to the cache per second.
get_qps: the number of times that clients read 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.
bandwidth_limit_query_cnt: the number of times access to the query cache is throttled due to bandwidth limits. By default, throttling is disabled.
qps_limit_query_cnt: the number of times access to the query cache is throttled due to QPS limits. By default, throttling is disabled.
QUERYCACHE INSTALL
Command syntax: QUERYCACHE INSTALL.
Command description: This command is used to query all cached requests.
Sample command:
QUERYCACHE INSTALLSample 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) 667Sample output description: Each request consists of three lines of information: the database name, the complete request content formatted based on the Redis serialization protocol specification, and the remaining time to live in milliseconds.