How Redis LFU Detects Hot Keys and Enables Client‑Side Caching

Redis 4.0 LFU‑Based Hot‑Key Detection

In many workloads some keys become hot, and identifying them is essential for performance tuning. Redis 4.0 adds a Least Frequently Used (LFU) based hot‑key detection mechanism that records access frequency using a 24‑bit field.

LFU concept in Redis

LFU stores a counter for each key; each access increments the counter. The 24‑bit field is split into a 16‑bit timestamp (minutes) and an 8‑bit counter. The counter grows logarithmically, not linearly, to avoid rapid saturation.

LFU algorithm details

The counter uses a probabilistic logarithmic increment (LFULogIncr). When a key is accessed, the counter is first possibly decremented (LFUDecrAndReturn) and then increased according to a probability that decreases as the counter grows.

<code>typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time or LFU data (high 16 bits = access time, low 8 bits = counter) */
    int refcount;
    void *ptr;
} robj;
</code>

The 8‑bit counter can represent values up to 255. To extend the usable range, Redis applies a log‑factor (default 10) that slows counter growth as it increases. The probability of increment is

1/((counter‑LFU_INIT_VAL)*log_factor+1)

, where

LFU_INIT_VAL

defaults to 5.

New keys receive an initial counter of

LFU_INIT_VAL

(5) to prevent immediate eviction.

Counter decay

To avoid counters only increasing, Redis introduces a decay factor (

lfu_decay_time

, minutes). If a key is not accessed for

n

decay intervals, its counter is reduced by

n

. The decay algorithm extracts the timestamp and counter from the 24‑bit field, computes elapsed minutes, and subtracts the appropriate amount.

<code>unsigned long LFUDecrAndReturn(robj *o) {
    unsigned long ldt = o->lru >> 8;               // high 16 bits = last decrement time
    unsigned long counter = o->lru & 255;          // low 8 bits = counter
    unsigned long num_periods = server.lfu_decay_time ? LFUTimeElapsed(ldt) / server.lfu_decay_time : 0;
    if (num_periods) {
        counter = (num_periods > counter) ? 0 : counter - num_periods;
    }
    return counter;
}
</code>

Configuration

Redis 4.0 adds two LFU eviction policies:

volatile-lfu

(only keys with an expiration) and

allkeys-lfu

(all keys). Two tunable parameters control LFU behavior:

lfu-log-factor

– larger values make the counter grow more slowly.

lfu-decay-time

– minutes after which the counter is decremented.

Redis 6.0 Client‑Side Caching

Problem statement

Client‑side caches must stay consistent with the server. Setting a static TTL can cause stale data or reduce cache effectiveness.

Tracking solution

Redis 6.0 introduces Tracking , which records which clients accessed which keys. When a key changes, the server pushes an invalidation message to the relevant clients.

Default (client‑specific) mode

The server maintains a

TrackingTable

mapping each client ID to the keys it has accessed. When a key is modified, only the clients that accessed it receive an invalidation message. The table stores a pointer to the key object and the client ID; entries are evicted when the table is full.

Broadcast mode

Clients can subscribe to key‑prefixes. The server does not store per‑client key lists, so memory usage is minimal. However, every key change matching a subscribed prefix is broadcast to all interested clients, which can increase network traffic.

RESP3 protocol

Redis 6.0 also adopts RESP3, adding richer data types and enabling more efficient invalidation messages.

References

Redis client‑side caching documentation