Redis Solutions: Standalone vs Sentinel vs Cluster
What is Redis?
Redis is a fast in-memory NoSQL database and cache. Besides open-source, written in C, and designed for speed, Redis means “Remote Dictionary Server”.
Its fundamental data types are strings, lists, hashes, sets, and sorted sets; therefore Redis is often referred to as a data structure server. Many other data structures and capabilities for geolocation and stream processing are also available.
Redis’ various data structures are similar to the native data structures which are easily shared between processes and services, it’s great for rapid development and speedy applications.
Redis saves data in memory by default, with periodic disk persistence as an option. There are two kinds of disk persistence in Redis; RDB(Redis Database) and AOF(Append Only File). At certain intervals, RDB creates point-in-time snapshots of your dataset. AOF logs every write action received by the server, reconstructing the original dataset.
To prevent Redis from being full, you may set up a TTL(Time to live) to eject data when the specified amount of time elapsed.
This article focuses on Standalone Redis, Redis Sentinel for high availability, and Redis Cluster for automatic partitioning, as well as their advantages and disadvantages.
What is a Single Redis Instance?
It’s a solution using the single Redis node deployment architecture.
Standalone Redis Pros：
- Simple and classical architecture.(Image 1)
- Easy deployment and configuration.
Standalone Redis Cons：
- It is not suitable for data reliability requirements.
- There is no backup(slave) node for real-time data synchronization.
- Because Redis is a single-threaded mechanism, its performance is limited by the processing capacity of a single-core CPU. The major bottleneck is the CPU, which restricts the number of instructions that can be performed on a single computer.
What is Redis Sentinel?
It’s a solution that makes it easier to manage Redis instances. Since Redis 2.8, a stable release of Redis Sentinel has been available. Sentinel is a separate application that runs in the background. It will monitor your master and slave instances, alert you to any changes, manage automated failover in the event of a master failure, and perform as a configuration provider.
Quorum is configurable which only refers to the number of sentinels who must agree when a master is down. When in a failover scenario, sentinel instances attempt to reach a consensus, and at least three (odd number) sentinel instances will prevent most problems. These three Sentinel instances should also be placed on separate physical servers or Virtual Machines, as they are expected to fail in independent ways.
Redis Sentinel Pros:
- With three nodes, you can build up a fully functional Sentinel deployment. (Image 2)
- Simplicity - it’s usually simple to maintain and configure.
- Highly available, you can build a Redis Sentinel deployment that can survive certain failures without any need for human intervention.
- Work as long as a single master instance is available; it can survive the failure of all slave instances.
- Multiple slave nodes can replicate data from a master node.
Redis Sentinel Cons:
- Not scalable; writes must go to the master, cannot solve the problem of read-write separation.
- Slaves may serve reads, but because of asynchronous replication, outdated reads may result.
- It doesn’t shard data, so master and slave utilization will be imbalanced.
- The slave node is a waste of resources because it does not serve as a backup node.
- Redis-Sentinel must be supported by the client. The client holds half of the magic.
What is the Redis Cluster?
Data is automatically partitioned over many Redis nodes, resulting in a stable and reliable data service. So automatically split your dataset among multiple nodes. A cluster must have at least three master nodes to work correctly, with Redis recommending that each master have at least one slave and requires Redis version 3.0 or higher.
Every node should open two TCP connections. The standard Redis TCP port for serving clients. The second port is utilized for the Cluster bus, which is a binary protocol-based node-to-node communication.
If a master instance becomes unavailable due to network failures or software/hardware failures, the other Master nodes will notice by the Cluster bus and reach a failover state. After then, a suitable slave of the unavailable Master node will step forward and be promoted to become the new Master.
Redis Cluster Pros:
- It has no central architecture, automatically splits data among multiple nodes.
- Data is distributed among several nodes based on a hash slot, and data distribution can be adjusted dynamically.
- Scalability: Add and remove nodes in the cluster easily. Nodes can be added or removed dynamically, and the system can scale up to 1000 nodes.
- Automatic failover can be done by using Slave as a standby data copy. Because of supports the master-slave structure, you don’t need any additional failover handling, it has built-in failover of the master;
Redis Cluster Cons:
- You need at least 6 nodes — 3 master and slave. (Image 3)
- Not entirely highly available, the cluster will stop down if the majority of masters are unavailable in the case of a bigger failure.
- Data is replicated asynchronously, and there is no guarantee of data consistency.
- Because the replication structure only allows one layer, the slave node can only duplicate the master node.
- Because data is sharded among the masters, clients should have network access to all nodes in a Redis Cluster. If a client wants to write data to Master1 but the data belongs to Master2, Master1 will give the client a MOVE message, directing it to forward the request to Master2.
- Not every library supports; the lack of client library implementations in Redis Cluster.
- It is not possible to ensure a strong consistency. In practice, this means that Redis Cluster may lose writes that were acknowledged by the system to the client under certain circumstances.
- Because of data partitioning, data handling becomes more complicated; for example, you should handle multiple RDB / AOF files, and you need to aggregate the persistence files from multiple instances and hosts to generate a backup of your data. It is not possible to manage backups from a single location.
In this article, the advantages and disadvantages of various Redis solutions have been discussed. There are many factors to consider while selecting the best solution for your business cases. The following scenarios might help choose in this regard.
- You want to use Redis for testing, but don’t need high availability or data-reliability -> Use Standalone Redis
- If you need high availability, even if it is not scalable, and you have less data than RAM on a machine -> Use Redis Sentinel
- You need data sharding, scalability and automatic failover, it doesn’t have to be entirely highly available and you have more data than RAM on a server -> Use Redis Cluster
References:
