What the heck is Redis

Shubham Gupta
Ula Engineering
Published in
6 min readAug 6, 2020

--

You might have heard a term caching and NoSql data a lot. You might also have heard about Redis. But what is it exactly? How does it work? All these questions still persist. I know that tutorials are long and boring and not everyone wants to go in-depth but actually wants to know the overall architecture and working.

So in this article, I will be covering overall architecture and a few critical features which you should know about Redis. This will also help you to decide whether it’s helpful in your scenario or not. Also, it will help you to choose the model you want to adopt for Redis.

So what is Redis?

Redis is an open-source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams.

The one thing that needs to be remembered here is that Redis is an in-memory but persistent on-disk database, so it represents a different trade-off where very high write and read speed is achieved with the limitation of data sets that can’t be larger than the memory. Another advantage of in-memory databases is that the memory representation of complex data structures is much simpler to manipulate compared to the same data structure on disk, so Redis can do a lot, with little internal complexity.

All I can say about Redis is that its blazing fast, open-source, good community support, supports a wide variety of data types and easy to get started.

How is Redis so fast?

The reason is simple as the entire data resides in-memory, in contrast to databases that store data on disk or SSDs. By eliminating the need to access disks, in-memory data stores such as Redis avoid seek time delays and can access data in microseconds.

What all languages it supports?

Don’t worry about it. Redis supports most of the languages and very easy to integrate, it also has a good amount of documentation and community support.

Why should one choose Redis?

I am not sure whether it fits into your case and that you needs to be evaluated. But I can help you with giving an idea about its rich features which can help you to decide.

  1. Powerful and extremely fast in-memory database
  2. Store data in key-value
  3. Persistence. Optionally, you can save the data to disk
  4. Master-slave replication
  5. No Indexing
  6. No Query Language
  7. LUA Support
  8. Dynamic schema
  9. Supports Transactions
  10. Pub/Sub
  11. Keys can have TTL
  12. LRU Eviction of keys
  13. Automatic failover

There are so many lucrative things but should have some downsides as well

Yeah there are a few downsides as well

  1. Your dataset has to fit comfortably in memory
  2. No joins or query language
  3. You have to learn Lua if you want something like stored procedures

Where all we can leverage Redis?

It can be used in many places like

  1. Store and invalidate user sessions
  2. Caching
  3. Queues
  4. Notifications
  5. Chat, messaging, and queues
  6. Gaming leaderboards
  7. Real-time analytics/streaming

Now let’s deep dive into a few of its feature

As it’s an in-memory database, how will I recover my important data in-case of node failover?

That’s an important question and in production, we certainly need to consider this use case. To solve this problem redis do provides a few options to recover the data. Redis has the following persistence options.

  • No persistence, dataset in memory
  • RDB(Redis database file)
  • AOF(Append only file)
  • Hybrid(RDB & AOF)

RDB(Redis database file)

RDB makes a snapshot of the dataset at specific intervals. On every snapshot creation,new child process starts in addition to the parent process. The child process begins to write the dataset to a temporary RDB file. Once the child process finishes writing to the new RDB file, it replaces the old one.

AOF(Append only file)

AOF logs each write operation received by the server, that will be played again at server startup, restoring the original dataset.

Hybrid Approach(RDB & AOF)

This is the recommended approach in redis documentation. AOF provides data safety, and RDB delivers snapshots backup for disaster recovery.

Combining both AOF and RDB in the same instance is possible. In this case, when redis restarts, the AOF file will be utilized to reproduce the original dataset since it is assured to be the most complete.

What will happen in the case of my server goes down or if I have a large data set. Am I screwed?

Hey, don’t worry. Redis has already figured that out for you. There are 2 very good solutions available. So hold tight, we are going to have a look into both the models.

Redis Sentinel

  1. Redis sentinel is a system, designed to help & manage redis instances.
  2. The primary purpose of using sentinel is to provide a high availability system, by monitoring, notifying and providing instances failover.
  3. Sentinel performs three tasks
  • Monitoring: Check if your master and slave instances are working as expected.
  • Notification: Notify other programs or the system admin vai an API, when something goes wrong with the monitored instances.
  • Automatic failover: On master failure, sentinel promotes one of the slaves to a master, then makes the other additional slaves use the new master.

4. Sentinel act as a source of authority for clients. Clients connect to sentinel in order to ask for the address of the current Redis master.

5. Things to consider

  • At least 3 sentinel instances to run on a server that fails in an independent way.
  • Redis client must have sentinel support.
  • Redis Sentinel is a specific execution mode of the Redis server itself.
Redis Sentinel

Redis Cluster

  1. It is a data sharding solution with automatic management, failover and replication.

2. Data sharding is a method to break up a big DB into many smaller parts. It is the process of breaking up a DB across multiple machines to enhance the manageability, availability, performance and load balancing of an application.

3. The reason for data sharding is that, after a certain scale point, it is cheaper and more attainable to scale horizontally by adding more machines then to grow it vertically by adding beefer servers.

4. Cluster mode provides similar high availability to sentinel mode, but the sharding allows more data to be stored in the cluster. The cluster provides scalability to your application.

Redis cluster

Cluster VS Sentinel

  • Similarity: Both solutions provides high availability for your system.
  • Use sentinel when speed isn’t your primary concern, which makes it an excellent option for smaller implementation with high availability concerns.
  • Redis cluster provides high availability plus clustering solution, it’s an excellent choice to ensure high availability while keeping fast access speed in consideration to access your data.
  • Bottom Line: if you need an automatic failover solution without going to a full cluster solution, then use sentinel. For getting a complete clustering solution which splits your database in between multiple nodes then go for clustering.

Takeaway

So we have got a very abstract idea about Redis. We have seen 2 models of Redis and also looked into its features. Though there are a lot more interesting things to it like Redis transactions, Pub/Sub, replacement policies etc. But I would like to keep it short and for specific topics, you can have a look at the official documentation https://redis.io/documentation.

I hope you enjoyed the article. If you do then please let me know. Thank you!

--

--