This topic describes how to use the proxy query cache feature. Tair (Redis OSS-compatible) 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 cached result to the client without the need to interact with backend data shards.
Prerequisites
The instance that you want to manage is a Tair (Enterprise Edition) 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. Hotkeys ensure that the CPU utilization and traffic usage of specific data shards remain at a level close to 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 can accept the possibility of reading stale data during the period of time when data is updated up to when the cached data expires. This period of time is the validity period of the proxy cache. This trade-off sacrifices strong consistency for improved system performance and stability. The business logic must be able to handle this potential brief data inconsistency to ensure that even with some latency in the data, the core business processes remain unaffected.
How it works
Figure 1. How the proxy query cache feature works 
Tair (Redis OSS-compatible) uses effective sorting and statistical algorithms to identify hotkeys. Hotkeys are keys that receive more than 5,000 queries per second (QPS). After you enable the proxy query cache feature, proxy nodes cache the request and response data of hotkeys based on the rules that you configure. Proxy nodes cache only the 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. If the query results of hotkeys change, the cache is not updated.
You can use the instance diagnostics feature to check whether an instance receives skewed requests. You can also use the real-time key statistics feature to query the statistics about hotkeys on 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 You can enable the proxy query cache feature in the following scenarios:
|
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 you set this parameter 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. Important
|
Commands
You can connect to the Tair (Redis OSS-compatible) instance and run the following command to check the query cache usage. For more information, see Use redis-cli to connect to an ApsaraDB for Redis instance.
QUERYCACHE KEYS
Command syntax: QUERYCACHE KEYS.
Command description: This command is used to query all hotkeys cached on a proxy node. This command 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 data to the cache per second.
get_qps: the number of times that clients read data 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 that access to the query cache is throttled due to bandwidth limits. By default, throttling is disabled.
qps_limit_query_cnt: the number of times that 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.