What are the cluster modes of redis?

There are generally 5 types of Redis clusters:

1, master-slave replication

2, sentinel mode

3, Cluster officially provided by Redis Cluster mode (server)

4, Jedis sharding cluster (client sharding)

5, using middleware agents, such as Wandoujia’s codis, etc.

After introducing their model, let’s analyze their principles now:

Master-Slave Replication:

The working principle of master-slave replication: after the slave node service starts and connects to the master, it will actively send a SYNC command. After receiving the synchronization command, the Master service master node will start the background save process and collect all received commands for modifying the data set. After the background process is completed, the Master will transfer the entire database file to the Slave to complete a complete synchronization. . The Slave slave node service saves and loads the database file data into memory after receiving it. After that, the Master node continues to transmit all the collected modification commands and new modification commands to the Slaves in sequence. The Slaves will execute these data modification commands this time to achieve final data synchronization.

If the link between Master and Slave is disconnected, Slave can automatically reconnect to Master, but after the connection is successful, a full synchronization will be automatically performed.

Master-slave replication configuration

Modify the configuration file of the slave node: slaveof masterip masterport

If a password is set, set it: masterauth master- password

Sentinel mode:

This mode is provided starting from Redis version 2.6, but the mode of this version at that time was unstable until Redis version 2.8 Later, the sentinel mode became stable. Whether it is the master-slave mode or the sentinel mode, these two modes have a problem. They cannot expand horizontally, and the high availability features of these two modes will be limited by the memory of the Master node.

The Sentinel process is used to monitor the working status of the Master server in the redis cluster. When the Master server fails, the Master and Slave servers can be switched to ensure high availability of the system.

The role of Sentinel process

Monitoring: Sentinel will constantly check whether your Master and Slave are operating normally.

Notification: When a problem occurs on a monitored Redis node, the sentinel can send notifications to the administrator or other applications through the API.

Automatic failover: When a Master fails to work properly, Sentinel will start an automatic failover operation. It will upgrade one of the Slaves of the failed Master to a new Master, and Let other Slaves of the failed Master change to copy the new Master; when the client tries to connect to the failed Master, the cluster will also return the address of the new Master to the client, so that the cluster can use the current Master to replace the failed Master. After the Master and Slave servers are switched, the contents of the Master's redis.conf, Slave's redis.conf and sentinel.conf configuration files will change accordingly, that is, there will be an extra line of slaveof in the Master's redis.conf configuration file. Configuration, the monitoring target of sentinel.conf will be changed accordingly.

How the Sentinel process works

Each Sentinel process sends a message to the Master server and Slave server in the entire cluster once per second. Send a PING command from the server and other Sentinel processes.

If the time since the last valid reply to the PING command exceeds the value specified by the down-after-milliseconds option, the instance will be marked as subjectively offline (SDOWN) by the Sentinel process. )

If a Master server is marked as subjectively offline (SDOWN), all Sentinel processes that are monitoring the Master server must confirm that the Master server has indeed entered once a second. Subjective offline state

When a sufficient number of Sentinel processes (greater than or equal to the value specified in the configuration file) confirm that the Master server has entered the subjective offline state (SDOWN) within the specified time range, then The Master server will be marked as objectively offline (ODOWN)

Under normal circumstances, each Sentinel process will notify all Master servers and Slave slaves in the cluster once every 10 seconds. The server sends an INFO command.

When the Master server is marked as objectively offline (ODOWN) by the Sentinel process, the frequency of the Sentinel process sending INFO commands to all Slave slave servers of the offline Master server will change from Changed from once every 10 seconds to once every second.

If there are not a sufficient number of Sentinel processes to agree to the Master server being offline, the objective offline status of the Master server will be removed. If the Master server sends the PING command to the Sentinel process again and returns a valid reply, the subjective offline status of the Master server will be removed.

Redis official Cluster cluster mode

Redis Cluster is a server Sharding technology, officially available since version 3.0.

In this figure, each blue circle represents a redis server node. Any two of their nodes are connected to each other. The client can connect to any node and then access any node in the cluster. Perform access and other operations on it.

Redis cluster data sharding

On each node of redis, there are two things, one is the slot (slot), which can be understood as a A variable that can store two values. The value range of this variable is: 0-16383. Another one is cluster. I personally understand this cluster as a cluster management plug-in. When our access key arrives, redis will obtain a result based on the crc16 algorithm, and then calculate the remainder of the result to 16384, so that each key will correspond to a hash slot numbered between 0-16383, through This value is used to find the node corresponding to the corresponding slot, and then automatically jumps directly to the corresponding node for access operations.

Jedis sharding cluster

Redis Sharding can be said to be a commonly used method in the industry before the Redis cluster came out. Its main idea is to use the hash algorithm to store the key of the data. Hash, so that a specific key is assigned to a specific node.

Fortunately, the Java Redis client driver Jedis already supports the Redis Sharding function, namely ShardedJedis and ShardedJedisPool combined with the cache pool

The Redis Sharding implementation of Jedis has the following characteristics:

Use a consistent hash algorithm to hash the key and node name at the same time, and then perform mapping and matching. The algorithm used is MURMUR_HASH. The main reason for using consistent hashing instead of simple hash-like modulo mapping is that when nodes are added or removed, rehashing due to rematching will not occur. Consistent hashing only affects the key allocation of adjacent nodes, and the impact is small.

In order to avoid consistent hashing only affecting adjacent nodes and causing node allocation pressure, ShardedJedis will virtualize 160 virtual nodes according to the name of each Redis node (no, Jedis will assign a default name). Hash. According to the weight, 160 times of virtual nodes can also be virtualized. Using virtual nodes for mapping matching allows keys to be moved and distributed more evenly among Redis nodes when adding or reducing Redis nodes, instead of only adjacent nodes being affected.

ShardedJedis supports the keyTagPattern mode, which is to extract a part of the keyTag for sharding. In this way, by naming the key appropriately, a group of related keys can be put into the same Redis node, which avoids accessing related data across nodes. Very important.

Using middleware agent

The role of middleware is to calculate a value from the key of the data we need to store in redis through a set of algorithms. Then find the corresponding redis node based on this value, and store the data in this redis node.

Commonly used middleware include these types

Twemproxy

Codis

nginx

The above is the detailed content of What are the cluster modes of redis?. For more information, please follow other related articles on the PHP Chinese website!