Master Redis 6.0 Client‑Side Caching: Tracking, Options, and Practical Telnet Tests

Redis 6.0’s new features were decided through iterative discussion and optimization. Many of them were previewed in earlier RC versions, but the final GA release adds several changes:

SSL

ACL with better command support

RESP3

Client‑side caching redesign

Threaded I/O

Diskless replication on replicas

Cluster support in redis‑benchmark and improved redis‑cli cluster support

Disque in beta as a Redis module, entering the message‑queue space

Redis Cluster Proxy

Immediate deletion of unused RDB files

PSYNC2 optimized replication protocol

More friendly timeout settings

20‑30 % faster RDB loading

STRALGO new string commands, currently only LCS (longest common subsequence)

Antirez noted that this is the largest version update in Redis history, urging thorough testing before production use. A bug introduced in 6.0.0 was quickly fixed in 6.0.1.

The article focuses on the client‑side caching feature.

smallnest/RESP3 is a Redis RESP3 protocol parser library that can be used to communicate with Redis at a low level or to build a new client or server.

The idea for client‑side caching was inspired by Ben Malec’s talk at RedisConf 2018. Companies often cache hot data on the client side to handle sudden spikes, such as viral events on social platforms.

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

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

When tracking is enabled, Redis remembers the keys requested by each client and sends an invalidation message when a key’s value changes. The message can be delivered via RESP3 or forwarded to another connection (RESP2 + Pub/Sub). Various options modify this behavior:

REDIRECT : forwards invalidation messages to another client.

BCAST : enables broadcast mode; clients receive invalidation messages for all tracked keys, even if they never requested them.

PREFIX : registers a key prefix; only keys matching the prefix trigger invalidation messages in broadcast mode.

OPTIN : without broadcast, only keys accessed after CLIENT CACHING YES are tracked.

OPTOUT : without broadcast, only keys accessed after CLIENT CACHING OFF are tracked.

NOLOOP : prevents sending invalidation messages to the client that performed the update.

Testing environment setup

Install Redis 6.x (e.g., 6.0.1) from the official source, compile, and start the server on port 6379:

make distclean
make
make test
sudo make install

Start the server: redis-server Connect with redis-cli (default to localhost:6379) or telnet for raw RESP3 output.

BCAST broadcast mode ( client tracking on )

Start Redis server and connect with telnet:

Enable RESP3: hello 3 Enable tracking and read a key:

client tracking on
+OK
set a 1
+OK
get a
$1
1

When another client updates a, the telnet client receives an invalidation message:

set a 2
OK
>2
$10
invalidate
*1
$1
a

Tracking specific key prefixes ( client tracking on )

Register prefixes a and user with broadcast mode:

client tracking on prefix a bcast
+OK
client tracking on prefix user bcast
+OK

Updates to keys matching the prefixes generate invalidation messages, while other keys do not.

OPTIN – selective tracking

With OPTIN, only keys accessed after CLIENT CACHING YES are tracked.

client tracking on optin
+OK
get a
$1
2
client caching yes
+OK
get a
$4
1000
>2
$10
invalidate
*1
$1
a

OPTOUT – selective untracking

With OPTOUT, only keys accessed after CLIENT CACHING OFF are tracked.

client tracking on optout
+OK
get a
$4
3000
>2
$10
invalidate
*1
$1
a

To exclude a specific key, disable caching for that key:

client caching no
+OK
get b
$1
3

NOLOOP – avoid self‑invalidations

When NOLOOP is set, the client that modifies a key does not receive its own invalidation message.

client tracking on bcast noloop
+OK
set a 1
+OK
client tracking off
+OK
client tracking on bcast
+OK
set a 1
+OK
>2
$10
invalidate
*1
$1
a

REDIRECT – forwarding invalidations

Use REDIRECT to forward invalidation messages to another client (useful for RESP2 compatibility):

client list
id=4 addr=127.0.0.1:61017 ...
client id
:12
SUBSCRIBE __redis__:invalidate
*3
$9
subscribe
$20
__redis__:invalidate
:1
client tracking on bcast redirect 12
set a 1000
OK
*3
$7
message
$20
__redis__:invalidate
*1
$1
a

The implementation of the tracking feature resides in tracking.c.