Would there be any risk if I migrate from default named cache to several custom named caches?

[jundayin]

I'm currently building up the metric monitoring for the FusionCache hit ratio. I notice that the only way to differentiate the ratio number by cache scenario is using named cache. Currently we are using default named cache and we have to split it into several named caches in order to obtain the granularity.

Now, since the application is already running on remote environment and the cache presenting in the Redis already. Would there be any risk if I directly update DI registration to use different named cache?

For example, this is the current setup

services
  .AddFusionCache()
  .WithOptions(o =>
  {
    o.EnableAutoRecovery = true;
    o.DisableTagging = true;
  })
  .WithDefaultEntryOptions(o => o.SetFailSafe(false))
  .WithDistributedCache(new Microsoft.Extensions.Caching.StackExchangeRedis.RedisCache(new RedisCacheOptions() { Configuration = redisCacheSettings.ConnectionString }))
  .WithBackplane(new RedisBackplane(new RedisBackplaneOptions { Configuration = redisCacheSettings.ConnectionString }))
  .WithSerializer(new FusionCacheSystemTextJsonSerializer());

It should be fine if I change the code to

RedisCacheSettings redisCacheSettings = Configuration.GetSection(nameof(RedisCacheSettings)).Get<RedisCacheSettings>();
services
  .AddFusionCache("A")
  .WithOptions(o =>
  {
    o.EnableAutoRecovery = true;
    o.DisableTagging = true;
  })
  .WithDefaultEntryOptions(o => 
  {
    // configuration for A
  })
  .WithDistributedCache(new Microsoft.Extensions.Caching.StackExchangeRedis.RedisCache(new RedisCacheOptions() { Configuration = redisCacheSettings.ConnectionString }))
  .WithBackplane(new RedisBackplane(new RedisBackplaneOptions { Configuration = redisCacheSettings.ConnectionString }))
  .WithSerializer(new FusionCacheSystemTextJsonSerializer());

services
  .AddFusionCache("B")
  .WithOptions(o =>
  {
    o.EnableAutoRecovery = true;
    o.DisableTagging = true;
  })
  .WithDefaultEntryOptions(o => 
  {
    // configuration for B
  })
  .WithDistributedCache(new Microsoft.Extensions.Caching.StackExchangeRedis.RedisCache(new RedisCacheOptions() { Configuration = redisCacheSettings.ConnectionString }))
  .WithBackplane(new RedisBackplane(new RedisBackplaneOptions { Configuration = redisCacheSettings.ConnectionString }))
  .WithSerializer(new FusionCacheSystemTextJsonSerializer());

My understanding is the named cache won't create additional prefix to the cache itself as well as the backplane channel in Redis until dev explicitly set it in the code, which means the named cache will still reading from the existing cache keys from Memory/Redis as default cache does and all existing Redis PubSub event of cache update will be still intact, even if there is another application update the same cache key using FusionCache without named cache. Is this correct?

Also could you please help confirm whether this is following the best practice of registering the redis connection? I have a doubt because of this post

[jundayin]

Tested it on our secondary cluster and verified that the cache key remained the same while the backplane channel in Redis is changed with named cache

Which means somehow I need to ensure all pieces of code are aligned with the new named cache

[jodydonetti]

Hi @jundayin , sorry for the delay.

Now, since the application is already running on remote environment and the cache presenting in the Redis already. Would there be any risk if I directly update DI registration to use different named cache?

I would say no, and as you already verified thanks to me being late 😅, that is the case.

My understanding is the named cache won't create additional prefix to the cache itself as well as the backplane channel in Redis until dev explicitly set it in the code, which means the named cache will still reading from the existing cache keys from Memory/Redis as default cache does and all existing Redis PubSub event of cache update will be still intact, even if there is another application update the same cache key using FusionCache without named cache. Is this correct?

Ok so in general this is correct, BUT watch out though for one important detail.

When sharing an underlying cache (either L1 or L2) WITHOUT specifying a cache key prefix, you will:

• NOT HAVE problems when working wirh specifie keys
• HAVE problems when working with higher-level features, like Tagging or Clear (which is itself based on Tagging)

So in general I would go with a CacheKeyPrefix and a BackplaneChannelPrefix, to avoid surprises down the road.

Also could you please help confirm whether this is following the best practice of registering the redis connection? I have a doubt because of this post

Yes, your registration looks correct: at most, to save on connections, you may create an IConnectionMultiplexer per-named-cache and share the multiplexer with both the distributed cache and the backplane.

Hope this helps.