Iron dogs who don’t want to play the guitar well are not good program apes
Although the redis performance of a single machine is very good and has a complete persistence mechanism, what if your business volume is really large and exceeds the upper limit that a single machine can carry? What if redis hangs up without doing anything? With this question, we begin our topic today-Redis high availability, due to space reasons, this chapter only talks about master-slave replication.
Why should we start with master-slave replication first, becauseMaster slave replicationIt can be said to be the cornerstone of the whole redis high availability implementation. You can have such a concept first. As for why it is the cornerstone, it will be mentioned later when we talk about sentinel and redis clusters.
First of all, we need to know why we developers need itMaster-slave architecture？ Can’t a redis instance?
In fact, in addition to the load mentioned at the beginning exceeding the upper limit that redis can handle, there is another case that redis can not guarantee its high availability. That is, even if redis can carry all traffic, what if the machine where the redis process is located hangs? The request will directly turn the muzzle, and a large amount of traffic will instantly hang up your DB, and then you can carry a P0 and pack it home.
Moreover, suppose your demand for redis really exceeds the capacity of a single machine, what do you do? Do you have multiple independent redis instances? If the data cached by the user exists in instance 1 this time, and if the user accesses instance 2 again next time, do you want to go through the DB again? Unless you can maintain the correspondence between users and redis instances (but the logic is usually complex), deploying multiple redis instances will lose its significance and there is no way to scale horizontally.
Can the master-slave architecture solve this problem?
We can intuitively understand it from a diagram.
In master-slave synchronization, we divide the roles of nodes into
slave, formingOne master and many slaves。 The slave provides read operations to the outside, while the master is responsible for write operations, forming a read-write separation architecture, which can carry more business requests.
In most business scenarios, for redisRead operationMore thanWrite operationTherefore, when the number of read requests is particularly large, we can increase the slave node to enable redis to carry more traffic.
You can’t do this, brother. If you write data to the master, I can’t get the previous data if I connect to the slave?
Didn’t I write this subtitle?Master slave replication, the slave will synchronize data from the master according to a certain policy. In redis, we can use
slaveofThe command allows one redis instance to replicate the status of another redis. The replicated redis instance is the master node, and the execution
slaveofThe command machine is the slave node.
The master-slave replication of redis is divided into two steps:synchronizationandCommand propagation。
Synchronous operationIt is used to copy the memory state of the master node to the slave node, andCommand propagationDuring synchronization, the client performs some more operationswriteThe operation changes the state of the server. At this time, the state of the master node is inconsistent with that of the synchronization operation. Therefore, command propagation is required to make the master and slave states consistent again.
The general process of synchronization is as follows:
- Slave node sends to master node
- Master received
syncThe command is then executed
bgsaveCommand, redis will fork out a sub process, generate RDB files in the background, and record the write commands in the synchronization process into the buffer
- After the file is generated, the master will send the RDB file to the slave, and the RDB file received from the server will be loaded into memory
- Then, the master sends all write commands recorded in the buffer to the slave, and the slave updates these commandsreplay, update the status of its database to be consistent with that of the master
In order to make you more clearly understand this process, let’s understand it again through the figure.
, what if the slave hangs up after synchronization? After the slave is restarted, it may be inconsistent with the master again?
Indeed, this involves a noun calledBreakpoint continuationYes. As discussed above, when a slave connects to the master for the first time, it will executeFull replicationFor the above situation, the processing methods of new and old redis versions are different.
Before redis 2.8, after the master and slave have completed synchronization, if the slave is disconnected and reconnected, it will send a message to the master
syncCommand, the master will send the full amount of data to the slave again.
However, we will find a problem, that is, most of the data are orderly, and it is not necessary to synchronize all the data again. After redis 2.8, in order to solve this problem, it is used
Simply put, the PSYNC command sends all the write commands received by the master during the slave disconnection to the slave. After the slave is replayed, the state is consistent with that of the master.
Hehe, that’s it? Do you know how PSYNC is implemented? Or just use it?
The implementation of PSYNC depends on the information maintained by both the master and the slave
Every time the master sends to the slaveCommand propagation, you can add your own offset to the number of bytes that have been propagated. The slave will update its offset every time it receives how many bytes of data.
Based on offset, you only need a simple comparison to know whether the current master-slave state is consistent. Then, based on offset, you can propagate the instruction corresponding to the corresponding offset to slave playback. Therefore, even if the slave hangs up during synchronization, the effect of continuous transmission at breakpoint can be achieved based on offset.
No, no, what about the master? After you restart the slave, the data of the master is also updated. According to you, the data of the two will never be consistent
Redis did think about this problem. In fact, in addition to offset, a master instance will be brought after the slave is disconnected and reconnected
runid, each service instance has its own unique runid. As long as the redis service is restarted, its
After receiving this runid, the master will judge whether it is consistent with its current runid. If it is consistent, it indicates that it is still connected with itself before the disconnection. If it is inconsistent, it indicates that the master also goes down during the disconnection of the slave. At this time, it is necessary to update the dataFull synchronizationTo slave.
Even if you can solve this problem, you maintain an offset. Where does the command corresponding to the offset come from? Did it fall from the sky? Where do I know what these orders are?
Indeed, we need to use this offset to get the data we really need – that is, instructions, and redis uses this offsetCopy backlog bufferTo achieve.
In name, it is actually a queue. Just like recursion, polling and transparent transmission, it is actually a simple horse. To get back to business, the default size of the replication backlog buffer is 1m, and redis is in progressCommand propagationIn addition to sending the write command to the slave, the command will also be written to the slaveCopy backlog bufferAnd associated with the current offset. In this way, the corresponding instruction can be obtained through offset.
However, due to the limited size of the buffer, if the disconnection time of the slave is too long, the earlier instructions in the copy backlog buffer have been overwritten by the new instructions. Here, it can be understood as a queue, and the elements that entered the queue earlier have been out of the queue.
Since there is no corresponding offset, the instruction data cannot be obtained, and redis will performFull synchronization。 Of course, if the offset still exists in the copy backlog buffer, it is processed according to the corresponding offsetPartial synchronization。
Based on the above full and incremental master-slave replication, master-slave switching can be performed in case of master failure to ensure the normal operation of the service. In addition, it can also solve the problem of data loss under abnormal conditions. The read-write separation strategy can also improve the concurrency of the whole redis service.
Don’t blow it. What are you talking aboutMaster slave replicationIs there no disadvantage?
In fact, there are. For example, the master-slave switch mentioned just now, if it is not ready-madeHAFramework, this process needs to be completed manually by programmers, and notify the service caller that redis’s IP has changed. This process can be said to be very complex, and may even involve code configuration changes. Moreover, the previous slave replications were all suspended masters, and it was more complicated to change the master database of the slave.
In addition, although read-write separation is realized, due toOne master and many slavesArchitecture of clusterRead requestCan be extended, butWrite requestThere is an upper limit on concurrency, that is, the upper limit that the master can carry. There is no way to expand this.
Well, that’s the end of this issue. I’ll see you in the next issue.
If you think this article is helpful to you, it’s troublesomeLike it，Close a note，Share，Leave a message
WeChat can also search official account.SH’s full stack notesPay attention to the official account and read other articles ahead of time.
- Redis foundation – analyze the basic data structure and its usage
- Redis Basics – learn how redis does data persistence
- Take a brief look at k8s and build your own cluster
- A complete introduction to web assembly — understanding the past and present lives of wasm
- On JVM and garbage collection