3 modes of redis cluster

1. Master-slave mode architecture

The difference between SYNC and PSYNC

After the master-slave synchronization is completed, if the slave server is down for a period of time, it will be necessary to resynchronize the master server after it is back online. The difference SYNCfrom the  PSYNCcommand is the processing method of the re-replication stage after the disconnection.

  • The SYNC
    slave server re-initiates a SYNCcommand to the master server  , and the master server regenerates all the data and sends the RDB snapshot to the slave server to start synchronization
    re-initiates a PSYNCcommand from the server to the master server  . The master server judges whether a complete resynchronization is needed or only the write command executed during the disconnection period is sent to the slave server according to the deviation of the data between the two parties.

Obviously, PSYNC is much more efficient than SYNC. It is important to know that synchronizing all data is a very resource-intensive operation (disk IO, network), and it is very worthless to synchronize all resources only because of short-term network instability.

How does PSYNC achieve partial resynchronization?

The realization of partial resynchronization mainly depends on three parts

1. Record the copy offset

Both the master server and the slave server maintain a replication offset.

  • When the master server sends N bytes of data to the slave server, it will copy its own offset +N.
  • When the slave server receives N bytes of data from the master server, it will copy its own offset +N.

When the data of the master and the slave are synchronized, the offset is equal. Once one of the slave servers is disconnected for a period of time and less data is received. Then the server offsets of the master and slave are not equal at this time, and the difference between them is the number of bytes transferred less. If the amount of data transferred is not very large and does not exceed the size of the replication backlog buffer of the master server , then the buffer content will be directly sent to the slave server to avoid complete resynchronization. On the contrary, it still needs to be fully resynchronized.

2. Copy the backlog buffer

The replication backlog buffer is a first-in, first-out byte queue maintained by the master server, and the default size is 1mb. Whenever a write command is sent to the slave server, the data will be stored in this queue. Each byte records its own copy offset. When the slave server reconnects, it will send its own replication offset to the master server. If the data after the replication offset exists in the replication backlog buffer, it only needs to send the subsequent data to the slave server.

3. Record the server ID

When performing master-slave synchronization, the master server will send its own server ID (usually an automatically generated UUID) to the slave server. After the slave server recovers from a disconnection, it will determine whether the ID is the currently connected master server. If it is the same ID, it means that the main server has not changed and tried partial resynchronization. If it is not the same ID that represents a change in the main service, it will be completely resynchronized with the main server.

The specific flow chart is as follows:

Redis sentinel mode (Sentinel)

Although the Redis master-slave mode can do very good data backup, it is not highly available. Once the main server is down, the main server can only be switched manually. Therefore , the sentinel mode of Redis is to solve the high-availability solution of the master-slave mode .

Sentinel mode introduces a Sentinel system to monitor the master server and all slave servers it belongs to. Once the master server is found to be down, one of the slave servers will be automatically selected to be upgraded to the new master server to achieve the purpose of failure escape.

The same Sentinel system also needs to be highly available, so it is generally a cluster and will monitor each other. Sentinel is actually a Redis server in a special mode.

Realization principle

1. Sentinel establishes a connection with the master-slave server

  • After the Sentinel server is started, it will create a command connection to the main server and subscribe to the ** sentinel : hello channel of the main server to create a subscription connection**
  • Sentinel will send INFO commands to the master server every 10 seconds by default  , and the master server will return the information of the master server itself and the information of all its slave servers.
  • According to the information returned, if the Sentinel server finds that a new slave server is online, it will create a command connection and a subscription connection to the slave server at the same time as when connecting to the master server .

2. Determine whether the main server is offline

Each Sentinel server will send PINGcommands to all connected instances (including the master server, slave server, and other Sentinel servers) every second  , PONG and determine whether the instance is offline according to whether it responds to the  command.

Judging subjective offline

If the instance is within PINGthe down-after-milliseconds milliseconds (according to the configuration) of receiving the  command, there is no valid reply. Then the instance will be PINGconsidered subjectively offline by the Sentinel that initiated the  order.

Judging objectively offline

When a main server is judged to be offline without a certain Sentinel server, in order to ensure that the main server is really offline, Sentinel will confirm with other servers in the Sentinel cluster. If the Sentinel server that judges the main server to go offline reaches When a certain number (usually N/2+1), then the main server will be judged to be objectively offline, and failover is required.

3. Election leader Sentinel

When a main server is judged to be offline, the Sentinel cluster will elect a leading Sentinel server to perform failover operations on the offline main server. The entire election is actually implemented based on the RAFT consensus algorithm. The general idea is as follows:

  • Each Sentinel that discovers that the main server is offline will ask other Sentinels to set themselves as the local leader Sentinel.
  • The received Sentinel can agree or reject
  • If a Sentinel is supported by more than half of the Sentinel, it will become the leader Sentinel in this election.
  • If the leader Sentinel is not elected within a given period of time, the election will restart after a period of time until the leader Sentinel is elected.

4. Election of a new master server

The leading server will select the most suitable one from the services as the new primary server. The selection rules are:

  • Select the slave node that is in a healthy state, and exclude INFOthe slave servers that are disconnected and have not recently responded to  commands.
  • Select the slave server with high priority configuration
  • Select the server with the largest copy offset (indicating the most complete data)

After the new master server is selected, the leader server will send a SLAVEOF no onecommand to the new master server to  actually upgrade it to the master server, and modify the replication targets of other slave servers, and set the old master server as a slave server to achieve the failure Transfer.

Redis Cluster

The Redis sentinel mode achieves high availability and separation of reads and writes, but there is still only one master node, that is, write operations are all in the master node, which has also become a performance bottleneck.

Therefore, Redis has added the Cluster mode after 3.0. It is implemented by removing unintentional nodes. The cluster will save the key-value pairs in the database through sharding.


A Redis cluster will consist of multiple nodes, and each node is connected to each other, and will store information about itself and other nodes. The nodes exchange the state of each other through the gossip protocol, and keep the information of the newly added nodes.

Sharding of data

The entire database of the Redis Cluster will be divided into 16384 hash slots. Each key in the database belongs to one of these 16384 slots. Each node in the cluster can have 0 or a maximum of 16384 slots.

Set slot assignment

Through commands,  CLUSTER ADDSLOTS <slot> [slot...] we can assign one or more slots to a node.

For example, the> CLUSTER ADDSLOTS 1 2 3 4 5 command is to assign slots 1, 2, 3, 4, and 5 to the node with a local port number of 7777.

After setting, the node will send the information of slot assignment to other clusters, and let other clusters update the information.

Calculate which slot the key belongs to

def slot_number(key):    return CRC16(key) & 16383 

Calculating the location of the hash slot actually uses the CRC16 algorithm to calculate the key value and then modulo 16383 to get the final slot.

You can also use it  CLUSTER KEYSLOT <key> to view.

Sharding process

  1. When the client initiates an operation instruction on the key-value pair, it will be arbitrarily assigned to one of the nodes
  2. The node calculates the slot to which the key value belongs
  3. Determine whether the current node is the slot to which the key belongs
  4. If yes, execute the operation command directly
  5. If not, return a moved error to the client. The moved error will carry the correct node address and port, and the client can directly redirect to the correct node after receiving it.

High availability of Redis Cluster

Each node of Redis can be divided into a master node and a corresponding slave node. The master node is responsible for processing slots, and the slave node is responsible for copying a certain master node, and when the master node goes offline, it replaces the offline master node.

How to achieve failover

In fact, similar to the sentinel mode, each node of Redis will periodically send Ping messages to other nodes to check whether the other party is online. When a node detects that another node is offline, it will be set as suspected offline. If more than half of the nodes in a machine set a master node as suspected offline, the node will be marked as offline and start failover.

  1. A new master node is selected from the slave nodes of the offline master node through the raft algorithm
  2. The selected slave node executes the  SLAVEOF no one command and becomes the new master node
  3. The new master node revokes the slot assignments of the offline master node and points these slots to itself
  4. The new master node broadcasts itself from the slave node to the master node to the cluster
  5. The new master node begins to accept and is responsible for processing the relevant command requests of the slot

to sum up

This article mainly introduces the three cluster modes of Redis, and summarizes

  • The master-slave mode  can realize read-write separation and data backup. But it’s not “highly available”
  • The sentinel mode  can be regarded as the "highly available" version of the master-slave mode, which introduces Sentinel to monitor the entire Redis service cluster. But because there is only one master node, there is still a write bottleneck.
  • The Cluster mode  not only provides a high-availability method, but also the data is stored in fragments in each node, which can support high-concurrency writing and reading. Of course, the implementation is also the most complicated.