Redis Usage Guidelines and Operational Restrictions

Usage Guidelines

Redis is powerful with rich data types, but unrestricted use can cause serious problems. By disabling high‑risk features and applying development constraints, teams can address problems with a simple, generic mindset rather than being tied to specific implementations.

Cold and Hot Data Separation

Although Redis supports persistence, storing all data in Redis is costly. It is recommended to load hot data (e.g., QPS > 5k) into Redis, while low‑frequency data should reside in MySQL or Elasticsearch.

Business Data Separation

Avoid mixing unrelated business data in a single Redis instance; this prevents cross‑impact, limits instance growth, and reduces the blast radius during failures.

Message Size Limits

Because Redis is single‑threaded, large messages block other operations. Keep messages under 1 KB and never exceed 50 KB per record to avoid bandwidth and I/O issues.

Connection Limits

Frequent creation and destruction of connections waste resources and can crash the host; ensure proper client connection‑pool configuration.

Cache Key TTL Settings

Cache keys must have an expiration time appropriate to the business; be aware of units (seconds vs. milliseconds) to avoid mistakes.

Cache Should Not Have Intermediate State

Cache must be used only as a cache; removing it should not change business logic, and it should never become part of core processing.

1) Cache high availability affects business; 2) Deep coupling can cause unpredictable effects; 3) Maintenance impact is significant.

Preferred Sharding Method: Client Hash

If the application is small, do not over‑scale the Redis cluster. Prefer client‑side hash sharding, e.g., split users into 10 clusters based on the last digit of the user ID.

Operational Restrictions

Prohibit KEYS

The KEYS command is O(N) and can block the server; it is disastrous on a cluster and must be renamed and disabled.

Prohibit FLUSH

FLUSHALL

or FLUSHDB clears all data and is a high‑risk operation; only DBA should be allowed to execute it after renaming.

Do Not Use Redis as a Message Queue

Unless there is a very special need, Redis should not be used as a message queue due to capacity, network, and reliability issues; use Kafka or RocketMQ instead.

Prohibit Unbounded Batch Operations

Unrestricted batch commands cause slow queries; avoid them.

1) ZSET: Do not use range commands without specifying limits (e.g., ZRANGE myzset 0 -1). Specify a range or use ZCARD to check length first.

2) HASH: Do not use HGETALL on large hashes; check length with HLEN first.

3) KEY: In Redis Cluster, avoid large MGET across shards as it degrades performance; benchmark beforehand.

4) Other: Avoid set aggregation commands such as SUNION, SINTER, SDIFF.

Disable SELECT

The SELECT command switches databases, which can cause issues and is unsupported in cluster mode; it should be disabled.

Disable Transactions

Redis is fast; unless absolutely necessary, handle errors manually instead of using transaction commands.

Disable Lua Scripts

Lua scripts act like stored procedures, introducing performance and maintenance problems; they should be disabled.

Avoid Long‑Running MONITOR

MONITOR

can severely impact performance during peak periods; use with extreme caution.

Key Naming Conventions

Keys must follow a clear naming scheme using colon separators (e.g., user:sex, msg:achi) to enable easy cleanup, updates, and understanding of ownership and usage.

Conclusion

Reasonable constraints are essential for mature architecture; standardized conventions lead to collective development excellence. Use Redis steadily, enforce constraints, and consider wrapping the client to block prohibited actions for better results.