Redis – What Is It and When Should I Use It?

Table of Contents

• Abstract
• Introducing Redis
• Redis as a database
  • Limitations
  • Excellences
• Example use case
  • Requirements
  • Redis’ answers
  • Redis’ bonus points
• Redis as a cache
  • Limitations
  • Excellences
• Example use cases
  • Requirements
  • Redis’ answers
  • Redis’ bonus points
• Redis as a message broker
  • Limitations
  • Excellence
• Example use case
  • Requirements
  • Redis’ answers
  • Redis’ bonus points
• Conclusion

Abstract

This blog post takes you on a tour of Redis: its use cases, and example deployments. We hope this article will be useful to you when architecting your Cloud Native applications.

Introducing Redis

According the website Redis.io:

But what does that actually mean? If it can do all that, then why do we need any other data services. There must be some nuances, some things redis is optimised for, and some caveats we should keep in mind when considering Redis in our applications.

Redis as a database

Limitations

• Database size limited to available memory
  • Sharding possible at the cost of losing some operations and increased latency
• 
NoSQL
  • Lua scripting is available
• Non relational
• No users, groups or access controls
  • Access is secured by one shared secret
• Less mature persistence options
  • 
Combining both RDB and AOF on disk formats can be reasonably robust

Excellences

• Speed
  • In memory data stores are fast
• Lua scripting
  • Operating on values in your databases memory is fast
• Helpful data/query types
  • Geospatial
  • Hyperloglog
  • Hash
• Binary safe
• Expiring records

Example use case

Imagine our app deals with users who are authorized to take different actions within our app. Each time we authenticated [or implicitly renew authorization] a user, we want to derive their authorization for controlling access in your app.

We might consider sending the full list of authorisations [packaged with a nonce and expiry then signed of course] to the user and having them send it to you with each action as proof of authorization. There is nothing wrong, cryptographically, with this approach [provided we use a good standard like JOSE and keep our key material safe], however, if users of our app has more than a couple of authorizations, this becomes very hard to scale, but there is another option we should contemplate.

Instead of sending the list of authorizations to the user, what if we store our users’ authorizations in some form of database and proved the user a unique key (token) that they must send us as proof of authorization? We can then use the key to look up the user’s authorization when they make a request. This of course doesn’t stop us sending the user a copy of their authorizations periodically for building our apps UI [for example], but we have made our authorisation system much more scalable.

Requirements

• Speed
  • We don’t want authorization to take very long
• 
Majority read access Scalability
  • We will likely be checking authorization more than driving it
• Associate a list with a key
  • A token authorizes many things
Store a relatively small amount of data
  • Authorization data is large enough to be network overhead but small enough to happily reside in RAM
• Best effort but not mission critical data persistence
  • It would be inconvenient if we had to regenerate authorization data but it expires anyway

Redis’ answers

• Speed
  • Redis is in-memory: it’s very fast
• Majority read access Scalability
  • Redis can be clustered with Sentinel that allow reads from slaves (replicas)
• Associate a list with a key
  • Redis has a plethora of list storage options the simplest of which being a set
• Store a relatively small of data
  • That’s good: it will fit in memory
• Best effort but not mission critical data persistence
  • RDB checkpoints sound like what we need

Redis’ bonus points

• Expiring keys
  • Tokens expire
• Hyperloglog
  • 
An efficient metric of authorizations is useful

Redis as a cache

Redis has mostly taken over from memcached as the defacto cache for modern web applications. Its binary friendliness along with convenient features make it ideal for caching all kinds of things.

Limitations

• Connecting to Redis via TCP is [almost certainly] slower than your local RAM
  • Obviously
• 
Key values can be no bigger than 512MB
• It doesn’t have magical AI and scrape your data store for things to cache preemptively

Excellences

• Sharing cache among instances of microservices via the network
• Convenient features like Lua scripting that make using caches easier
• Time based and contest based expiry

Example use cases

Let’s say that our app involves displaying items to users with some values sorted in varying ways. We have a lot of values in a data service (like MySQL) and we want to display the sorted versions frequently, so doing the sorting calculations each time we display the value is too costly, we need to cache our values in sorted order.

Requirements

• Can store sorted sets of values
• Can retrieve subsets of those sorted sets
  • If we need to do pagination
• Faster than doing the calculations on our data storage service every time

Redis’ answers

• Can store sorted sets of values
  • Ordered sets
• 
Can retrieve subsets of those sorted sets
  • 
Operations to retrieve ranges of ordered sets
• Faster than doing the calculations on our data storage service every time
  • 
In memory data store is fast

Redis’ bonus points

• Perform operations on sets with Lua
• 
High availability with Cluster or Sentinel
• 
Extras like coordinate operations

Redis as a message broker

Redis provides quick and basic pub/sub message brokering. Whilst not being as feature rich as other message brokers Redis has its uses.

Limitations

• Only simple pub/sub
• 
No queuing

Excellence

• Speed
• 
Stability

Example use case

Picture an app where users collaborate in real time. Real time collaboration means we need a way to inform every user about every other user’s actions. Our users might be being served by different instances of our app, so we need to deal with this communication between the different instances of our app.

Requirements

• Low latency
  • 
We don’t want our users to perceive lag in collaboration
• 
Stability
  • Users should have a smooth experience
• 
Horizontal scale
  • 
We want to support a lot of users

Redis’ answers

• Low latency
  • 
Very lite and simple
• Stability
  • 
Minimal moving parts
• 
Horizontal scale
  • 
Ability to Cluster

Redis’ bonus points

• Wild card subscriptions
• 
Binary friendly

Conclusion

Redis is a very useful data service for tying microservices together and following the 12 factor app principles. For workloads focusing on rapidly changing ephemeral data sets where privilege control is not a concern (i.e. apps that you trust enough or less sensitive data) Redis is a strong choice.

For workloads where the data needs protecting (i.e. is sensitive or hard to recreate) then Redis is less suitable and the workload may be better served by another data service (e.g. PostgreSQL, MongoDB, or Elasticsearch).

If Redis has sparked your interest, anynines have a variety of solutions to match your scale, you can get started deploying apps for free on a9s Public PaaS.