As a high-performance in-memory database, Redis is widely used in current mainstream distributed architecture systems. To improve system fault tolerance, using multiple instances of Redis is also inevitable, but the complexity is much higher than that of a single instance. This article mainly introduces the four deployment modes of Redis and their advantages and disadvantages.
Standalone
Standalone mode is to install a Redis, start it, and business connects to it and that's all. The specific installation and startup steps are not repeated here. Standalone mode is also used in many scenarios, such as situations where high availability is not necessary.
Advantages:
- Simple deployment, zero cost.
- Low cost, no standby nodes, and no other expenses required.
- High performance, single-node does not need to synchronize data, and data has natural consistency.
Disadvantages:
- Reliability is not guaranteed, and there is a risk of node failure.
- Single-node high performance is limited by CPU processing power, and Redis is single-threaded.
- The choice of standalone mode needs to be based on one's own business scenario. If high performance and reliability are required, standalone mode is not very suitable.
Master-Slave
Master-Slave mode consists of N Redis instances, which can be 1 master with N slaves or N masters with N slaves (if N masters with N slaves, it is not strictly a master-slave mode, and we will discuss it in the subsequent cluster mode. N+N Redis instances are required for N masters with N slaves). One function of master-slave mode is to backup data so that when a node is damaged (meaning irreparable hardware damage), data can be easily recovered because there is a backup. Another function is load balancing. If all clients access one node, it will definitely affect the efficiency of Redis's work. With master-slave, query operations can be completed by querying the slave node. Since master-slave replication means that the data of the master and slave are the same, there is a problem of data redundancy. In system design, redundancy is allowed for high availability and high performance. For products that pursue ultimate user experience, downtime is absolutely not allowed.
Advantages:
- Once the master node fails, the backup slave node can take over at any time.
- Expand the read ability of the master node and share the read pressure of the master node.
- The cornerstone of high availability: In addition to the above functions, master-slave replication is also the basis for sentinel mode and cluster mode, so master-slave replication is the cornerstone of Redis high availability.
Disadvantages:
- Once the master node fails, the slave node needs to be promoted as the new master node and the application's master node address needs to be modified. It is also necessary to command all slave nodes to replicate the new master node, which requires manual intervention throughout the process.
- The write ability of the master node is limited by a single machine.
- The storage capacity of the master node is limited by a single machine.
- For example, as I just mentioned, there is a problem of data redundancy.
Sentinel
In a master-slave mode, when the master node goes down, the slave node can take over as the master node and continue providing service. However, there is an issue when the IP address of the master node changes. At this time, the application service still uses the original master node address to access, requiring manual intervention to modify. Sentinel can precisely solve this problem. Access to data in the Redis cluster is through the Sentinel cluster, which monitors the entire Redis cluster. Once a problem is detected in the Redis cluster, such as the master node going down, the slave node takes over. But when the master node address changes, the application service is unaware and does not need to change the access address because Sentinel interacts with the application service. Sentinel solves the problem of failover well, taking high availability to another level, and of course, Sentinel has other functions. For example, master node live detection, master-slave operation detection, and master-slave switching. The minimum configuration for Redis Sentinel is one master and one slave.
How it works
- Each Sentinel sends a PING command to all its master servers, slave servers, and other Sentinel instances at a frequency of once per second.
- If an instance has not responded to a PING command for a time longer than specified by down-after-milliseconds, the instance is marked by Sentinel as subjective offline.
- If a master server is marked as subjective offline, all Sentinel nodes monitoring the master server must confirm whether the master server has indeed entered the subjective offline state at a frequency of once per second.
- If a master server is marked as subjective offline, and a sufficient number of Sentinels (at least as specified in the configuration file) agree with this judgment within the specified time range, then the master server is marked as objective offline.
In general, each Sentinel sends an INFO command to all the master servers and slave servers it knows at a frequency of once every 10 seconds. When a master server is marked as objective offline by Sentinel, the frequency at which Sentinel sends INFO commands to all slave servers of the offline master server changes from once every 10 seconds to once per second. Sentinel and other Sentinel nodes negotiate the status of the master node. If the master node is in the SDOWN state, a vote is automatically cast to select a new master node. The remaining slave nodes are directed to replicate data to the new master node.
When there are not enough Sentinels to agree on the offline status of a master server, the objective offline state of the master server is removed. When a master server responds with a valid reply to a PING command from Sentinel, the subjective offline state of the master server is removed.
Advantages:
- Sentinel mode is based on the master-slave mode, and Sentinel mode has all the advantages of master-slave mode.
- The master-slave can switch automatically, making the system more robust and with higher availability.
- Sentinel continuously checks whether the master server and slave server are running normally. When a Redis server being monitored has a problem, Sentinel sends notifications to administrators or other applications through an API script.
Disadvantages:
- Redis is difficult to support online expansion. For clusters, online expansion becomes complicated when capacity reaches its limit.
Cluster
Master-slave cannot solve the problem of automatic fault recovery, and Sentinel can already solve the problem of automatic fault recovery. So why do we still need cluster mode? Master-slave and Sentinel still have other issues that have not been resolved. The storage capacity and access capacity of a single node are limited. Redis Cluster has high availability, scalability, distribution, fault tolerance, and other characteristics.
How it works
Data sharing is achieved through data sharding, while providing data replication and fault transfer functions. In the previous two modes, data was all on one node, and the storage capacity of a single node is limited. Cluster mode shards data and stores it on multiple nodes. When a shard reaches its limit, it is divided into multiple shards. Data is divided into 16384 slots (hash slots) in the key space of the cluster, and data is distributed to different shards based on hash, as follows:
HASH_SLOT = CRC16(key) & 16384
Data reading and writing after sharding: read requests are assigned to slave nodes, and write requests are assigned to the master node, and data is synchronized from the master to the slave node. Separating read and write requests improves concurrency and increases performance, as shown in the figure below.
Horizontal expansion after data sharding: The master node can be expanded, and data migration is automatically completed within Redis. When you add a new master node, data migration is required, but the Redis service does not need to be offline.
For example, there are three master nodes, which means that Redis slots are divided into three segments, assuming the three segments are 0-7000, 7001-12000, and 12001-16383, respectively. Now, due to business needs, a new master node is added, and the four nodes collectively occupy 16384 slots. The slots need to be re-assigned, and the data also needs to be migrated, but the service does not need to be offline. The Redis cluster's re-sharding is performed by the Redis-trib management software within Redis. Redis provides all the commands for re-sharding, and Redis-trib performs re-sharding by sending commands to the nodes.
Fault tolerance: If the red node in the middle fails, a master node will be generated through an election by the slave node under master3 to replace the failed node. This process is the same as the fault tolerance of the Sentinel mode, as shown in the figure below.
Why does Redis cluster have 16384 slots?
If the slot is 65536, the message header for sending heartbeat messages is too large, reaching 8KB. As mentioned above, the largest space in the message header is myslots[CLUSTER_SLOTS/8]. When the slot is 65536, the size of this block is 8KB: 65536÷8÷1024=8KB. Since Redis nodes need to send a certain number of ping messages as heartbeat messages every second, if the slot is 65536, the message header of this ping message is too large and wastes bandwidth.
The number of Redis cluster master nodes cannot exceed 1000. As mentioned above, the more cluster nodes there are, the more data is carried in the message body of the heartbeat package. If there are more than 1000 nodes, it will also cause network congestion. Therefore, it is not recommended to have more than 1000 Redis cluster nodes. For Redis cluster clusters with less than 1000 nodes, 16384 slots are enough. There is no need to expand to 65536. The smaller the slot, the higher the compression ratio when there are fewer nodes. In the Redis master node's configuration information, the hash slot it is responsible for is saved in the form of a bitmap. During transmission, the bitmap is compressed. However, if the filling rate of the bitmap slots/N is high (N represents the number of nodes), the compression rate of the bitmap is low. If there are few nodes and many hash slots, the compression rate of the bitmap is low.
Reference: Redis四种部署方式-今日头条 (toutiao.com)
