Client Side Caching Support

[shacharPash]

Hi guys,

First off, thank you - thanks a tonne of the RESP3 changes. It was really helpful, as a result of this, I will extend NRedisStack's RESP3 support soon.

We've been thinking a lot about client side caching, and have started that work in a few client libraries. I wanted to take a stab at doing this in StackExchange.Redis, and thought about the following breakdown.

1. Add support for the redis commands by modifying src/StackExchange.Redis/Interfaces/IDatabase.cs: a. CLIENT.TRACKING b. CLIENT.TRACKINGINFO c. CLIENT CACHING

2. Extend the connection multiplexer to support a "light weight cache" doing something similar to:

   var conn = ConnectionMultiplexer.Connect("localhost:6379,protocol=3,caching=1");

and:

var config = new ConfigurationOptions
{
    // ...
    Caching = 1,
    // ...
};

using var conn = ConnectionMultiplexer.Connect(config);

3. Creating a cache object using something like MemoryCache, or anything you might suggest!

4. Process cache deletions and removals by handling the push notifications redis sends out as per that document above link When RESP3 is used instead, invalidation messages are sent (either in the same connection, or in the secondary connection when redirection is used) as push messages (read the RESP3 specification for more information).

5. Enable cache configuration by via the ConfigurationOptions in src/StackExchange.Redis/ConfigurationOptions.cs a. This includes optional support for whitelisting and blacklisting commands b. Allowing users to specify memory use, etc (@uglide, feel free to add more context)

What are your thoughts? Is there something I'm missing, or should consider? Do you have plans that perhaps I can join in on?

[mgravell]

I have some similar ideas in progress - see the server-cache-invalidation branch; I think it is a little more nuanced than "all on / all off", so I don't think it can be readily done at a global level; my plan was a new abstraction that wraps this. It is intended to support both RESP2 and RESP3, although it was based off the RESP2 build - it needs updating.

So yes: plans are afoot in that area. Improving distributed cache support is also a major objective in my MSFT role this year (for .NET 9), so: I expect to be able to invest a lot of time "officially".