Redis Hot Keys

A hot key is one that receives far more traffic than any other. Because a key lives on exactly one node and commands execute in one thread, a hot key makes one core the ceiling for the whole cluster.

Finding them

# Requires maxmemory-policy to be an LFU policy; reports keys by access frequency.
redis-cli --hotkeys
 
# Sample live commands. Attaching costs throughput — use briefly.
redis-cli --stat

In a cluster, an imbalance in INFO commandstats or in per-node operations per second is often the first sign: one shard doing several times the work of its peers, with an even slot distribution.

Mitigations

Client-side caching. The cheapest fix for a read-hot key is not to ask Redis. Redis 6's client tracking (CLIENT TRACKING ON) invalidates local caches when the value changes, so application instances can hold the value locally and stay correct.

Replicate the key. Write the same value under N suffixed keys and have each client read a random one:

suffix = random.randint(0, 9)
value = r.get(f"shop:config:featured:{suffix}")

The keys hash to different slots, so the read load spreads across shards. The cost is that writes must update all N copies, so this suits values that are read constantly and written rarely.

Read from replicas. For read-hot keys where staleness is acceptable, direct reads to replicas (READONLY in cluster mode). This does not help a write-hot key.

Aggregate writes. For counters, accumulate in the application and flush periodically with INCRBY, trading exactness of the instantaneous value for a large reduction in command rate.

Write-hot keys

A key that is written constantly cannot be spread by replication. Options:

• Shard the counter. Maintain counter:{n} for n in 0..15, increment a random one, and sum on read. Reads become 16 operations instead of one; writes spread over 16 slots.
• Move the aggregation. If the exact live value is not needed, aggregate in a stream or in the application and materialise periodically.

Preventing recurrence