In today’s world of distributed applications, having a cache solution that can scale with an application is a prerequisite for success. Caching in the AspNet world has typically been tied to the Application Pool and accessed through the
HttpContext.Current.Cache object. When the Application Pool was recycled, so too was the cache. When moving a web application to the cloud (be it Azure or any other cloud vendor) this can be problematic due to the transient nature of cloud applications. When you move your web application to a different Azure App Service or virtual machine, be it for deployment purposes or otherwise, that cache is no longer there and, in many cases, it can be vital for the cache to survive that transition to ensure no downtime.
Redis is an advanced key-value store which runs as a stand alone application/service on either Linux or Windows. It runs completely from memory and has the ability to persist the data to a separate permanent storage location. Clients, such as your web application, connect to it over HTTP/HTTPS and leverage it as a cache solution or a general data store. Since Redis is a separate stand-alone service it does not rely on the availability of your web application for its life-cycle management.
More Than a Cache
The “advanced” part of the description is speaking to the ability of Redis to hold the values as complex types. Redis has the ability to hold values for the several data types. These data types allow for advanced scenarios of caching while keeping the interaction with this data very fast. The data types most often used are as follows:
- String (Binary Safe – meaning that they are consistently stored whether being encoded on a Windows machine or a Linux machine)
- Hash (a set of name-value pairs – think of it as a cache within Redis but it lives within one single Redis key/value entry)
- List (Implemented as a Linked List – great for adding and removing to the beginning or end of the list but not for accessing directly by index like a random access would allow)
- Sets (an unordered collection of strings which allow operations to be applied between different Sets in Redis, like unions, intersections, or differences)
- Sorted Set (Just like a Set but with an added “score” property which allows for the collection to be ordered)
Something that isn’t necessarily a data type but lends itself to the “advanced” moniker is the fact that Redis also has a built-in Pub/Sub mechanism.
Works Across Network and Device Boundaries
Since Redis is a stand-alone service, it can be leveraged across several different network boundaries and device topologies. This is great for web applications that have the need to be scaled out (i.e. multiple web servers behind a load balancer). It’s also beneficial when used with an application that has been deployed as a collection of micro-services. All the individual micro-services can share the same cached data which allows for a more consistent real-time data sharing experience. Also, since Redis has a built-in Pub/Sub mechanism, the individual micro-services can leverage Redis for fast, inter-service communication.
While Redis runs completely in memory it has the ability to persist that data to disk or some other persistent data store location. This allows for data to be available after events such as a server failure or restart. You can also take that data and restore it to another Redis instance somewhere else.
Running During Development
Availability on Azure
Redis is available as a service on the Azure platform with options for several different usage tiers. You can also setup your own Redis instance on an Azure VM. The advantage of the Azure Redis-as-a-Service offering is the added management capabilities. Things like revoking or renewing access keys, setting the max-memory policy, data import/export, usage metrics, and much more. When running on a VM, one would have to manually set that up.
Using Redis as the cache solution for any application is a pretty straight forward choice and an easy one to make at that.