Shulou(Shulou.com)06/02 Report--

This article mainly introduces the Redis master-slave architecture of the establishment of what the relevant knowledge, the content is detailed and easy to understand, simple and fast operation, has a certain reference value, I believe that after reading this Redis master-slave architecture of the establishment of which articles will have some gains, let's take a look.

Master-slave environment building

Redis instances are all master nodes by default, so we need to modify some configurations to build master-slave architecture. The construction of redis master-slave architecture is relatively simple. Redis provides three ways to build master-slave architecture. We will introduce it later. Before introducing, we need to understand the characteristics of master-slave architecture: there is one master node (master) and at least one slave node (slave) in master-slave architecture. And data replication is one-way, can only be copied from the master node to the slave node, not from the slave node to the master node.

The way of establishing the master-slave architecture

There are three ways to establish a master-slave architecture:

Add the slaveof {masterHost} {masterPort} command to the Redis.conf configuration file, which will take effect with the launch of the Redis instance

Add the-- slaveof {masterHost} {masterPort} parameter after the redis-server startup command

Use the command directly under the redis-cli interaction window: slaveof {masterHost} {masterPort}

The Redis master-slave architecture can be built in the above three ways. We will demonstrate it in the first way, and try the other two ways on our own. Because it is a demonstration, we will start two Redis instances locally instead of starting redis instances on multiple machines. We will prepare a master node instance of port 6379 and an instance of a slave node of port 6480. The redis instance configuration file for port 6480 is named 6480.conf and adds a slaveof statement to it, with the following statement at the end of the configuration file.

Slaveof 127.0.0.1 6379

Start two redis instances respectively, and after they start, they will automatically establish a master-slave relationship. We will talk about the principle behind this in detail. Let's first verify whether our master-slave architecture has been successfully built. We first add a piece of data to the 6379 master node:

New data for master node

Then get the data on the 6480 slave node:

Slave node acquires data

We can see that we have successfully obtained the new values in the master node on the slave node, indicating that the master-slave architecture has been successfully built. We use the info replication command to view the information of the two nodes. First, let's take a look at the information of the master node.

Master info replication

You can see that the instance role of port 6379 is master, there is an instance being connected, and there is other running information. Let's take a look at the redis instance information of port 6480.

Slave info replication

You can see that the two nodes record each other's information about the object, which will be used in data replication. It is important to note that by default, the slave node is read-only and does not support writing, and it is not recommended to enable writing. We can verify that a piece of data is written on the 6480 instance.

127.0.1 READONLY You can't write against a read only replica 6480 > set x 3 (error). 127.0.0.1purl 6480 >

Prompt read-only, does not support write operations, of course, we can also modify the configuration, in the configuration file replica-read-only yes configuration item is used to control read-only from the server, why only read-only? Because we know that replication is one-way and the data can only be sent from master to slave node. If writing is enabled on the salve node, then the data of the slave node is modified, which is imperceptible to the master node, and the data of the slave node cannot be copied to the master node. This will cause data inconsistency, so it is recommended that the slave node read only.

Disconnection of master-slave architecture

The disconnection of the master-slave architecture is also a slaveof command. Executing the slaveof no one command on the slave node can break the follow relationship with the master node. We execute the slaveof no one command on the 6480 node.

127.0.0.1 slaveof no one OK 6480 > info replication # Replication role:master connected_slaves:0 master_replid:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_replid2:e5c1ab2a68064690aebef4bd2bd4f3ddfba9cc27 master_repl_offset:4367 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4367 127.0.0.1 Replication role:master connected_slaves:0 master_replid:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_replid2:e5c1ab2a68064690aebef4bd2bd4f3ddfba9cc27 master_repl_offset:4367 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4367 6480 >

After executing the slaveof no one command, the role of the 6480 node is immediately restored to master. Let's take a look at the time when it is still connected to the 6379 instance, and we add a key-value on the 6379 node.

127.0.0.1 6379 > set y 3 OK

Get y on 6480 nodes

127.0.0.1 get 6480 > y (nil) 127.0.0.1 purl 6480 >

We cannot get y on the 6480 node because the 6480 node has been disconnected from the 6379 node, and there is no master-slave relationship. The slaveof command can not only disconnect, but also switch the master server. Using the command slaveof {newMasterIp} {newMasterPort}, we make 6379 the slave node of 6480, execute the slaveof 127.0.0.1 6480 command on the 6379 node, and let's take a look at the info replication of 6379.

127.0.0.1 6379 > info replication # Replication role:slave master_host:127.0.0.1 master_port:6480 master_link_status:up master_last_io_seconds_ago:2 master_sync_in_progress:0 slave_repl_offset:4367 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea master_replid2:0000000000000000000000000000000000000000 master_repl_offset:4367 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size : 1048576 repl_backlog_first_byte_offset:4368 repl_backlog_histlen:0 127.0.0.1 purl 6379 >

The role of the 6379 node is already slave, and the primary node is 6480, so we can take a look at the info replication of 6480 nodes.

127.0.0.1 6480 > info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6379,state=online,offset=4479,lag=1 master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea master_replid2:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_repl_offset:4479 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4479 127.0.0.1purl 6480 >

There are 6379 slave nodes on the 6480 node, you can see that the slaveof command has helped us to complete the switch of the master server.

The principle of replication technology

The master-slave architecture of redis seems to be very simple. We successfully built the master-slave architecture after executing a command, and there is no problem with data replication. It is really easy to use, but behind this, redis still helps us do a lot of things, such as data synchronization between master-slave servers, status detection of master-slave servers, and so on. How is redis implemented behind this? Next, let's take a look at it.

Principle of data replication

After we execute the slaveof command, our master-slave relationship is established. In this process, there are several steps between the master server and the slave server, as shown in the following figure:

Principle of redis replication

Behind the slaveof command, the master and slave server has roughly gone through seven steps, in which permission verification is not necessary. In order to better understand these steps, let's take the redis instance we built above as an example to talk about each step in detail.

1. Save the master node information

When the 6480 client sends the slaveof 127.0.0.1 6379 command to the 6480-node server, we get an OK immediately.

127.0.0.1 slaveof 6480 > 127.0.0.1 6379 OK 127.0.0.1 6480 >

At this time, the data replication work does not begin, and the data replication work does not begin until the OK is returned. At this time, what the 6480 slave node does is save the given master server IP address 127.0.0.1 and port 6379 to the server state's masterhost attribute and masterport attribute.

2. Establish a socket connection

After the slaveof command is executed, the slave server will create a socket connection with the master server according to the IP address and port set by the command. If the slave server can successfully establish a socket connection with the master server, then the slave server will associate a file event handler dedicated to the socket to handle the replication work, which will be responsible for the subsequent replication work. For example, accept fully copied RDB files and write commands from the server. Similarly, after accepting the socket connection from the slave server, the master server will create a client state for the socket. At this time, the slave server has both server and client identities. The slave server can send a command request to the master server and the master server will return a command reply to the slave server.

3. Send ping command

After a successful connection between the slave server and the master server, the first thing to do is to send a ping command to the master server. The main purpose of sending the ping command is as follows:

Detect the availability of network sockets between master and slave

Detect whether the primary node can currently accept processing commands

After sending the ping command, the master server will normally return the pong command. After receiving the pong reply from the master server, it will proceed to the next step. If it does not receive a pong reply from the master node or times out, such as the network timeout or the master node is blocking and unable to respond to the command, the slave server will disconnect the replication connection and wait for the next scheduled task to be scheduled.

4. Authentication

After the slave server receives the pong reply from the master server, the next step is to decide whether authentication is required based on the configuration information:

If the masterauth parameter is set from the server, authentication occurs

If the slave server does not set the masterauth parameter, no authentication occurs

When authentication is required, the slave server will send an auth command to the master server with the command parameter of the slave server masterauth option. For example, if the masterauth parameter is set to: 123456 in the configuration of the slave server, then the slave server will send the auth 123456 command to the master server. The authentication process is not smooth, and the following situations may be encountered:

If the password sent by the slave server through the auth command is the same as the requirepass parameter value of the master server, the subsequent operation will continue. If the password is inconsistent, the master service will return an invalid password error.

If the primary server does not set the requirepass parameter, the primary server will return a no password is set error

All error conditions cause the current replication work to be aborted from the server and restart the replication process from the establishment of the socket until authentication is passed or replication is abandoned from the server.

5. Send port information

After the authentication is passed, the slave server will execute the REPLCONF listening command to send the listening port number of the slave server to the master server. For example, in our example, the port monitored by the slave server is 6480, then the slave server will send a REPLCONF listening 6480 command to the master server. After receiving this command, the master server will record the port number in the slave_listening_port attribute of the client status corresponding to the slave server. This is the port value we see in the info replication of the master server.

6. Data replication

Data replication is the most complex piece, which is completed by the psync command. The slave server sends a psync command to the master server for data synchronization. Before version 2.8of redis, the sync command was used. In addition to the different commands, there is also a great difference in the way of replication. Before version 2.8of redis, full replication is used, which will cause great overhead to the master node and the network. After redis 2.8, data synchronization will be divided into full synchronization and partial synchronization.

Full replication: generally used in the initial replication scenario, both new and old versions of redis will perform a full copy when the slave server connects with the master service for the first time. It will send all the data of the master node to the slave node at once. When the data is large, it will cause great overhead to the master node and the network. The early version of redis only supports full replication, which is not an efficient way of data replication.

Partial replication: used to deal with data loss scenarios caused by network flash breaks in master-slave replication. When the slave node is connected to the master node again, if conditions permit, the master node will reissue the lost data to the slave node. Because the reissued data is much smaller than the full data, the excessive overhead of full replication can be effectively avoided. Partial replication is a major optimization of the old version of replication, which effectively avoids unnecessary full replication operations.

The reason why redis can support full replication and partial replication is mainly due to the optimization of the sync command. After version 2.8 of redis, a new psync command is used. The command format is: psync {runId} {offset}. The meaning of these two parameters:

RunId: the id running by the primary node

Offset: the current data offset replicated from the node

Maybe you are a stranger to the above runid and offset, but it doesn't matter. Let's first take a look at the following three concepts:

1. Copy offset

The master and slave nodes participating in replication maintain their own replication offset separately: each time the master server propagates N bytes of data to the slave server, it adds N to its own offset value. Each time the slave server receives N bytes of data propagated by the master server, add its own offset value to N. By comparing the replication offset of the master-slave server, we can know whether the data of the master-slave server is consistent or not. if the offset of the master-slave server is always the same, then the master-slave data is the same. on the contrary, if the offsets of the two master-slave servers are not the same, then the master-slave server is not in a state of data consistency. For example, when there are multiple slave servers, a server is offline in the process of transmission. As shown in the following figure:

Offset inconsistency

Due to the disconnection of slave server A during data transmission due to network reasons, the offset is inconsistent with the master server, so when slave server An is restarted and the connection with the master server is successful, the psync command is sent to the master server again. Should the data replication perform full replication or partial replication? If partial replication is performed, how does the master server compensate for the data lost by slave server A during the disconnection? The answers to these questions are in the copy backlog buffer.

2. Copy the backlog buffer

The copy backlog buffer is a fixed-length queue saved on the master node. The default size is 1MB. When the master node has a connected slave node (slave), it is created. When the master node (master) responds to the write command, it will not only send the command to the slave node, but also write to the copy backlog buffer, as shown in the following figure:

Copy backlog buffer

Therefore, the copy backlog buffer of the primary server holds some of the most recently propagated write commands, and the copy backlog buffer records the corresponding replication offset for each byte in the queue. So when the slave server reconnects to the master server, the slave server sends its own replication offset offset to the master server through the psync command, and the master server decides what data synchronization operation to perform on the slave server based on this replication offset:

If the data after the replication offset from the slave server still exists in the replication backlog buffer, the master server will perform a partial copy operation on the slave server.

If the data after the replication offset from the slave server does not exist in the replication backlog buffer, the master server will perform a full copy operation on the slave server.

3. The server runs ID

After starting, each Redis node will dynamically assign a 40-bit hexadecimal string to run ID. The main function of running ID is to uniquely identify the Redis node. We can use the info server command to view

127.0.0.1 957.27.2.el7.x86_64 6379 > info server # Server redis_version:5.0.5 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:2ef1d58592147923 redis_mode:standalone os:Linux 3.10.0-957.27.2.el7.x86_64 x86 regions 64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:4.8.5 process_id:25214 run_id:7b987673dfb4dfc10dd8d65b9a198e239d20d2b1 tcp_port:6379 uptime_in_seconds:14382 uptime _ in_days:0 hz:10 configured_hz:10 lru_clock:14554933 executable:/usr/local/redis-5.0.5/src/./redis-server config_file:/usr/local/redis-5.0.5/redis.conf 127.0.0.1purl 6379 >

There is a run_id field that is the ID that the server is running

After understanding these concepts, let's take a look at the running flow of the psync command, which is shown in the following figure:

Psync running process

The logic of the psync command is relatively simple, and the whole process is divided into two steps:

1. Send a psync command to the master node from the slave node. The parameter runId is the ID run by the master node saved by the slave node, and the parameter offset is the replication offset saved by the slave node. If it is the first time to participate in replication, the default value is-1.

2. After receiving the psync command, the master node will return one of the following three responses to the slave server:

Reply + FULLRESYNC {runId} {offset}: indicates that the master server will perform a full copy with the slave server, where runid is the running id of the master server, the slave server will save the id and use it the next time the psync command is sent, while offset is the current replication offset of the master server, and the slave server will use this value as its initialization offset

Reply + CONTINUE: then it means that the master server and the slave server will perform partial replication operations, and the slave server only needs to wait for the master server to send the missing data.

Reply + ERR: then the version of the master server is lower than redis 2.8.It does not recognize the psync command. The slave server will send the sync command to the master server and perform a full copy with the master server.

7. The command is continuously copied

When the master node synchronizes the current data to the slave node, the replication establishment process is completed. However, the master-slave server will not disconnect, because then the master node will continuously send write commands to the slave node to ensure the consistency of the master-slave data.

After the above seven steps, the data synchronization between the master and slave servers is completed. Because of the length of this article, the details of full replication and partial replication will not be introduced. Full replication is to send the current data of the master node to the slave server, and then load it from the local disk, so that when the file is too large, it will require a lot of network overhead. Otherwise, due to the slow data transmission, the master-slave data delay is larger, and part of the replication is that the master server sends the write command to copy the backlog buffer directly to the slave server.

Heartbeat detection

Heartbeat detection occurs when master-slave nodes maintain a long connection and send heartbeat commands to each other after establishing replication, and then continue to send write commands. Master-slave heartbeat detection is shown in the following figure:

Master-slave heartbeat detection

Both master and slave nodes have heartbeat detection mechanism, and each node is simulated as each other's client to communicate. The rules for master-slave heartbeat detection are as follows:

By default, the master node sends ping commands to the slave node every 10 seconds to judge the viability and connection status of the slave node. The sending frequency can be controlled by modifying the repl-ping-replica-period parameter in the redis.conf configuration file.

The slave node sends the replconf ack {offset} command every 1 second in the master thread to report its current replication offset to the master node. This command not only detects the master-slave node network, but also sends the replication offset to ensure the consistency of the master-slave data.

The master node judges the slave node timeout according to the replconf command, which is reflected in the lag information in the info replication statistics. We execute the info replication command on the master server:

127.0.0.1 6379 > info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6480,state=online,offset=25774,lag=0 master_replid:c62b6621e3acac55d122556a94f92d8679d93ea0 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:25774 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:25774 127.0.0.1

You can see that the value of the slave0 field is followed by a lag,lag indicating the number of seconds behind the last communication delay with the slave node. The normal delay should be between 0 and 1. If the value configured by repl-timeout is exceeded (the default is 60 seconds), it is determined to go offline from the node and disconnect the replication client, and heartbeat detection will continue if it is restored from the node.

Master-slave topology architecture

The master-slave topology of Redis can support single-layer or multi-layer replication relationships. According to the topology complexity, it can be divided into the following three types: one master-slave, one master-slave, and tree master-slave architecture.

One master and one slave structure

The one-master-one-slave structure is the simplest replication topology. What we built in front of us is the one-master-one-slave architecture, as shown in the figure:

One master and one slave architecture

One master and one slave architecture

It is used for the slave node to provide failover support when the master node is down. When the application write command concurrency is high and needs persistence, AOF can only be enabled on the slave node, which not only ensures data security but also avoids the performance interference of persistence to the master node. But there is a pit, which you should pay attention to, that is, when the master node turns off the persistence function, avoid automatic restart if the master node is offline. Because the data set of the master node is empty after the persistence function is not enabled before, if the slave node continues to copy the master node, the slave node's data will also be emptied, which loses the meaning of persistence. It is safe to perform slaveof no one on the slave node to break the replication relationship with the master node, and then restart the master node to avoid this problem.

One master and multi-slave architecture is also called star topology. The one-master and multi-slave architecture is shown in the following figure:

One master and multiple slaves architecture

The one-master and multi-slave architecture can realize the separation of read and write to reduce the pressure on the master server. For the scenario where the read occupies a large proportion, the read command can be sent to the slave node to share the pressure on the master node. At the same time, in daily development, if you need to execute some time-consuming read commands, such as keys, sort, etc., you can execute on one of the slave nodes to prevent slow queries from blocking the master node and affecting the stability of online services. For scenarios with high write concurrency, multiple slave nodes will cause multiple write commands of the master node to send multiple times, resulting in excessive consumption of network bandwidth, but also aggravate the load of the master node and affect the service stability.

Tree master-slave architecture

The tree master-slave architecture is also known as the tree topology architecture, which is shown in the following figure:

Tree master-slave architecture

The tree master-slave architecture enables the slave node not only to copy the master data, but also to continue to copy to the lower level as the master node of other slave nodes. The deficiency of one master and multi-slave architecture is solved. By introducing the middle layer of replication, the load of the master node and the amount of data that needs to be transmitted to the slave node can be effectively reduced. For example, in the architecture diagram, after the data is written to node A, the data is synchronized to the B and C nodes, and the B node synchronizes the data to the D and E nodes. When the master node needs to mount multiple slave nodes, in order to avoid the performance interference to the master node, the tree master-slave structure can be used to reduce the pressure of the master node.

This is the end of the article on "what are the ways to establish the master-slave architecture of Redis?" Thank you for reading! I believe you all have a certain understanding of "what is the way to establish the master-slave structure of Redis". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.