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. If a proxy node receives a duplicate request within the validity period, the proxy node directly returns a response to the client without the need to interact with backend data shards.

Prerequisites

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

Note The key-value pairs of the hotkeys cached on proxy servers are not updated within the validity period. Therefore, make sure that your business supports eventual consistency within the validity period.

How it works

Figure 1. How proxy query cache works
How proxy query cache 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 servers cache request and response data of hotkeys based on the rules you set. Proxy servers cache only request and response data of a hotkey, instead of the entire key. If a proxy server receives a duplicate request within the validity period, the proxy server directly returns a response to the client without the need to interact with backend data shards. This improves the read speed, reduces the impact of hotkeys on the performance of data shards, and prevents skewed requests.

Note You can use the instance diagnostics feature to analyze whether an instance receives skewed requests. You can also use the cache analytics feature to query the information about hotkeys of an instance. For more information, see Create a diagnostic report and Query real-time hotkeys.

Parameter configurations

To manage this feature, modify the following instance parameters. For more information, see Parameter overview.

Parameter Description
query_cache_enabled Specifies whether to enable the proxy query cache feature. Default value: 0. Valid values:
  • 0: disables the proxy query cache feature.
  • 1: enables the proxy cache feature.
Notice The key-value pairs of the hotkeys cached on proxy servers are not updated within the validity period. Therefore, make sure that your business supports eventual consistency within the validity period.
query_cache_mode The proxy query cache mode. Default value: 0. Valid values:
  • 0: caches data only of the hotkeys pushed by data shards.
  • 1: caches data of all keys. The cached keys are evicted based on the Least Recently Used (LRU) algorithm.
Notice For proxy nodes, the maximum cache space per thread is 100 MB. If the value of this parameter is set to 1, which specifies that the proxy nodes evict keys based on the LRU algorithm, 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.
  • 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 duplicate 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

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.

  • querycache keys: You can use this command to query all hotkeys cached on proxy servers.

    Sample response

    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 response description

    The information about a hotkey consists of two lines:

    • The first line is the name of the database that receives the request.
    • The second line is the name of the hotkey.
  • querycache info: You can use this command to query the status of the proxy query cache.

    Sample response

    1) "put_qps:4.00"
    2) "get_qps:16570.00"
    3) "hit_rate:99.98"
    4) "memory_size:180"
    5) "query_count:4"
    Sample response 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.
  • querycache listall: You can use this command to query all cached requests.

    Sample response

    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 response description

    The information about each request consists of three lines:

    • The first line is the name of the database that receives the request.
    • The second line is the content of the request. The format follows the Redis protocol.
    • The third line is the remaining time before the request expires. Unit: milliseconds.