To better address access skew issues caused by hotkeys that receive many read requests, Tair (Redis OSS-compatible) provides the proxy query cache feature (Proxy Query Cache). 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 interacting 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 many 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 between when data is updated and when the cached data expires. This period 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 in an instance (typically, hotkeys have a QPS greater than 5,000). After you enable this feature, proxy nodes cache the request and response data of hotkeys based on the rules that you configure (only the query results of hotkeys are cached, not 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 interacting 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.
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 commands to query the usage of Querycache. For more information, see Use redis-cli to connect to an 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 running 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 listall
Command syntax: QUERYCACHE LISTALL
Command description: This command is used to query all cached requests.
Sample command:
QUERYCACHE LISTALLSample 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.