My learnings on Redis thus far which you may find useful:
- Location of Redis should be close to your app.
- Data structures within Redis, larger key value sizes lead to fragmentation of memory space and these larger memory requirements means more network data transfer, Redis states to use 100KB maximum, this will affect the transfer time allocated from the app. It could time out if the data request is big.
- Creating connections is expensive (can cause latency) hence reuse connection or at least close older ones before releasing them.
- Expiration times, expiration sliding strategies etc – this is for your Developers to decide for their apps.
- Redis commands are single threaded, use them with caution, for example KEYS command may ruin performance.
- You need to cater for possible failover issues. An unplanned failover might happen because of hardware failure, network failure, or other unexpected outages to the primary node. Developers should use the runtime maintenance notifications on a publish/subscribe (pub/sub) channel called
AzureRedisEvents. Many popular Redis client libraries support subscribing to pub/sub channels. Receiving notifications from the
AzureRedisEventschannel is usually a simple addition to your client application.
- Persistence of data? If you need persistence (RDB), then this is only available on premium upwards. This allows you to persist data stored in Redis. You can also take snapshots and back up the data. If there’s a hardware failure, you load the data.
- If you want this you need Azure Storage, you can leverage Managed Identities for access.
- Scaling tips, for Redis you scale up if you are hitting memory thresholds and scale out if you are hitting CPU thresholds (enable clustering)
- Within the app in Azure what nuget packages are needed? Will it be dotnet add package Microsoft.Extensions.Caching.StackExchangeRedis –version 6.0.3 and StackExhange.Redis or Microsoft.Extensions.Caching.Redis.Core ? it’s important to know this because some work with cache sharding and some don’t.