Skip to content

Client-Side Caching

Native implementation

Client Side caching is implemented using client tracking listener through RESP3 protocol, which is available in both Valkey and Redis.

This technique is used for performance optimization of read operations and avoid network roundtrips. Client Side caching stores data entries on Redisson side which allows to execute read operations up to 45x faster in comparison with common implementation.

Requires protocol setting value set to RESP3.

Available for RBucket, RStream, RSet, RMap, RScoredSortedSet, RList, RQueue, RDeque, RBlockingQueue, RBlockingDeque objects.

Warning

Client side caching feature invalidates whole object per entry change which is ineffective.
Use Advanced implementation instead which implements invalidation per entry.

RClientSideCaching object is stateful and each instance creates own cache.

Code usage example: 

RClientSideCaching csc = redisson.getClientSideCaching(ClientSideCachingOptions.defaults());

RBucket<String> b = csc.getBucket("test");

// data requested and change is now tracked
b.get();

// ...

// call destroy() method if object and all related objects aren't used anymore
csc.destroy();

Advanced implementation

Native client side caching technique in the previous section is effective only on a per-object basis. Unfortunately, this is not sufficient for data structures like Map or Hash. Because the cache invalidation message doesn't contain any information about the invalidated entry and only includes the object name, it's impossible to evict a specific entry. As a result, only clearing the entire cache can help keep the client cache up to date.

To address this issue Redisson provides own client cache aka local cache implementations for the structures below: