Redis Operational Best Practices and Guidelines

Mandatory Rules

In production environments, disable the KEYS , FLUSHALL , and FLUSHDB commands because they can cause severe performance degradation by blocking the Redis main thread.

Reference Solutions

Limit String values to 10 KB to avoid big keys.

Separate business data across different Redis instances (default 16 databases) for isolation.

Restrict collection elements to no more than 10 000 items.

Store only hot data in Redis to prevent wasteful memory usage.

Keep instance size between 2 GB and 6 GB for efficient snapshot and replication.

Persist slow‑query logs regularly, possibly storing them in a database for analysis.

Increase slowlog-max-len (e.g., set to 1000) to retain more slow‑query entries.

Adjust slowlog-log-slower-than based on concurrency; default >10 ms.

Use Redis as a simple message queue, noting its limited pub/sub capabilities.

Prefer BGSAVE over SAVE for RDB snapshots to avoid blocking.

Deploy read‑write separation when possible.

Implement distributed locks with Lua scripts.

Update the database before the cache to maintain consistency, handling possible cache deletion failures and brief inconsistencies.

Recommended Solutions

Prefix keys with the business name (e.g., mc:act_123456:share_count) for easy identification.

Keep key lengths short, using abbreviations to reduce memory overhead.

Use efficient serialization and compression (e.g., Snappy or Gzip) for values.

Prefer integer types when possible to leverage Redis's shared integer object pool.

Enable AOF with the Everysec policy for balanced durability and performance.

Enable both AOF and RDB persistence for dual protection.

Set appropriate expiration times for cached data to free memory.

Use MONITOR cautiously, as it can overflow output buffers under heavy load.

Avoid full‑scan commands (e.g., HGETALL , SMEMBERS ) on large collections; prefer SSCAN and HSCAN .

Deploy monitoring platforms such as CacheCloud for observability.

Distribute Sentinel nodes across different physical machines, with at least three nodes (odd number preferred) for reliable leader election.

Use Bitmaps for unique user counting to save memory.

Mitigate cache penetration with empty objects or Bloom filters.

Prevent cache avalanche by implementing client degradation, pre‑testing, layered caching, rate limiting, and staggered expirations.

Avoid cache breakdown by using mutex locks, keeping hot keys permanent, and periodically extending hot key TTLs.

For the latest electronic version, reply with Redis to receive the handbook.