Use proxy query cache to address issues caused by hotkeys - ApsaraDB for Redis

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

An ApsaraDB for Redis Enhanced Edition (Tair) DRAM-based instance is created.
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%.

Note 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 the feature works

Figure 1. How the proxy query cache feature 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 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 server 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.

Note 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 Modify the values of parameters for an instance.


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 query cache feature. 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	Specifies the proxy query cache mode. Default value: 0. Valid values: 0: caches query results only of the hotkeys pushed by data shards. 1: caches query results of all keys. The cached data is evicted based on the Least Recently Used (LRU) algorithm. 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	Specifies the validity period of cached data. Unit: milliseconds. Default value: 1000. Valid values: 100 to 60000. 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 your 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 to connect to an ApsaraDB for Redis instance.

querycache keys: queries all hotkeys cached on proxy nodes.
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"
```
Sample output description
The information about a hotkey consists of two lines:
- The first line is the name of the database.
- The second line is the name of the hotkey.
querycache info: queries the status of the proxy query cache.
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"
```
Sample output description
- put_qps: the number of data node writes to the cache per second.
- get_qps: the number of client reads 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: queries all cached requests.
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
The information about each request consists of three lines:
- The first line is the name of the database.
- The second line is the content of the request. The format follows the Redis protocol. For more information about the Redis protocol, see Redis Protocol specification.
- The third line is the remaining time to live of the request. Unit: milliseconds.