Redis 4.0 LFU Hot‑Key Detection Mechanism and Redis 6.0 Client‑Side Caching Overview

The article introduces Redis 4.0’s LFU (Least Frequently Used) hot‑key discovery mechanism, which leverages a 24‑bit field in each object to store a 16‑bit last‑access timestamp and an 8‑bit probabilistic counter. The counter grows logarithmically using a random‑based increment function, allowing high‑frequency keys to be identified without linear growth.

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time or LFU data (8‑bit counter + 16‑bit time) */
    int refcount;
    void *ptr;
} robj;

The 8‑bit counter is updated by LFULogIncr , which increments the counter with probability p = 1 / (baseval * server.lfu_log_factor + 1) . As the counter grows, p decreases, making further increments increasingly unlikely, resulting in a logarithmic growth pattern.

void updateLFU(robj *val) {
    unsigned long counter = LFUDecrAndReturn(val);
    // counter growth function
    counter = LFULogIncr(counter);
    val->lru = (LFUGetTimeInMinutes() << 8) | counter;
}

New keys receive an initial counter value defined by LFU_INIT_VAL (default 5) to avoid immediate eviction. The counter also decays over time based on lfu_decay_time , reducing the counter by one for each decay interval without accesses.

unsigned long LFUDecrAndReturn(robj *o) {
    unsigned long ldt = o->lru >> 8;               // last decrement time (minutes)
    unsigned long counter = o->lru & 255;          // current 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;
}

Configuration options lfu-log-factor and lfu-decay-time control the growth speed of the counter and its decay rate, respectively. The LFU algorithm is available in the volatile-lfu and allkeys-lfu eviction policies.

In Redis 6.0, client‑side caching is introduced via the Tracking feature. When tracking is enabled, the server records which clients accessed which keys. Upon a key change, the server pushes an invalidation message to the relevant clients, ensuring cache consistency.

Tracking operates in two modes:

Default mode : The server remembers each client’s accessed keys and only notifies those clients when their keys change.

Broadcast mode : Clients subscribe to key‑prefixes; the server broadcasts invalidation messages for all keys matching the prefix, requiring no per‑client state on the server.

Both modes rely on the RESP3 protocol (available from Redis 6.0) to deliver invalidation messages, with RESP2 compatibility via Pub/Sub when needed.

References: Redis client‑side caching documentation .