21 Essential Redis Practices: Key Design, Pipelines, Locks, and Performance Tips

Redis is widely used as an in‑memory cache, and following proper usage patterns is crucial for performance and stability. This article organizes 21 important points into four sections: usage standards, problematic commands, project‑level pitfalls, and operational configuration.

1. Redis Usage Standards

Key naming: Prefix keys with the business name and separate parts with colons (e.g., live:rank:1) to avoid collisions; keep keys under 30 characters when possible; avoid spaces, line breaks, quotes, and other special characters; set a TTL for keys to enable automatic cleanup.

Value limits: For String values keep size ≤10KB; for hash, list, set, zset keep element count ≤5,000. Choose the most suitable data structure instead of defaulting to String.

Expiration: Use EXPIRE to set TTLs; stagger expiration times across different business keys to prevent a sudden surge of expirations that could cause cache‑snowball effects.

Batch operations: Prefer commands like MGET, MSET or pipelines to reduce round‑trip time (RRT). For commands lacking native batch support (e.g., HGETALL), use PIPELINE to send multiple commands in a single RTT.

2. Commands with Pitfalls

Avoid O(N) commands: HGETALL, SMEMBERS, LRANGE can spike CPU on large datasets; consider HSCAN or similar incremental scans.

Monitor: Use only for debugging; in production it can consume large memory and degrade performance.

KEYS: Never use in production; it scans the entire keyspace with O(N) complexity. Use SCAN instead, handling possible duplicate results on the client side.

FLUSHALL / FLUSHDB: These commands are atomic but will wipe all data; use with extreme caution.

DEL: Deleting a String key is O(1); deleting complex types is O(N) based on element count. For large collections, consider iterative deletion via LPOP / RPOP or scanning then HDEL / SREM / ZREM.

High‑complexity commands: Avoid SORT, SINTER, SINTERSTORE, ZUNIONSTORE, ZINTERSTORE on large data; perform aggregation in the application layer when possible.

3. Project‑Level Pitfalls

Distributed locks: Common patterns using SETNX + EXPIRE can leave stale locks if the process crashes before setting expiration. Better approaches include:

Combine SET with NX and EX in a single atomic command.

Store a unique request ID and verify it before deletion (Lua script ensures atomicity).

Use Redisson or the Redlock algorithm for safety across multiple nodes.

Cache consistency: Read‑through pattern (cache → DB) and write‑through pattern (DB → cache) should be followed; always invalidate or update the cache after a write, and set appropriate TTLs. For strict consistency, consider a write‑ahead log (biglog) plus a message queue.

Capacity planning: Re‑setting a key overwrites its TTL, so frequent overwrites can unintentionally extend key lifetimes. The source code of setKey shows that removeExpire is called on overwrite.

Cache penetration: Queries for non‑existent data repeatedly hit the DB. Mitigation strategies:

Validate request parameters at the API gateway.

Cache a placeholder (null or empty) with a short TTL when DB returns no result.

Use a Bloom filter to pre‑filter definitely‑absent keys.

Cache snowball: Massive simultaneous expirations cause a DB overload. Distribute TTLs by adding a random offset (e.g., base 5 h + 0‑1800 s).

Cache breakdown (hot‑key stampede): When a hot key expires, a surge of requests may hit the DB. Solutions include using a mutex (e.g., SETNX) to ensure only one request repopulates the cache, or keeping the key “never expires” and refreshing it asynchronously.

Hot‑key handling: Identify hot keys via experience, client metrics, or proxy reports. Mitigate by:

Scaling Redis cluster (adding shards/replicas).

Sharding the hot key into multiple sub‑keys.

Adding a local JVM cache as a second‑level cache.

4. Redis Configuration & Operations

Connection management: Prefer long‑lived connections with a connection pool; short connections incur TCP handshake overhead.

Database selection: Use only db0 in standalone mode; switching databases adds latency and is unsupported in Redis Cluster.

Memory limits & eviction policies: Set maxmemory and choose an appropriate maxmemory-policy (e.g., volatile-lru, allkeys-lfu, noeviction) based on workload.

Lazy‑free: Enable lazy freeing (Redis 4.0+) to offload large key deletions to background threads, reducing main‑thread blocking.

By adhering to these guidelines, developers can avoid common Redis pitfalls, maintain high throughput, and ensure system reliability.