21 Essential Redis Usage Tips to Avoid Common Pitfalls

Preface

Recently I have been studying Redis, reviewing Alibaba's Redis development specifications and the book "Redis Development and Operations". I organized 21 important points across usage standards, problematic commands, project practice, and operational configuration to help everyone learn Redis together.

1. Redis Usage Standards

1.1 Key Naming Guidelines

Use business name as key prefix, separated by colons, e.g., live:rank:1 , to avoid collisions. Keep key length under 30 characters when semantics are clear. Avoid special characters such as spaces, newlines, quotes, and escape characters. Set TTL for keys to ensure unused keys are cleared promptly.

1.2 Value Guidelines

Redis values should not be set arbitrarily.

First point : Storing large values (bigKey) can cause slow queries and rapid memory growth.

If the value is a String, keep size within 10KB.

If the type is hash, list, set, or zset, keep element count generally below 5,000.

Second point : Choose appropriate data structures. Many developers only use String with set and get, but Redis offers rich structures such as hash and zset that suit many scenarios.

Incorrect example :

set user:666:name jay
set user:666:age 18

Correct example :

hmset user:666 name jay age 18

1.3 Set Expiration and Disperse TTLs

Redis stores data in memory, which is a precious resource.

Redis is typically used as a cache, not a primary database, so keys should not have overly long lifetimes.

Use expire to set TTLs.

If many keys expire simultaneously, Redis may experience latency spikes or a "cache avalanche"; therefore, distribute expiration times across different business keys, optionally adding a random offset.

1.4 Use Batch Operations for Efficiency

Just like SQL batch updates, Redis batch commands reduce round‑trip time (RTT). Commands like mget and mset are efficient, but many commands lack batch support (e.g., hgetall). The Pipeline feature can group multiple commands into a single RTT.

Pipeline assembles a group of Redis commands, sends them in one RTT, and returns the results in order.

Without Pipeline, executing n commands incurs n RTTs; with Pipeline, the whole batch requires only one RTT.

2. Problematic Redis Commands

2.1 Beware of O(n) Commands (e.g., hgetall , smember , lrange )

Redis executes commands single‑threadedly; O(n) commands can cause CPU spikes and block other operations when the data size grows.

When hgetall processes many hash elements, consider using hscan instead.

2.2 Caution with monitor Command

monitor

prints every command received by the server and is meant for debugging only; using it in production can cause memory to balloon.

Running monitor generates a large output buffer on the server, consuming significant memory.

2.3 Do Not Use keys in Production

keys

scans the entire keyspace with O(n) complexity; on large datasets it blocks the single Redis thread and can halt the service.

Use scan instead; it iterates with a cursor, avoiding thread blockage but requiring client‑side deduplication.

2.4 Avoid flushall and flushdb

flushall clears all databases. flushdb clears the current database.

Both commands are atomic and cannot be interrupted once started.

2.5 Careful Use of del

Deleting a String key is O(1) and safe. Deleting List/Hash/Set/ZSet keys is O(n) where n is the number of elements, which can block the main thread for large collections.

For List, use lpop or rpop repeatedly. For Hash/Set/ZSet, scan the elements with hscan / sscan / scan and delete each individually.

2.6 Avoid High‑Complexity Commands like SORT , SINTER , ZUNIONSTORE

These commands consume significant CPU and can block the main thread; consider performing such aggregations on the client side.

3. Practical Project Pitfalls

3.1 Distributed Lock Considerations

Typical implementation uses SETNX + EXPIRE, but if the process crashes after acquiring the lock and before setting expiration, the lock becomes permanent.

if (jedis.setnx(key, lockValue) == 1) {
    expire(key, 100);
    try { /* business */ } finally { jedis.del(key); }
}

Storing expiration time in the client leads to clock sync issues and missing lock owner identifiers.

Client‑generated expiration times require synchronized clocks. Without a unique owner ID, other clients may accidentally release the lock. Concurrent getSet calls can cause one client to overwrite another's expiration.

Using the extended SET command with NX and EX is safer, but still suffers from lock expiration before business completion and possible accidental deletion.

if (jedis.set(key, uniqueId, "NX", "EX", 100) == 1) { /* business */ jedis.del(key); }

To avoid accidental deletion, verify the lock owner before releasing, but the check‑then‑delete is not atomic.

if (uniqueId.equals(jedis.get(key))) { jedis.del(key); }

Lua scripts provide an atomic check‑and‑delete:

if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
else
    return 0
end;

Redisson implements a watchdog to automatically extend lock TTL, mitigating premature expiration.

However, single‑node locks can fail during master‑slave failover; the Redlock algorithm addresses this issue.

3.2 Cache Consistency

Read: cache first, then DB.

Write: DB first, then cache.

Invalidate cache after each DB update.

Set appropriate TTLs.

For high consistency, use a log + MQ to guarantee ordering.

3.3 Avoid Overwriting Expiration

Setting a new value on a key removes its existing TTL, so frequent overwrites can unintentionally extend key lifetimes.

void setKey(redisDb *db, robj *key, robj *val) {
    if (lookupKeyWrite(db,key)==NULL) {
        dbAdd(db,key,val);
    } else {
        dbOverwrite(db,key,val);
    }
    incrRefCount(val);
    removeExpire(db,key); // removes TTL
    signalModifiedKey(db,key);
}

3.4 Cache Penetration

When a request queries a non‑existent value, the cache miss leads to a DB query each time, putting pressure on the database.

Cache penetration occurs when both cache and DB lack the requested data, causing every request to hit the DB.

Mitigation methods:

Validate request parameters at the API gateway to filter illegal values.

Cache a placeholder (e.g., null) for empty DB results, with an appropriate TTL.

Use a Bloom filter to quickly test existence before querying.

A Bloom filter uses a bitmap and multiple hash functions; if all corresponding bits are set, the key is considered present.

3.5 Cache Avalanche

Massive simultaneous expirations cause a surge of DB traffic; disperse TTLs by adding a random offset (e.g., 5 h + 0‑1800 s).

3.6 Cache Stampede

When a hot key expires, many concurrent requests may hit the DB. Solutions:

Use a mutex (e.g., setnx) to ensure only one request loads data and repopulates the cache.

Implement "never expire" with asynchronous refresh before expiration.

3.7 Hot Key Issues

Hot keys receive far more traffic than others, potentially overwhelming a single Redis node.

Read‑heavy, write‑light scenarios like flash sales. Uneven key distribution causing many requests to the same shard.

Identification methods include experience, client reporting, and proxy layer metrics.

Scale the Redis cluster (add shards/replicas). Hash‑shard hot keys into multiple replicas. Introduce a second‑level (local JVM) cache.

4. Redis Configuration and Operations

4.1 Use Persistent Connections and Proper Connection Pooling

Long‑lived connections avoid repeated TCP handshakes, reducing latency.

Connection pools keep a set of ready connections; configure idle timeout to release unused resources.

4.2 Use Only Database 0

Switching databases (e.g., select 0 vs select 1) adds overhead.

Redis Cluster supports only DB 0; using others complicates migration.

4.3 Set maxmemory and Appropriate Eviction Policy

Select a policy based on business needs (e.g., volatile-lru, allkeys-lfu, noeviction, etc.) to prevent out‑of‑memory crashes.

4.4 Enable Lazy‑Free Mechanism

From Redis 4.0 onward, lazy‑free offloads expensive memory reclamation (e.g., deleting big keys) to background threads, reducing main‑thread blocking.