With all the clutter on the web, it's hard to find a good resource explaining what a technology is or does, Redis included. My goal with this post is to do it as simple as possible.
After reading it, you'll have a basic understanding of what Redis is, how it works and when to use it. For the ones interested in diving deeper, I'll be following up with a more in-depth guide for PHP clients for Redis explained, so stay tuned.
Let's start with the basics.
Definition of what is Redis?
Redis is a fast, open-source, in-memory key-value data structure store.
Yeah, sure... and that is?
Long story short, REDIS allows you to store key-value pairs on your RAM. Since accessing RAM is 150,000 times faster than accessing a disk, and 500 times faster than accessing SSD, it means speed.
But, we are already using RAM for most of our operations!
Yes, we do, but when it comes to cache, or database interactions, we use disks by default. Imagine accessing a database to read 10,000 records. If the data is stored on disk it will take an average of 30 seconds, while it takes around 0.0002 seconds to read from RAM.
What this means is that it’s a super-fast read/write system, but since it's stored in RAM it is volatile.
Wait! So, are we going to lose our data?
To prevent data loss from happening there is a built-in persistence module which writes the in-memory state to dump files on the disk on given occasions. The dump files are loaded when the system is starting and once it’s up and running the data is available for manipulations. So, no data loss.
We can play with different configurations with multiple instances, to allow us for a constant up-time with the so-called Sentinels and Master-slave Architecture. We'll discuss this later in this post.
But, what does Redis mean? It's an acronym for REmote DIctionary Server.
In other words, it's a tool that lets you have a database stored on your RAM.
Where and When to use Redis?
Since Redis is lightning fast, it is mainly used for caching purposes. It is where Redis shines the most since it offers a variety of types it can store with its dictionary structure.
That being said, we can use Redis to cache full pages that feature high traffic and static content. If the page itself is prone to changes or the content is generated dynamically, then it shouldn't be cached in any case regardless of whether it's Redis or Memcached we're using. If the page contains mostly static content or the content is refreshed every x period of time, then we can cache that page and have it served in no time!
So, number one on where to use Redis goes to Full Page Cache (FPC).
Another thing it can be used for is to store sessions. Unlike Memcached that has no persistence whatsoever, Redis has it and that allows for session storage. Handling the sessions with Redis boosts the user experience while interacting with the site.
Persistence is important for storing sessions, to avoid data loss in critical sections of the user interaction. For example processing a payment, adding an item to the shopping cart, or requesting any action as an authenticated user.
So, the second place goes to Session Cache.
Here is a good list of other options about when to use Redis.
Advanced
Now that we know what Redis is, where and why we should use it, it's time to get a bit more technical.
Redis runs as a process, the same way as MySQL, PHP, Apache, and all other services run. It uses a lot of RAM memory, and if the server needs more space for its heavy-duty lifting then it may choose to kill Redis' process. In this scenario, we would experience a downtime of the process with a potential data loss. To prevent this from happening Redis has a built-in Master-Slave architecture.
This architecture allows us to have additional processes that monitor our main one. The slave processes imitate its commands and occasionally copy the Master dump file to keep consistency between the processes. These monitor processes are called Slaves, while the main one is the Master.
When the main process is killed, one of the Slaves becomes the Master and processes all requests while the Master process is being rebooted. Once the Master is up again, it takes the dump file from the Temporary Master and uses that as a base. The main process is re-instantiated as Master while the Temporary Master goes back to being a Slave again.
But how do we know when the main process is down? And how do we know which Slave should become a master?
Well, here is where the Sentinels come into the game. Sentinels are the processes that have the specific duty to check if the instances of Redis are working. They are responsible for:
- Detecting if the Master is down;
- Selecting who the temporary master should be;
- Monitoring when the Master comes back and telling it which dump file to load.
Sentinels, I guess the name says it all.
A general set-up usually uses one Master, two Slaves, and three Sentinels.
What's next?
Redis has a nice community and well-written documentation. If you want to give it a try, you'll find plenty of support on their official website.
Getting started with Redis depends on the technology you are using. Different languages have different ways to interact with them. Their documentation covers it all. You can find a complete list of Redis clients here and even submit your own.
In the next blog posts, I'll be digging more into setting up Redis with WordPress and Laravel.
What this post helpful? Do you want more of them coming out? Let me know in the comments.
