copy

You can make one redis instance copy another by sending the Slaveof IP port command to that instance. We call the instance being copied master and the instance performing the replication slave. Replication enables the master and slave to have the same database state.

Replication consists of two operations:

  1. Sync Synchronizes the slave database status with that of the master
  2. Command propagation When the master receives commands from the client, the database status changes constantly. Therefore, the slave status dynamically keeps the same with that of the master.

Synchronizing the two phases of sync:

  1. Slave sends the sync command to the master.
  2. After receiving sync, the master runs the BGsave command to generate an RDB snapshot and records all write commands received from the CLIENT.
  3. After generating an RDB, the master sends the RDB to the slave. The slave will load the RDB file to the database state when the master starts generating the RDB.
  4. The master then sends the write command from the cache to the slave, and the slave executes the write command to make the database status of the slave and master the same.

Command transmission

The master continuously propagates write commands sent by the client to the slave, and the slave executes the write commands to ensure that the database status of the slave and master are dynamically consistent.

What if the slave and master break?

Older versions of Redis would repeat the entire sync process to make the slave and master identical again, and then run the propagation command. But this is inefficient.

New version of Redis processing scheme

Let’s start with three concepts

  • Replication Offset The master and slave stores a replication offset. When the master propagates a write command to the slave, the replication offset of the master increases. When the slave executes this write command, the offset of the slave also increases. Therefore, the consistent status of the master and slave databases is equivalent to the same replication offset.
  • The replication backlog buffer master maintains a fixed size FIFO queue. Each time a write command is propagated to the slave, the corresponding command is written to the queue. Offsets corresponding to these commands are also recorded.

Operations performed after the slave and master are reconnected:

  1. The slave sends the psync command to the master to resynchronize data and send its offset to the master
  2. After the master receives the offset, if the backlog buffer queue contains the write command corresponding to the offset, it sends the write command and subsequent write commands to slave, which executes the write command and restores the database state to be consistent. We call this partial resynchronization.
  3. If no, full resynchronization is performed. The entire process of sync before.

note

  • The default size of the backlog buffer is 1M, depending on the situation.

Sentinel

Sentinel is a highly available solution offered by Redis.

The Sentinel system consists of one or more Sentinel instances. They can monitor one or more masters and all of their slaves. The Sentinel system can automatically failover when a master fails, making the service highly available.

Automatic failover

  1. If a master goes offline, sentinel selects a new master node from the slave nodes of the master.
  2. Sentinel notifies other slave nodes to copy the new master node.
  3. Sentinel will continue to monitor the previously offline master, and once it is restored, Sentinel will turn it into a slave of the new master.

So how does Sentinel tell if a master node is offline?

  • Subjective offline Each Sentinel instance periodically sends a ping message to all master nodes, and the master returns pong. Once Sentinel does not receive a valid PONG response for a period of time, the master is considered subjectively offline.
  • After a Sentinel instance determines that a master is subjectively offline, it will seek the views of other Sentinel instances on the master. If the number of sentinel instances of the master subjectively offline reaches a certain number, The Sentinel system determines that the master is objectively offline. And perform automatic failover on the master.

The cluster

Redis cluster is a distributed database solution provided by Redis. Data is distributed on different cluster masters, providing replication, failover, and other functions.

The data distribution of the Redis cluster is allocated by slot. The whole Redis cluster has a total of 16,384 slots, and all master nodes in the cluster divide all 16,384 slots. Each key is calculated by CRC16(Key) &16383 to determine which slot the key should be allocated to and which node it should be distributed to.

When a client sends a command to a node in the Redis cluster, such as get Name. The node receiving the command will check whether the slot corresponding to name is the node to process, if so, directly return the result. If not, it will want the client to respond to a Moved and send the node that can handle the key back to the client. The client then sends the get name command to the node that can handle the key.

In addition, redis clustering mode also supports online resharding. To transfer a slot processed by one node to another node for processing.