Redis is like SQL if your connection goes, your whole site will likely go tits up. I've used Redis on numerous projects now and I've definitely experienced a few hidden gotchas along the way. If you want to be a champ at your work and avoid the same mistakes I made, then read on.
I started using Redis on this website, using the free demo credits you get with your MSDN license. I didn't realise that when you get a Redis server on your development license, halfway through the month it cuts out. When my Redis server cut off my whole site died instantly. When this happened I was away from my PC so there wasn't even an easy way to fix the issue without doing a code deployment. If you're using Redis, I strongly suggest that you plan for this. One option is to pay a little extra and get a clustered Redis to ensure you always have a connection. The other option is to have a quick and easy way to recover your website in case Redis goes down/isn't available. In my instance, I changed my code so I could turn it on and off via the Azure portal. If something goes wrong again, I can set a flag that will bypass Redis.
Like SQL, a Redis instance can be clustered. As of Redis 4.0.0 a number of improvements were made to Redis clustering and this is probably one of the easier options to ensure that your Redis server is always available.
Recently I had really bad performance issues on my website. I had disabled my Redis cache, however, I forgot that on application I was still running the Redis connect and getdatabase code. Even though I wasn't trying to add anything to the cache, or get any value from it. The call to GetDatabase() produced a memory leak in my website. After an IISRESET the site would work as expected for a while and then after a few hours the site would get slower and slower until IIS was rebooted.
If you're using Redis be aware that establishing a failed connection to Redis can cause issues. If you create a cache manager class then ensure that it's a singleton and that only one instance of the class can be created, otherwise, you could experience the same application tool hanging issues I ran into.
I worked for one client who had the Azure Redis monitor running on the infrastructure's team bank of monitoring monitors. Whenever there was a spike in Redis someone would come over and ask if there was anything wrong with Redis. As I explained to them, Redis is simply an advanced key/value store. If you have a spike in Redis then it means something is happening on your website. You can use the Redis monitor as a tool to make sure nothing untoward is going on with your website.
Yes and No. First, if you're used to using a session cache then you'll probably understand that if you could visualise the total amount of memory the session cache used in real-time, you would see a graph that would constantly jump up and down as new cache items get added and expire from the cache. Redis doesn't necessarily work this way, which can be confusing. Redis can be set to use a policy to only expire the cache when it's full. This means your cache might grow until it hits your max size and only at that point it will it start to clean up the cache. Redis can be configured in different ways (which is beyond this article) but it is something worth being aware of.On the other hand, the full key/value store must fit in RAM at all times, so depending on how your Redis is set-up, if you hit your max size you could encounter fatal issues. This is one of the reasons you need a semi-good knowledge about how to configure Redis. You need enough RAM to hold your entire set of data. So when you ask yourself if you should be concerned the safe answer should always be yes. My recommendation would be to test hitting your max limit locally and see what happens.
I've had a number of developers propose using Redis for the wrong thing. For example, as a log file storage which we could then 'query'. Redis is a key/value store and consequently, the paradigm of getting data in and out of it is completely different. Don't expect to be able to query data like in a database. If you need to query your data then it does not live within Redis!
This isn't a hard and fast Redis rule, however, my personal preference is to only use Redis to store temporary data that you can afford to lose. I tend to use Redis to store things like HTML fragments, user data etc.. I wouldn't use Redis to store data that I want to keep forever. The way I tend to architecture my projects is that anything stored in Redis I'm not too fussed if it gets deleted. Any data that is vital to the running of the system, I tend to store in a database, an application setting, or if I'm working with a CMS, then within the CMS itself.
When you start talking to Redis it is very likely that you'll be talking to database 0. It is possible to create different databases to allow better segregation of data within your application, all for free! In case you're wondering how many extra Redis databases you can create, then the answer is apparently 'unlimited'. The limiting factor is the available memory in the cluster. If your total Redis size is bigger than your allocated amount, then you need to worry. In the past I've tended to use one database for user sessions data, one to store HTML partial fragments etc.. If money isn't a factor, you can also consider using two or more Redis instances, rather than simplifying using a different database. For reference, one or more Redis databases can be used in a single instance (e.g. one cost), if you use two instances in the cloud, then you'll have to pay for two Redis servers. This separation is probably overkill for most situations, however, it means one Redis could go down while the other one is up.
Redis is a cool tool that I've used on a number of projects to great success. Redis is a lot more configurable than using something like normal in-memory session cache and there can be a few hidden gotchas if the Redis server is not available, or depending on how you've configured it. If you're planning on using Redis, I strongly recommend that you come up with a plan of what to do if Redis isn't available. One option is to pay for a clustered Redis instance to reduce the risk of that happening, another option might be writing some C# code to disable Redis completely if it goes down. A good site would probably do both. Anyway, I hope this article helps prepare someone out there, good luck!
Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge