How can Redis be persisted? What are the pros and cons of different persistence mechanisms? How is persistence implemented at the bottom?
Interviewer psychoanalysis
If Redis just caches data in memory, if Redis goes down and restarts, all the data in memory is lost. You must use Redis’ persistence mechanism to write data to memory asynchronously and slowly to a disk file for persistence.
If Redis goes down and restarts, it will automatically load some of the data that was persisted from the disk. You may lose a little data, but at least you won’t lose all of the data.
If redis is suspended and then restarted, the data in the memory will be lost. Can the data be recovered on reboot?
Analysis of interview questions
Persistence is mainly for disaster recovery, data recovery, it can also be classified as a link of high availability, for example, if you have a whole Redis down, and then Redis is not available, you have to do is to make Redis available, as soon as possible.
Restart Redis and make it available to the outside world as soon as possible. If no data backup is done, then Redis starts up and is not available.
It is possible to say that a large number of requests come in, the cache is not hit, the data is not found in Redis, this time is dead, cache avalanche problem. All requests that are not hit in Redis will go to the source of the mysql database, and suddenly mysql receives high concurrency, and then dies.
If you do a good job of redis persistence, backup and recovery plan to achieve enterprise-level, so even if your Redis failure, you can also backup data, rapid recovery, once the restoration of external services immediately.
Redis persists in two ways
RDB: RDB persistence mechanism, which periodically persists data in REDis.
AOF: The AOF mechanism logs each write command toappend-onlyThe mode is written to a log file, which can be passed when Redis restartsThe playbackWrite instructions in the AOF log to rebuild the entire data set.
Through RDB or AOF, redis memory data can be persisted to disk, and then these data can be backed up to other places, such as Ali Cloud and other cloud services.
If Redis fails, the memory and disk data on the server are lost. You can copy back the previous data from the cloud service and put it in the specified directory. Then restart Redis, redis will automatically restore the data in the memory according to the data in the persistent data file and continue to provide services.
If both RDB and AOF persistence mechanisms are used, then when Redis restarts, AOF will be used to rebuild the data, because the data in AOF is more complete.
RDB pros and cons
RDB will generate multiple data files, and each data file represents the data of REDis at a certain time. This method of multiple data files is very suitable for cold backup. Such complete data files can be sent to some remote secure storage, such as Amazon S3 cloud service. In China, it can be on the ODPS distributed storage of Ali Cloud to regularly back up data in Redis with a predetermined backup strategy.
RDB has very little impact on the read and write services provided by Redis, so that Redis can maintain high performance, because the main redis process only needs to fork a sub-process and let the sub-process perform disk I/O operations for RDB persistence.
Compared to AOF persistence, restarting and restoring redis processes directly based on RDB data files is much faster.
RDB is not as good as AOF if you want to lose as little data as possible when Redis fails. In general, RDB data snapshot files are generated every 5 minutes or more, at which point you have to accept that if the Redis process goes down, the data in the last 5 minutes will be lost.
Each time the RDB forks a child process to perform the RDB snapshot data file generation, if the data file is very large, the service provided to the client may be suspended for milliseconds, or even seconds.
AOF the pros and cons
AOF can better protect data from loss. Generally, AOF is executed every second through a background threadfsyncOperation, loss of data for up to 1 second.
AOF log files asappend-onlyMode write, so there is no overhead of disk addressing, write performance is very high, and the file is not prone to breakage, even if the end of the file is broken, it is easy to repair.
Even if the AOF log file is too large, the background rewrite operation does not affect the client read and write. Because in therewriteThe instructions are compressed to create a minimal log that needs to be recovered. When a new log file is created, the old log file is written as usual. When the log files after the merge are ready, the old and new log files can be exchanged.
Commands for AOF log files are logged in a readable way, which is a very special featureSuitable for emergency recovery of catastrophic deletions. Like when someone accidentally uses itflushallThe command clears all data as long as it is in the backgroundrewriteIt hasn’t happened yet, so you can copy the AOF file immediately and put the last oneflushallThe command was deleted, and then theAOFPut the files back, and you can recover all the data automatically through the recovery mechanism.
AOF log files are usually larger than RDB data snapshot files for the same data.
When AOF is enabled, the supported write QPS are lower than those supported by RDB because AOF is typically configured to be per secondfsyncLog files once, of course, every secondfsyncThe performance is also very high. (If you write in real time, the QPS and Redis performance will be greatly reduced)
In the past, there was a bug in AOF, that is, the same data was not recovered when the logs recorded by AOF were recovered. Therefore, a more complex command log/merge/playback approach such as AOF is more vulnerable and buggy than the rDB-based approach of persisting a complete data snapshot file at a time. AOF, however, is designed to avoid bugs in the rewrite process, so instead of merging the rewrite log, rewrite it based on the data in memory at the time, which is much more robust.
How to choose BETWEEN RDB and AOF
Don’t just use RDB, because that will cause you to lose a lot of data.
Don’t just use AOF either, because there are two problems with that. First, if you do cold standby through AOF, recovery is faster without RDB. Second, RDB is more robust and can avoid the bugs of AOF, a complex backup and recovery mechanism.
Redis supports two types of persistence at the same time. We can use AOF and RDB to ensure that the data is not lost, which is the first choice for data recovery. RDB is used for varying degrees of cold backup and for quick data recovery when AOF files are lost or corrupted and unavailable.
Pay attention to my wechat official number, the first time to get the update of my blog remind, more surprise waiting for you ~
Scan the QR code below or search for wechat account shenshan_laoyuan
This article was automatically published by ArtiPub
