1. Development Standards

【1】 Weak Dependency Check and Offline Confirmation: Redis must be used as a weak dependency, meaning Redis failures should not affect business operations. This includes timeout checks.

【2】 Check for Storage Use: Redis should not be used as a storage system. It should only be used as a cache or for state management. For storage, prefer local caching.

【3】 Timeout Check and Offline Confirmation: Redis must have a timeout setting. If the timeout occurs, the corresponding strategy and solution must be defined.

【4】 Stateless Check: The same Redis key cannot be used by different applications or in different scenarios. The principle of "who produces, who consumes" should be followed.

【5】 Synchronized Lock Check: Prefer using the distributed lock provided by the framework within the organization.

【6】 Key Check: Check the uniqueness of the key to ensure there are no obvious conflicts with other scenarios and applications. The key length should be under 128 bytes, and it should not exceed 1024 bytes. Control the key length to reduce memory usage, especially when there are many keys. The key should be composed of business name (or database name) as a prefix, followed by the table name, and separated by a colon, e.g., business_name:table_name:id. Avoid special characters, such as spaces, newline characters, single/double quotes, and other escape characters. For example, use car+app_name+business_name+specific_id.

【7】 Approval Record Check: Ensure the approval process has been fully recorded in the approval log, including the approvers.

2. Use Cases

Reasonable Use of Data Structures: Redis supports various data structures: String, Hash, List, Set, Sorted Set, Bitmap, HyperLogLog, and Geospatial indexes.

Choose the appropriate data type based on the business scenario, for example:

• String: Used for standard key-value pairs or counting.

• Hash: Used for objects with many attributes, like products or agents.

• List: Can be used for message queues (not recommended), or fan/follow lists.

• Set: Useful for recommendations.

• Sorted Set: Can be used for leaderboards.

3. Key Design

Key Design:

【1】 Readability and Manageability (Recommended):

• Use the business name (or database name) as a prefix to avoid key conflicts, separated by a colon.

• Format: application_name:table_name:id.

【2】 Simplicity and Moderate Key Length (Recommended):

• Ensure the key length is appropriate. If there are many keys, memory usage could become an issue. For example, simplify user:{uid}:friends:messages:{mid} to u:{uid}:fr:m:{mid}.

【3】 Avoid Special Characters (Mandatory):

• Special characters such as spaces, newline characters, single/double quotes, and other escape characters are prohibited.

【4】 Key Count Limitation (Mandatory):

• Redis uses a rehash mechanism. If the number of keys exceeds a certain limit (e.g., 134,217,728 keys), rehash operations may require significant free memory. For example, if the number of keys reaches 134,217,728, 2GB of free memory is needed for rehashing. If the number of keys reaches 268,435,456, 4GB is needed. If sufficient memory is not available, keys may be evicted, leading to data loss or program timeouts.

4. Value Design

【1】 Avoid Big Keys (Prevent Network Traffic and Slow Queries):

• Prevent large data transfers and slow queries by ensuring string values are kept under 10KB and limiting the number of elements in Hash, List, Set, or ZSet to 5000.

• For non-string big keys, avoid using the DEL command. Use HSCAN, SSCAN, or ZSCAN for incremental deletion. Be cautious about automatic expiration of large keys (e.g., a ZSet with 2 million elements set to expire in one hour will trigger a blocking DEL operation, which won't appear in slow query logs).

【2】 Set Expiry Time:

• Redis should not be used as a database; always set an expiry time for keys. Without an expiry time, Redis instances can grow indefinitely, potentially leading to memory exhaustion or long recovery times in case of failure.

• Use the EXPIRE command to set expiration times, and consider staggering expiry times to prevent all keys from expiring at once. Focus on monitoring idletime for keys that should not expire.

5. Command Usage

【1】 Disable KEYS Command and Use SCAN Instead:

• Avoid using the KEYS command in production environments. This command is slow and can cause significant performance degradation. Use SCAN for incremental processing.

【2】 O(N) Command Usage and Control Collection Size:

• Use commands like HGETALL, LRANGE, SMEMBERS, and ZRANGE only when the collection contains a small number of elements.

• For larger datasets, use HSCAN, SSCAN, or ZSCAN for incremental scanning.

【3】 Use of SELECT Command:

• Redis supports multiple databases, but it is not ideal to use this feature in production. Use database numbers to differentiate, but note that Redis processes all databases in a single thread, which can cause interference.

【4】 Avoid Overuse of Transactions:

• Redis' transaction feature is weak (does not support rollbacks), and in the cluster version, keys involved in a transaction must reside on the same slot (this can be solved using the hashtag feature).

【5】 Do Not Use MONITOR in Production:

• The MONITOR command should be disabled in production environments as it can cause memory bloat and performance issues under high concurrency.

【6】 Use Batch Operations to Improve Efficiency:

• Native commands like MGET and MSET should be used for batch operations. For non-native commands, use PIPLINE to improve efficiency, but control the number of elements (e.g., keep it under 500 elements per batch).

6. Data Persistence

【1】 Reasonable Capacity Evaluation:

• During system design, evaluate whether the Redis cluster has enough capacity and set reasonable size and expiration times. Aim to maintain memory usage between 50% and 85%. If usage exceeds 85%, consider expanding the capacity. If it’s below 50%, consider scaling down.

【2】 Hot and Cold Data Separation:

• Although Redis supports persistence, its data is stored entirely in memory, which is expensive. Store only high-frequency hot data (QPS greater than 5000) in Redis. Low-frequency cold data should be stored in disk-based storage systems like MySQL, Elasticsearch, or MongoDB to save memory costs and improve speed and efficiency.

【3】 Separation of Business Data:

• Don’t mix unrelated business data in the same Redis instance. New business applications should apply for separate instances. Since Redis is single-threaded, using separate instances helps reduce interference between different business processes and improves request response times.

【4】 Compress Large Text Data Before Storing:

• For large text data (generally over 500 bytes), it’s recommended to compress the data before storing it in Redis. Storing large text data in Redis consumes significant memory and can saturate network bandwidth when accessed frequently, leading to service unavailability and cascading failures across the system.