This section describes the common usage specifications of Redis, including business usage specifications, SDK usage specifications, etc.
Business Usage Specifications
Specification | Description | Level | Remarks |
Separate business data. | Prevent interference to all related businesses due to Redis faults or unavailability. | Suggested | Separate business data to avoid multiple applications using one Redis instance, split irrelevant businesses, and make public data a service |
Improve Redis fault tolerance. | The DCS may encounter infrastructure faults or active/standby switchover, and the application needs to be fault-tolerant for possible faults and slow requests. | Suggested | When a cache miss occurs, data is obtained from the database; or when a fault occurs, allow another Redis to take over services automatically. |
Avoid Redis memory utilization exceeding 80%. | The cloud server has certain memory redundancy, but when Redis uses too much memory, the COPY-ON-WRITE mechanism introduced when Redis persists in full will consume additional memory. This combined with the memory fragmentation caused by large memory and management process consumption relating to the cloud server can easily trigger OOM KILL on the operating system. | Required | Scale up in time. |
Prevent cache breakdown. | To prevent cache penetration, use Redis together with the local cache. Store hotspot data in the local cache. Regularly update the hotspot data asynchronously. | Suggested | - |
Deploy businesses nearby. | The read/write performance will be greatly affected by network latency. If your business is latency-sensitive, do not create cross-AZ Redis instances. | Suggested | - |
Do not use Redis as a message queue. | In publish/subscribe scenarios, do not use Redis as a message queue. Redis support performance for PUB/SUB is limited. | Required | If message queues are required, use Kafka and RocketMQ instead. |
Specifications on Using Key Names
Specification | Description | Level | Remarks |
Keep the format consistent. | Use the business name or database name as the prefix, followed by colons (:). | Suggested | For example: business name:table name:ID. |
Minimize the key length. | Minimize the key length without compromising the clarity of the meaning. Abbreviate common words. | Suggested | For example, user can be abbreviated to u, and messages can be abbreviated to msg. Use up to 128 bytes. |
Do not use special characters. | Do not use special characters such as spaces, line breaks, single or double quotation marks, and other escape characters. | Required | Redis uses braces ({}) to signify hash tags. For cluster instances, braces in key names must be used correctly to avoid data skew where all data is assigned to a single slot. |
Specifications on Using Values
Specification | Description | Level | Remarks |
Avoid big keys and hot keys. | Big keys can cause NIC traffic storms and slow queries. Avoid big keys and hot keys. | Required | Generally, the string type should be controlled within 10 KB, and the number of hash, list, set, and zset elements should not exceed 1000. |
Choose appropriate data types. | Choosing the right data type can save memory and bandwidth, and improve performance. | Suggested | For example, to store multiple attributes of a user, you can use multiple keys, such as set u:1:name "X" and set u:1:age 20. To save memory usage, you can also use the HMSET command to set multiple fields to their respective values in the hash stored at one key. |
Set appropriate timeout. | Do not set a large number of keys to expire at the same time. | Suggested | This prevents high CPU usage and unstable performance due to Redis processing a large number of expired keys. |
Specifications on Redis Commands
Specification | Description | Level | Remarks |
Exercise caution when using commands with time complexity of O(N). | For commands with a time complexity of O(N), if the N value is large, it may cause Redis to execute actions too slowly, affecting overall performance and stability. | Required | For example, the HGETALL, LRANGE, SMEMBERS, ZRANGE, and SINTER commands will consume a large number of resources if there is a large number of elements. Alternatively, you can use SCAN sister commands, such as HSCAN, SSCAN, and ZSCAN commands. |
Disabled commands. | Some commands are prohibited, so you better learn about these commands in advance. | Required | Before using an instance, please see Redis command compatibility and WebCli command compatibility. |
Exercise caution when using the SELECT command. | Redis does not have strong support for multi-DB. Redis is single-threaded, so databases interfere with each other. | Suggested | When multiple DBs are needed, it is recommended to use multiple Redis instances. Cluster instances do not support multiple DBs. |
Batch Operations | For batch operations, use the MGET command, MSET command, or pipelining to improve efficiency, but be careful to control the number of elements in a batch operation to avoid slow execution and occupying too many Redis resources. | Suggested | l For batch operations, use the MGET command, MSET command, or pipelining to improve efficiency, but be careful to control the number of elements in a batch operation. MGET command, MSET command, and pipelining differ in the following ways: MGET and MSET are atomic operations, while pipelining is not. l Pipelining can be used to send multiple commands at a time, while MGET and MSET cannot. l Pipelining must be supported by both the server and the client. |
Do not use time-consuming code in Lua scripts. | The timeout of Lua scripts is 5s, so avoid using time-consuming code in Lua scripts. | Required | For example, time-consuming sleep statements or long loops. |
Do not use random functions in Lua scripts. | When calling a Lua script, do not use random functions to specify keys. Otherwise, the execution results will be inconsistent between the active and standby nodes, causing data inconsistency. | Required | - |
Follow the rules for using Lua on cluster instances. | Follow the rules for using Lua on cluster instances. | Required | l Rules for using Lua on cluster instances: When the EVAL or EVALSHA command is run, the command parameter must contain at least one key. Otherwise, the client displays the error message ERR eval/evalsha numkeys must be bigger than zero in Redis cluster mode. l When the EVAL or EVALSHA command is run, a cluster instance uses the first key to compute slots. Ensure that the keys to be operated are in the same slot. |
Do not use the DEL command to directly delete big keys. | When deleting a big key, do not use the DEL command directly because the DEL command will also block other client requests from execution. | Required | In Redis 4.0 and later, you can use the UNLINK command to delete big keys safely. This command is non-blocking. |
l In versions earlier than Redis 4.0: To delete big Hashes, use HSCAN + HDEL commands. l To delete big Lists, use the LTRIM command. l To delete big Sets, use SSCAN + SREM commands. l To delete big Sorted Sets, use ZSCAN + ZREM commands. | |||
Minimize the number of pipelining commands. | When using pipelining, do not run too many commands at once because it will occupy a lot of Redis resources, take a long time for execution, and block other commands. | Suggested | Do not run more than 100 commands at a time, and the actual number of bytes of the elements also needs to be taken into account. |
Use publish and subscribe commands properly. | Do not use Redis as a message queue. Using Redis as a message queue will cause various problems in capacity, network, efficiency, and functionality. | Suggested | If you need a message queue, you can use high-throughput Kafka or highly reliable RabbitMQ. |
Redis transaction limits. | Redis transactions do not support rollback. If a command fails during the transaction, the previous commands will still be executed successfully. | Suggested | - |
Specifications on Using SDK
Specification | Description | Level | Remarks |
Use connection pools + persistent connections. | Short connection performance is poor. It is recommended to use connection pools + persistent connections, which can effectively control the connections and improve efficiency. | Suggested | It is recommended to use JedisPool or JedisCluster to access your instance. |
Avoid using Lettuce. | Jedis is more stable because it is better at detecting and handling connection errors and network fluctuations. | Suggested | Jedis is recommended. |
The client must perform fault tolerance in case of faults or slow requests. | The client should have fault tolerance and retry mechanisms in case of active/standby switchover, command timeout, or slow requests caused by network fluctuation or configuration errors. | Required | - |
Set an appropriate interval and the number of retries. | Set the interval and number of retries based on your business requirements to avoid inappropriate configurations affecting service availability. | Required | l If the retry interval is very short, a retry storm may occur, and can easily cause service avalanche. l If the retry interval is very long or the number of retries is set to a large value, the service recovery may be slow in the case of an active/standby switchover. |
Specifications on O&M and Management
Specification | Description | Level | Remarks |
Enable password login. | Production environments require Redis password login for verification. | Required | - |
Verify the fault handling capability or disaster recovery logic of the service. | Organize drills in the test environment or pre-production environment to verify business reliability in Redis active/standby switchover, breakdown, or scaling scenarios. | Suggested | - |
Configure monitoring. | Pay attention to the Redis capacity and expand it before overload. | Required | Configure CPU, memory, and bandwidth alarms based on the alarm thresholds. |
Check the memory usage of each node. | Perform routine checks on the memory usage of each node and whether the memory usage of the master nodes is balanced. | Suggested | If memory usage is unbalanced, big keys exist and need to be split and optimized. |
Enable hot key analysis. | Perform routine analysis on hot keys and check whether there are frequently accessed keys. | Suggested | - |
Analyze Redis slow query log. | Perform routine analysis on slow query logs. | Suggested | Analyze slow query logs and rectify faults as soon as possible. |