All Products
Search
Document Center

Tair (Redis® OSS-Compatible):Use proxy query cache to address issues caused by hotkeys

Last Updated:Jul 11, 2025

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%.

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 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 worksProxy Query Cache原理

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.

Note

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:

  • 0: disables the proxy query cache feature. Default value.

  • 1: Enable.

Important

You can enable the proxy query cache feature in the following scenarios:

  • The query results of hotkeys are updated at a low or stable frequency. You can specify the expiration time of the cache to minimize the risk of dirty reads.

  • The business can accept potential data inconsistencies that may occur within the validity period of the cache.

query_cache_mode

The proxy query cache mode. Valid values:

  • 0: caches only the data of the hotkeys pushed by data shards. Default value.

  • 1: caches the data of all keys and evicts data based on the Least Recently Used (LRU) algorithm.

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.

Example: Hot news ranking list

The data of a hot news ranking list is stored on a read/write splitting instance, and the ranking list is refreshed every 15 minutes. Occasionally, specific hot news articles can cause the QPS for the service to exceed 5,000. The maximum acceptable data latency for the ranking list is 30 seconds. After the proxy query cache feature is enabled, set the validity period of the cache to 30 seconds.

Important
  • If the cached data is modified within the validity period, the modified data is not synchronized to the cache. In this case, dirty data is returned for identical read requests until the cache expires.

  • You must evaluate the value of this parameter based on your business requirements and tolerance for dirty data. If the value is smaller than required, the cache hit ratio is reduced. If the value is greater than required, the client reads dirty data for an extended period of time.

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 KEYS

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"

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 INFO

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"
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 LISTALL

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: 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.