How Do I Avoid Big Keys and Hot Keys?¶
Keep the size of Strings within 10 KB and the quantity of Hashes, Lists, Sets, or Zsets within 5000.
When naming keys, use the service name abbreviation as the prefix and do not use special characters such as spaces, line brakes, single or double quotation marks, and other escape characters.
Do not rely too much on Redis transactions.
The performance of short connections ("connect" in Redis terminology) is poor. Use clients with connection pools.
Do not enable data persistence if you use Redis just for caching and can tolerate data loss.
For details about how to optimize big keys and hot keys, see the following table.
Category | Method |
---|---|
Big key | Split big keys. Scenarios:
|
Store big keys on other storage media. If a big key cannot be split, it is not suitable to be stored in Redis. You can store it on other storage media, and delete the big key from Redis. Caution CAUTION: Do not use the DEL command to delete big keys. Otherwise, Redis may be blocked or even a master/standby switchover may occur. | |
Hot key | Use the client cache or local cache. If you know what keys are frequently used, you can design a two-level cache architecture (client/local cache and remote Redis). Frequently used data is obtained from the local cache first. The local cache and remote cache are updated with data writes at the same time. In this way, the read pressure on frequently accessed data can be separated. This method is costly because it requires changes to the client architecture and code. |
Design a circuit breaker or degradation mechanism. Hot keys can easily result in cache breakdown. During peak hours, requests are passed through to the backend database, causing service avalanche. To ensure availability, the system must have a circuit breaker or degradation mechanism to limit the traffic and degrade services if breakdown occurs. |