introduction
(This article is adapted from real life cases, if similar, no coincidence!)
Dragon Boat Festival, while tobacco brother is happy learning ....
Suddenly, a burst of micro-letter shake. Call of smoke turned out to be old Liu brother! Good brother thought people smoke is an offer I went out to play! However, a micro-channel open look, appear the following figure chats
So the theme of this paper, so started. Since I need to quickly let old Liu understand this answer routine questions, so I answered when she teaches is a common practice.
ps: Attached , "those years spent redis cluster architecture (including interview parse)" connection address.
Of course, I must, I must first ask what redis old Liu answered cluster architecture! Liu's answer is to use the redis cluster cluster architecture.
So, I heard my heart there at the end, start balabala ....
text
Persistence routine
OK, generally lasting strategy we use in production
- (1) master shut persistence
- (2) slave open RDB can, when necessary, AOF and RDB are open
This strategy can adapt to most of the scene, most of the cluster architecture.
Why are most of the scene?
Because this strategy there is some data loss possibilities. redis from the master copy is asynchronous, the result is returned to the client immediately after the End Run master client requests, and then synchronizing the commands asynchronously to the slave. So master may not have had time to transmit a command to the slave, it is down, this time slave becomes the master, data is lost.
Fortunately, the vast majority of business scenarios, can tolerate some data loss. Assume that the situation really hit cache avalanche, the code also has a fuse to protect the resource, and will not all requests are forwarded to the database, leading to the collapse of our services!
ps: Here's cache avalanche refer to the same time a bunch of request, the requested key does not exist in redis, leading all forwards the request to the database.
Why are most of the cluster architecture?
Redis separate read and write because the situation exists in the cluster, not suitable for this program up.
Fortunately, the use of separate read and write redis architecture, it is necessary to consider the master-slave synchronization delay problem, inviting complexity of the system. The industry currently uses separate read and write project redis architecture, really too little.
Why do so
(1) master shut persistence
The reason is simple, because no matter what kind of persistence will affect the way the performance of redis, which can cause persistent CPU Caton, affect the processing of client requests. To ensure the best performance read and write, the master of persistent closed!
Persistence RDB
RDB persistent data is a snapshot of the current process is saved to the hard disk (and therefore also known as snapshots persistence), save the file suffix is rdb; when Redis is restarted, you can read the snapshot file recovery data.
Then RDB persistent process, equivalent to execute bgsave command. This command execution process as shown in FIG.
As shown, the main thread to call the system function the fork (), to build a subprocess for persistence! Unfortunately, in the process of building the child process, the parent process will be blocked and can not respond to client requests!
Moreover, in the test found, fork function slower on a virtual machine, the faster the real machine. Taking into account are now deployed in the docker container, rarely deployed on a real machine, for performance, master is not recommended to open the RDB persistence!
AOF persistence
RDB persistence is the process of writing data to files, and AOF persistence (ie Append Only File persistent), execute each write sucked Redis commands recorded in a separate log file.
Over time, you will find this AOF files increases, so redis rewrite a set of mechanisms to reduce the volume of AOF documents. However, in the process also need to rewrite the parent process to fork a child process carried out rewrite operation. As for the impact fork function, the above mentioned before.
Another strategy is to brush disk fsync, this value is recommended with everysec, which is the default Redis will fsync call once every second, the data buffer is written to disk.
However, if the disk is unstable, fsync calls for more than 1 second. At this time the main thread of the AOF will fsync successful than the last time; if from the last less than 2s, the main thread directly back; if more than 2s, the main thread to block until the fsync synchronization is complete.
Therefore AOF also affect the performance of the redis.
ps: linux function, wrtie function when data is written to the file, the data is written to the buffer of the operating system, but also did not brush into the disk. The fsync function, you can force the operating system to flush data to disk brush.
In summary, in order to ensure we maximize read and write performance, the master of persistent closed.
(2) slave open RDB can, when necessary, AOF and RDB are open
First of all, let me explain, I do not recommend a single open AOF reason is that the recovery is too slow AOF-based data.
You want to, we have done a master-slave replication, data backup has been achieved, why slave need to open persist?
Because one day probably because of a certain project, the wire room Waduan, it will lead to the master and slave machines simultaneously shutdown.
So this time, we need to quickly restore the cluster, while the small RDB files, quick recovery, disaster recovery and therefore common RDB file.
Secondly, the official website does not recommend a single open AOF, at the following address:
https://redis.io/topics/persistence
shots are as follows
So, if it has certain requirements for data security, the RDB AOF and persistence are open.
In addition, good disaster recovery. Use the linux scp command rdb regularly copy files to the cloud server.
ps: scp is a secure copy of shorthand for remote command to copy files in Linux, and it is similar to the cp command there, but cp only copy in the machine can not be cross-server, and scp transmission is encrypted.
to sum up
This paper is a general persistence strategy, the main purpose is asked in the interview, give a reasonable answer, but not to look ignorant force.