Why Client‑Side Caching Is Needed and How Redis Tracking Works

Redis is widely used as a caching layer to improve data‑access performance, but hot data can still cause latency spikes; therefore many companies add a client‑side cache to store frequently accessed keys locally and avoid repeated network trips.

Typical hot‑key examples include viral topics such as "996福报" or trending celebrity news, which generate massive read traffic.

Beyond Redis, a second cache layer (e.g., Memcached) is often introduced. The lookup flow is:

Check Memcached; if hit, return the value.

If miss, query Redis; on hit, store the result in Memcached.

If Redis also misses, fetch from MySQL and populate both Redis and Memcached.

Accessing local memory is inherently faster than a network call to Redis, so this multi‑layer approach dramatically reduces latency and offloads Redis.

What to cache

Avoid caching keys that change constantly.

Avoid caching keys that are rarely requested.

Cache keys that are frequently read and change at a moderate, predictable rate; global counters updated with INCR are a bad candidate.

Redis client‑side caching mechanism (tracking)

Redis implements a server‑assisted client cache called tracking . The client command is:

CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]

Redis 6.0 provides two tracking modes for RESP3 (normal and broadcast) and a forwarding mode for RESP2.

Normal mode

When tracking is enabled, Redis records every key a client accesses. If a key’s value changes, Redis sends an invalidation message to the client via RESP3 or forwards it to a separate connection using RESP2 + Pub/Sub.

The server stores key → client‑ID list mappings in a global TrackingTable (a radix tree).

Each client has a unique numeric ID; when a client disconnects, its entries are removed.

The table does not differentiate databases, simplifying implementation.

Note: The server sends only one invalidation message per key change; subsequent modifications are reported only after the client issues another read that is tracked.

Clients must enable tracking before issuing read commands, e.g.:

CLIENT TRACKING ON
+OK
GET user:211
$3
公众号:码哥字节

Broadcast mode (BCAST)

In broadcast mode the server does not keep per‑client key lists, so it consumes no memory. Instead, it broadcasts invalidation events for all keys (or for keys matching a registered prefix) to every subscribed client.

Because broadcasting every key can be noisy, applications usually register a prefix (e.g., user ) so that only keys with that prefix trigger notifications.

client tracking on bcast prefix user

Redirect (forwarding) mode

RESP2 clients cannot receive server‑pushed messages directly. A RESP3 client acts as a proxy: it subscribes to the special channel _redis_:invalidate and the server forwards invalidations to that channel.

Example workflow:

// Client B (RESP2) – subscribe to invalidation channel
SUBSCRIBE _redis_:invalidate

// Client A (RESP3) – enable tracking and redirect to B's ID (606)
CLIENT TRACKING ON BCAST REDIRECT 606

Client B then receives invalidation messages via the subscribed channel.

References

https://redis.io/topics/client-side-caching https://colobu.com/2020/05/02/redis-client-side-caching/ https://time.geekbang.org/column/article/310838 https://juejin.cn/post/6844904153827786760