1 Introduction
Recently in the project to use Redis as cache, to facilitate sharing of data between multiple business processes. Since Redis data are stored in memory, if not configured persistence, after redis restart the data on the whole is lost, so the need to open the persistence function redis will save data to disk, when redis restart from disk Data recovery. redis persistence provides two ways, one is persistent RDB (Reids principle is the in-memory database record timing to dump the RDB persistent disk), is another persistent AOF (the principle is Reids operation log additional way to write files). So both ways persistence What difference does it make, change how to choose? Most read online presentation are two ways how to configure, how to use, that there is no distinction here between the two, under what scenario.
2, the difference between the two
RDB persistence means that within a specified time interval memory snapshot of the data set is written to disk, the actual operation is fork a child process, the first set of data written to a temporary file, write successfully, and then replace the file before , binary compressed storage.
AOF persisted in the form of log records processed by the server every write, delete, query operation is not recorded, the recorded text, you can open the file to see the detailed operating record.
3, both the advantages and disadvantages
What are the advantages RDB exist?
1) Once this manner, then your entire Redis database will contain only one file, which for file backup is perfect. For example, you might intend to archive every hour last 24 hours of data, but also archived once in the last 30 days of data every day. With this backup strategy, once the system has failed catastrophically, we can very easily be restored.
2) For disaster recovery purposes, RDB is a very good choice. Because we can very easily be a separate file compression and then transferred to other storage media.
3) The performance is maximized. For service of process Redis, at the beginning of persistence, it is the only need to do is fork out the child, and then after the completion of these persistent work by the child, so that you can greatly avoid the process of an IO operation of the service.
4) Compared to the AOF mechanism, if the data set is large, start RDB efficiency will be higher.
RDB and what weaknesses exist?
1) If you want to guarantee high availability of data, that is, the maximum to avoid loss of data, then the RDB would not be a good choice. Because once the system downtime phenomenon before the timing of persistence, had not had time to write data on the disk will be lost.
2) Since the RDB through the fork a child process to assist with data persistence work, so if and when the data set is large, it may cause the entire server to stop serving hundreds of milliseconds, or even one second.
AOF advantage, what does?
1). This mechanism can result in higher data security, namely data persistence. Redis provides 3 in synchronization strategy, that sync every second, every modification and synchronization are not synchronized. In fact, asynchronous synchronization is complete per second, its efficiency is very high, the difference is that once the system downtime phenomenon, then within seconds the modified data will be lost. And every modify the synchronization, we can be regarded as synchronization persistence that occurs every time data changes will be immediately recorded to disk. It is foreseeable that in this way is the lowest in efficiency. As for non-synchronous, needless to say, I think we can correct understanding of it.
2). Since the mechanism writes to the log file append mode is used, even if the phenomenon of downtime during the writing process, without disturbing the contents of the log file already exists. However, if we write this operation is only half the data appeared system crash, do not worry, before the next startup Redis, we can to help us solve the problem of data consistency by redis-check-aof tool.
3) If the log is too large, Redis can automatically enable rewrite mechanism. That Redis to append mode will keep the modified data is written to the old disk file, while Redis also creates a new file to record what has changed on command is executed during this period. Therefore, when switching is performed rewrite data security can be guaranteed better.
4). AOF format comprising a clear, comprehensible log file for recording all the changes. In fact, we can complete the reconstruction data through the file.
AOF disadvantages, what does?
1) For the same number of data sets, AOF is generally larger than RDB document file. RDB speed when recovering large data sets faster than the speed of recovery of AOF.
2). Depending on the synchronization policy, AOF on the operating efficiency tends to be slower than in RDB. In short, the efficiency of synchronous per second strategy is relatively high, disable synchronization efficiency and RDB policy as efficient.
When both selection criteria, is to see the system is willing to sacrifice some performance in exchange for higher cache coherency (aof), was willing to write frequent operation, do not enable the backup in exchange for higher performance, time to be run manually save the , do a backup (rdb). This is even more rdb some eventually consistent mean. However, the production environment is actually more a combination of both are used.
4, common configuration
RDB persistence configuration
Redis snapshots will dump data set to dump.rdb file. In addition, we can also be modified by the frequency Redis server configuration file dump snapshot, after opening 6379.conf file, we search save, you can see the following configuration information:
save 900 1 # After 900 seconds (15 minutes), if at least one key is changed, the dump memory snapshot.
save 300 10 # after 300 seconds (5 minutes), at least if there is a change key 10, the dump memory snapshot.
save 60 10000 # after 60 seconds (1 minute), if at least 10,000 key changes, the dump memory snapshot.
AOF persistence configuration
In the present embodiment three kinds of synchronous Redis profile, they are:
appendfsync always # every time a data modification occurs when a file is written to AOF.
appendfsync everysec # sync once per second, the strategy is the default strategy of AOF.
appendfsync no # Never synchronization. Efficient but the data are not persisted.
5. References