Generally, there are two ways to host and utilize Redis:
- Single Node: Setting up and using a single node is straightforward, with no replication or data distribution challenges.
- Multi-Node: The multi-node deployment comes in three types
- Replication (one master with several replicas)
- Cluster (several masters and several replicas)
- Sentinel (one master with several replicas and several sentinel services to monitor master node status)
Based on our application requirement you would choose one of the deployment types, each of these types has pros and cons which we have covered here. Find more about Redis deployment on their official website.
📼You can find the video of this article on my YouTube channel
Single Node
It means we will have just one instance of Redis on one single machine which servers as both Read and write command
- Pros 🟢
- Easy to Setup
- Easy to Maintain
- Well-suited for testing purposes and small applications
- Cons 🔴
- It’s not write-scalable
- It’s not Read-Scalable
- It’s not Highly-available
- When To Use ⏲️
- For those applications, data loss is not a big problem
- Amount of Data and Number of requests are low
- High availability is not a concern
Multi-Node
It means we have more than one instance of Redis which can be Master or Replica. There are three types of Multi-Node deployment Replication, Cluster, and Sentinel.
Replication
We have one master instance and based on your requirement can have one or multiple replica instances
- Pros 🟢
- Easy to setup
- Read scalability
- Cons 🔴
- Lack of Write scalability
- Lack of high availability
- Limited amount of data in the master node
- When To Use ⏲️
- You have low write request and high read request
- You have a low amount of data
- High availability is not a concern
Cluster
In Cluster mode, we have several masters and several replicas per master. to have write-scalability and read-scalability. Data is distributed between masters which mostly should be down on the client side, thus This deployment has more complexity rather than the previous one, also In case There is an operation that is going to apply to several keys that are located on different masters, it will fail. This deployment is the best approach in big systems with scalabilities and availability requirement
- Pros 🟢
- High-availability
- Write-scalability
- Read-Scalability
- Cons 🔴
- Lack of Multi-Key operation support
- Data distribution complexity and overhead
- When To Use ⏲️
- You have a big amount of data
- You need scalability in both the write and read part
- You need highly available service
Sentinel
In Sentinel mode, we have the same setup as Replication, But the difference here we have also several instances of Sentinel service, which are responsible for monitoring the master node status. In case the Sentinel service finds the master unreachable, tries to communicate with other Sentinel services in other to be sure about the master status. In case the majority of Sentinel services are reached to this point that the master is not functional, one of the Sentinel will be elected to take care of the failover process.
Then one of the replica instances will be promoted as the master node and the system will continue to server write and read requests, in this way, we will have a highly available service with only one Master node.
- Pros 🟢
- High-availability
- Cons 🔴
- Lack of Write-Scalability
- Limited amount of data in the master node
- When To Use ⏲️
- You have low write request and high read request
- You have a low amount of data
- High availability is a concern
That’s all, Hope you’ve enjoyed the article, feel free to contact me and send me your comments.
Cheers, Matt Ghafouri