This paper records and learns the knowledge summary and understanding about master-slave replication, Sentinel and cluster in the third part of Redis Design and Implementation.

Primary/secondary replication

In single-node deployment, once a node is faulty, services may become unavailable. The master-slave cluster is used to solve this problem and improve availability. In addition, the master-slave cluster separates read and write operations from those of the master database to reduce read pressure on the master database.

Master/slave replication includes full replication, command propagation based on long links, and incremental replication.

After the slaveof IP port command is executed on the secondary node, the first full replication is performed after the primary/secondary relationship is established.

1. For the first full synchronization, the master node starts the bgSave child process to create the full RDB and send it to the slave node.

2. After receiving the RDB file from the primary node, clear the local data and load the RDB file.

2. Command propagation: Write commands generated during full synchronization are cached in the replication buffer. The primary node sends write commands in the replication buffer to secondary nodes for execution.

The network between the primary and secondary nodes is disconnected – Incremental replication

Before version 2.8, full replication is performed after the primary and secondary nodes are disconnected, resulting in low efficiency.

Starting from 2.8, when the network is disconnected and reconnected, incremental replication is performed on the primary and secondary nodes.

When the primary and secondary nodes are disconnected and reconnected, the write command is obtained from the REPL_backlog_buffer buffer for incremental synchronization based on the offset of the primary and secondary nodes.

Why RDB and not AOF for full copy?

1. RDB file content is compressed binary data, while AOF file records the command of each write operation. The more the write operation, the larger the file will become, including many redundant operations on the same key for many times.

2, from the library through the RDB snapshot to load data fast, AOF to execute commands one by one;

2. Sentinel mechanism

The sentinel node is a special instance of Redis, especially because the command set of the sentinel node is different from that of the common Redis node. The sentinel node cannot execute data operation commands, but can execute commands such as PING and INFO. The sentinel cluster is used to monitor the Redis cluster and failover master nodes to ensure high availability.

The Sentinel node creates two connections with all the Redis master-slave nodes. One is to subscribe to the _sentinel:hello channel. One is command wiring.

Subjective vs. objective logoff

The sentry will send the ping command to the Redis node (master and slave) every second. According to the response of the node, it can be divided into:

  • Valid response: +PONG, -loading, or -masterDown is a valid response within the specified time (set to down-after-milliseconds)
  • Invalid response: any response other than the above three or no response within the specified time is invalid

If there is no invalid response, the sentry marks it as a subjective offline.

When the sentry determines that a primary node is subjectively offline, in order to confirm whether the node is objectively offline, it will ask other sentries monitoring the node and send is-master-down-by-addr command. When receiving all replies, more than or equal to quonum sentries determine that the primary node is subjectively offline. The primary node is an objective offline node.

After deciding that the master node is objectively offline, the sentinels cluster elects the lead sentinels (via the Raft algorithm, not expanded here), and the lead sentinels then failover.

Third, the cluster

Redis nodes use the cluster meet command to complete the handshake between nodes and establish connections. After the connection is established, the nodes periodically send ping/pong commands to each other to exchange data information (node information, status, etc.).

Each Redis node has a clusterNode to store node information. When the node joins the cluster, there will be a clusterState structure to store the information status of the cluster, as shown in the following figure:

Through the cluster meet command, nodes information in clusterState will be updated during connection between nodes.

The entire database of the cluster is divided into 16384 slots. The slots for each node can be assigned via Cluster Addslots. The attribute slots in the clusterNode structure records which slots the node is responsible for:

struct clusterNode {
	unsigned char slots[16384/8];
	int numslots;
}
Copy the code

Meanwhile, the clusterState structure stores the assignment information of 16,384 slots as follows:

struct clusterState {
	clusterNode *slots[16384];
}
Copy the code

ClusterState slots provides O(1) time to locate a node that corresponds to a slot.

Execute commands in the cluster

In a cluster environment, when a client sends a database command to a node, it calculates which slot the key belongs to. If the slot is assigned to the current node, the client runs the command. If the indicator of the slot is not the current node, the system returns MOVED to the client and information about the node assigned to the slot. Then, run the command again.

Calculate which slot the key belongs to: CRC16(Key) & 16383

Why 16,384 slots?

  • The data sent contains the slot information array slots of nodes [16383/8]. If there are too many slots, the data packets transmitted each time will increase, because the detection between nodes is very frequent, which will affect the transmission efficiency and easily cause network congestion

  • Generally speaking, the number of nodes in a Redis cluster is not recommended to exceed 1000. 16,384 slots are sufficient

Four, reference

  • Redis Design and Implementation

  • www.cnblogs.com/rjzheng/p/1…