Redis master-slave replication in one article

Challenges posed by local caching

What are the different points to focus on at the implementation level for distributed caching as compared to local caching. It is summarized below:

dimension (math.)	local cache	Centralized Caching
buffer size	Limited storage of data due to the size of memory on a single machine	It needs to be provided to all nodes in the distributed system for common use, for large systems, the capacity of the centralized cache requirements are very large, far more than the size of the capacity of a single machine memory.
dependability	Limited impact, only used by this process and does not affect the reliability of other processes.	As the whole system carries the pressure barrier, all the nodes in the system rely on the common service, once the centralized cache problem, it will affect all the business nodes with which it is connected, the impact on the system islethalityThe.
pressure-bearing	Carrying the pressure of a single node with a limited number of requests	Carry the entire distributed cluster of all the nodes of the traffic, the more the number of business distributed nodes deployed in the system, the larger the business volume, will lead to centralized caching to carry the pressure of the larger, or even uncapped.

A comparison of the above dimensions reveals that the same caching butCentralized CachingThe missions undertaken are quite different, and the business to centralized caching of thestorage capacity、dependability、pressure-bearingand other claims are also vastly different and not to be equated. TakeRedisAs an example:

How to break the problem of redis cache capacity being limited by the size of the machine's standalone memory?
How to make redis able to carry the pressure of requests coming from multiple parties?
How do you ensure that redis does not become a single point of failure source?

In fact, the answer is very simple, add machines! Through the stacked use of multiple machines, to achieve better results than a single machine -- now the business system of the cluster deployment, are also used in this way of thinking. redis distributed road is also the same, but compared to the regular business system distributed cluster construction is more complex:

It will be simple for many businesses to implement a clustered deployment because each business process node isstatelessIt's just a matter of deploying it and then providing responses to requests externally via load balancing.
Redis acts as a centralized caching database that isstatefulIn addition to deploying the processes on multiple nodes, you also need to store the data on each node, and at the same time ensure that the entire Redis cluster is a unified whole.

So for a centralized cache to be built with distributed capabilities, some additional mechanism must be provided to secure the data on each node with theconsistencyIt is also necessary to make a logical whole out of all the data that is scattered across the nodes.

Introduction to Master-Slave Replication

What is Master-Slave Replication

Master-slave replication refers to replicating data from one Redis server to other Redis servers. The former is called the master node (master), and the latter is called the slave node (slave); the replication of data is unidirectional and can only be from the master node to the slave node, while for redis, thelit. one master, two slaves (idiom); fig. a principal and a slaveIt's a more common pairing.

The master-slave model follows a read-write separation strategy to improve overall request processing:

The master node (Master) also provides externalRead and Writemanipulate
The slave node (Slave) is passed through thereplicateSynchronized approach, copying data from the master node, keeping its own data consistent with the master node
Slave nodes can only externally provideread operation

Of course, for read-more-write-fewer type of operations, in order to improve the overall read request processing capability, you can use themaster of many trades (computing)The way. All slave nodes are synchronized from the master node, which will lead to the master node synchronization processing pressure is too large and become a bottleneck. In order to solve this problem, redis also supports the ability to distribute from slave nodes, that is, from the server can also have their own slave servers, multiple slave servers can form a master-slave chain. This can spread the pressure of the master server.

The Role of Master-Slave Replication

Data Backup: Master-slave replication enables hot backup of data and is a form of data redundancy in addition to persistence.
Failure recovery: When the master node has problems, it can be served by the slave node to realize fast failure recovery.
Read-write separation: Write services are provided by the master node and read services are provided by the slave nodes to improve the concurrency of Redis servers.

Master-Slave Replication Process

full-scale replication

Full replication is done on the first synchronization (but not only on the first synchronization, see later for other cases)

Flow at first synchronization:

Phase I: link building, consultation and synchronization

The slave server sends the master server the PSYNC ? -1 command to proactively request a complete resynchronization

The psync command contains two parameters, the runID of the master server and the replication progress offset.

runID, each Redis server automatically produces a random ID to uniquely identify itself at startup. When the slave and master servers are synchronized for the first time, because the runID of the master server is not known, it is set to "?" .
offset, the progress of replication, (also called replication offset), mainly for incremental replication, here because it is a full replication, so use -1.

When the master server receives the psync command, it sends a FULLRESYNC response command to the slave server with two parameters: the master's runID and the master's current replication progress, offset. the slave server logs these two values when it receives the response.

FULLRESYNC The intent of the response command is to use full replication, which means that the master server will synchronize all data to the slave server.

Phase 2: Master server synchronizes data to slave servers

Next, the master server executes the bgsave command to generate the RDB file and then sends the file to the slave server (data persistence).

After receiving the RDB file from the server, theThe current data is cleared and then the RDB file is loaded.. This is because the slave server may have saved other data before it started synchronizing with the master server via the replicaof command. To avoid the effect of the previous data, the slave server needs to empty the current database first.

One thing to note here is that the process of generating the RDB on the main server does not block the main thread, because the bgsave command spawns a child process to do the work of generating the RDB file, which works asynchronously, so that Redis can still process the command normally.

Just as Redis does not stop providing services during RDB file generation, the master server can still write data while the slave server is receiving and loading the RDB file, so how do you pass this data to the slave server?

Phase 3: Master server sends new write operation command to slave server

In order to ensure data consistency between the master and slave servers, the master server prepares a replication buffer buffer for each slave server that connects in, and data written during this time is stored in this replication buffer. After the slave server finishes loading the RDB, it replies with an acknowledgement message to the master server. The master server then pushes the data in the replication buffer.

long connectivity propagation

After the master and slave servers complete the first synchronization, a TCP connection is maintained between the two parties, and this TCP connection is a long connection

After that it will be based on thislong connectionPerform command propagation. In this way the data consistency of the master and slave servers after the first synchronization is ensured.

incremental replication

In fact, generating the RDB file is more resource-consuming, and at the same time, the master server transmits the RDB file to the slave servers, an operation that consumes a lot of network resources of the master and the slave servers and has an impact on the response latency of the master server. For the slave server, during the loading of the RDB file, it will block other command requests, which will also lead to a reduction in response efficiency. Moreover, when the slave server disconnects and reconnects, the master and slave data are inconsistent, and full replication is not required in the case of a small amount of inconsistent data. Therefore, incremental replication is provided

Replication offset

The master and slave servers each maintain a replication offset. If the replication offsets of the master and slave servers are the same, the database state of the two servers is consistent; otherwise, the database state of the two servers is inconsistent, and the slave servers need to use incremental replication to synchronize the missing part of the data.

Replication Backlog

Write commands from the master server, in addition to being passed to the slave servers, are also written to the replication backlog (globally unique), which is a fixed-length first-in-first-out (FIFO) queue with a default size of 1MB. it is a ring structure in memory.

The master server writes commands in a clockwise direction, and the location of the latest write from the master server is the offset of the master server mentioned above, here called master offset.
Assuming that the slave server disconnects after set key2 2, which is the location of slave offset in the above figure, when it reconnects, it will take its own offset with it when it sends the psync command to the master server again (note the difference from full replication, where offset is set to -1, which at this point is the true offset value from the server).
Next, the master server realizes that the slave server's offset does not match its own and needs to be incrementally replicated. At this point, the master server calculates the command between the master offset and the slave offset and sends it to the replication buffer prepared for the slave server, which in turn sends it to the slave server.
The slave server writes and then returns to the same state as the master server.

Disconnecting and reconnecting is not necessarily always incremental replication

After the network is disconnected, when the slave server reconnects to the master server, the slave server sends its replication offset slave_repl_offset to the master server via the psync command, and the master server decides which synchronization operation to perform on the slave server based on the difference between its master_repl_offset and slave_repl_offset. to decide which synchronization operation to perform on the slave server:

The entire replication backlog is a ring structure, which means that the newest write command overwrites the oldest write command. In other words, if the slave server is disconnected for too long and the ring buffer is overwritten by the master server's write commands, then the slave server can only connect to the master server via thefull-scale replicationto get the data out. So the replication backlog should be configured to be as large as possible, which can reduce the probability of full replication after a master-slave disconnection.
- If it is determined that the data to be read by the slave server is still in the repl_backlog_buffer, then the master server will use incremental synchronization;
- Instead, if it is determined that the data to be read by the slave server no longer exists in the repl_backlog_buffer buffer, then the master server will use full synchronization.
As mentioned above, each instance has its own RunID, which is automatically generated at server startup and consists of 40 random hexadecimal characters. When the slave server disconnects and reconnects, it sends the RunID of the master server along with it (note the difference from the first connection, where the RunID is "?"). When the master server disconnects and reconnects, it sends the RunID of the previous master server along with the RunID (note the difference from the first connection, where the RunID is "?"), and the master server determines if the RunID is its own, and if it is not (e.g., if there is a fracture, and there are two master servers), it will return a FULLRESYNC response command as it does when it is fully replicated, informing the slave servers that they need to replicate at full capacity.

summarize

The first time the master and slave servers are synchronized is with full replication.

After the first synchronization is completed, both the master and slave servers maintain a long connection through which the master server, upon receiving a write command, propagates the write command to the slave server to ensure data consistency between the master and slave servers.

If you encounter a network disconnection, you need to perform incremental replication (not necessarily incremental replication, of course; it also depends on the size of the replication backlog, and the corresponding RunID of the master server).

Interview questions column

Java interview questions columnIt's online, so feel free to visit.

If you don't know how to write a resume, resume projects don't know how to package them;
If there's something on your resume that you're not sure if you should put on it or not;
If there are some comprehensive questions you don't know how to answer;

Then feel free to private message me and I will help you in any way I can.