In this article, I introduce you to 12 specifications in the areas of key-value pair usage, command usage, and data preservation, centered around the goals of high-performance access and saving memory space in Redis applications.

Key-Value Pair Usage Specifications

  1. [Recommended] Use the business name as the KEY prefix, preferably using its abbreviation. This is done by prefixing the business name, then separating it with a colon(:), followed by the specific business data name. For example, if we want to count the number of unique visitors to a web page, we can use the code uv:page:2048 to set the key, which means that this data corresponds to the business of counting unique visitors, and the corresponding page id is 2048.
  2. [Recommended] Control the length of the KEY. For the business name or business data name, we can use the first letter of the corresponding English word, (e.g., user is represented by u, order is represented by o, and log is represented by l), or we can use an abbreviation to represent it (e.g., unique visitor is represented by uv, page view is represented by pv, and message is represented by msg).
  3. [Reference] Control the data size of String type below 10KB. In the business layer, it’s advisable to limit the size of String-type data to under 10KB to avoid handling large String objects(i.e. to avoid the bigkey of String type).

  4. [Reference] Keep the number of elements in a collection type below 10,000. It’s advisable to keep the number of elements in a collection type below 10,000 to avoid bigkey collection types.

    Of course, the third and the fourth just to try to avoid bigkey, if the business layer of String type data is really big, we can also through the data compression to reduce the size of the data; if the collection type is really a lot of elements, we can split a large collection into multiple small collections to save.

  5. [Recommended] Use efficient serialization and compression methods, which will reduce the size of the value.

  6. [Recommended] Use the integer object shared pool. Under the premise of meeting business data requirements, try to use integers when you can, so that you can save instance memory.

Data Preservation Specifications

  1. [Recommended] Put different business data into different Redis instances. This way, you can avoid excessive memory usage of a single instance and also avoid interfering with the operations of different businesses.
  2. [Recommended] Set the expiration time when saving data. When saving data, it’s advisable to set the expiration time of the data based on the length of time the business uses the data. Otherwise, data stored in Redis will persist indefinitely, consuming memory. With continued growth, this can exceed the machine’s memory limit, leading to overflow and service crashes.
  3. [Recommended] Control the capacity of a Redis instance. Redis single-instance memory size are not too large. According to my own experience, it’s advisable to set the Redis single-instance memory size between 2 to 6GB. This range ensures quick completion of RDB snapshots and data synchronization across master and slave clusters, without blocking normal request processing.

Command Usage Specifications

  1. [Mandatory] Disable KEYS, FLUSHALL, FLUSHDB commands for production environments. Redis is single-threaded. If we execute commands that involve a large number of operations and are time-consuming, the main thread will be severely blocked, preventing other requests from being processed properly.
  2. [Recommended] Use the MONITOR command with caution. The MONITOR command continuously writes what it monitors to the output buffer. If there are a lot of operations on the online commands, the output buffer will soon overflow, which can have an impact on Redis performance and even cause the service to crash.
  3. [Recommended] Use the full operation command with caution. For collection-type data, it is generally not recommended to use commands with full-volume operations (e.g., HGETALL for Hash types, SMEMBERS for Set types) if you want to get all the elements in the collection. These operations scan the underlying data structures of the Hash and Set types at full volume, which can block the Redis main thread if there is a lot of data in the collection type.

Conclusion

The article introduces 12 specifications for high-performance access and saving memory space in Redis applications. These specifications are categorized into three areas: key-value pair usage, data preservation, and command usage.
For key-value pair usage, it is recommended to use business names as key prefixes, control key lengths, limit the size of string-type data and the number of elements in collection types, use efficient serialization and compression methods, and utilize the integer object shared pool.
For data preservation, it is recommended to separate different business data into different Redis instances, set expiration times for saved data, and control the capacity of a Redis instance.
For command usage, it is mandatory to disable certain commands in production environments, and it is recommended to use the MONITOR command and full operation commands with caution.