Since the data of redis is placed in memory, if the data is not persisted, the data will be lost after redis restarts, so persistence is required.
1. RDB method
RDB persistence actually refers to asynchronously writing the snapshot of the data set in memory to the disk within a specified time interval. The actual operation process is to fork a sub-process, first write the data set to a temporary file, and then replace the previous one after the writing is successful. files, stored with binary compression.
Advantage:
1. After adopting this method, the entire redis database will contain only one file, which is perfect for file backup. For example, you might plan to archive the last 24 hours of data every hour, and also archive the last 30 days of data every day. Through such a backup strategy, once the system fails catastrophically, we can restore it very easily.
2. For disaster recovery, RDB is a very good choice, because we can easily back up a single file.
3. Maximize performance. For the redis service process, when starting persistence, the only thing he needs to do is to fork the child process, and then the child process will complete the persistence work, which can greatly avoid the execution of the service process. IO operation.
4. Compared with the AOF mechanism, if the data set is too large, the startup efficiency of RDB will be higher.
shortcoming:
1. If you want to avoid data loss to the greatest extent, then RDB is not a good choice, because once the system crashes before persistence, all data that has not been written to disk before will be lost.
2. RDB uses fork sub-processes to assist in data persistence. When the data set is too large, the entire server may be stopped for hundreds of milliseconds, or even a second.
2. AOF method
AOF persistence refers to writing the redis operation log to a file in an appending manner.
Advantage:
1. Higher data security and higher persistence. Redis provides 3 synchronization strategies, synchronizing every second, synchronizing every modification and not synchronizing. In fact, the synchronization is done asynchronously every second, and its efficiency is also very high. The difference is that once the system goes down, the data modified within this second will be lost. And every modification synchronization, we can think of it as synchronization persistence, that is, every data change that occurs will be recorded to disk immediately. Predictably, this approach is the least efficient. As for no synchronization, no need to say much, I think everyone can understand it correctly.
2. Since this mechanism uses the append mode for log files, even if there is a downtime during the writing process, the existing content in the log file will not be destroyed. However, if we only write half of the data in this operation and the system crashes, don't worry, we can use the redis-check-aof tool to help us solve the problem of data consistency before Redis starts next time.
3. If the log is too large, Redis can automatically enable the rewrite mechanism. That is, Redis continuously writes modified data to the old disk file in append mode, and Redis also creates a new file to record which modification commands are executed during this period. Therefore, data security can be better ensured when rewrite switching is performed.
4. AOF includes a well-formatted, easy-to-understand log file for recording all modification operations. In fact, we can also complete the reconstruction of the data through this file.
shortcoming:
1. For the same number of datasets, AOF files are usually larger than RDB files. RDB is faster than AOF when recovering large datasets.
2. Depending on the synchronization strategy, AOF tends to be slower than RDB in operating efficiency. In short, the efficiency of the synchronization strategy per second is relatively high, and the efficiency of the synchronization disable strategy is as efficient as that of RDB.
The criteria for choosing between the two is to see whether the system is willing to sacrifice some performance in exchange for higher cache coherency (aof), or is willing to not enable backup in exchange for higher performance when write operations are frequent, and when save is manually run , and then make a backup (rdb).
4, regular placement
RDB endurance placement
Redis will dump a snapshot of the dataset into the dump.rdb file. In addition, we can also modify the frequency of Redis server dump snapshots through the configuration file. After opening the 6379.conf file, we search for save and we can see the following configuration information:
save 900 1 # After 900 seconds (15 minutes), if at least 1 key changes, dump the memory snapshot.
save 300 10 #After 300 seconds (5 minutes), if at least 10 keys have changed, dump the memory snapshot.
save 60 10000 #After 60 seconds (1 minute), if at least 10000 keys have changed, dump the memory snapshot.
AOF persistence configuration
There are three synchronization methods in the Redis configuration file, they are:
appendfsync always #The AOF file will be written every time a data modification occurs.
appendfsync everysec #Sync every second, this policy is the default policy of AOF.
appendfsync no #Never sync. Efficient but data will not be persisted.