foreword
Redis persistence, an old question, but interviewers just like to ask. This is also a knowledge point that we must know when we learn Redis. Redis is an in-memory database. When it works, the data is stored in memory, which is one of the reasons why it is fast. But storing in memory is definitely a risk of data loss, so Redis is designed to be persistent. There are two types of Redis persistence: RDB and AOF.
RDB persistence
RDB (Redis DataBase) is the default storage method of redis. RDB persistence is actually to make a snapshot of the data in memory directly to the disk. The ways to trigger RDB persistence are:
Comply with the configured snapshot saving rules (the configuration at the beginning of save in the configuration file);
Execute the save or bgsave command;
Execute the flushall command;
Perform a master-slave replication operation (for the first time).
In the configuration file redis.conf, the configuration beginning with save is related to RDB persistence. The specific explanation is as follows:
save "" means close rdb persistence;
save 3600 1 means that at least 1 key changes every 1 hour, triggering a persistence can write multiple conditions;
save 3600 1 300 100 60 10000 Three strategies are defined here, and they are in an OR relationship with each other.
AOF persistence
AOF ( Append Only File ) persistence is to record all the write instructions executed by Reids and save them in the log, similar to MySQL's bin-log. The persistence method is disabled in the default configuration file, and the configuration needs to be modified to:
appendonly yesSince AOF writes the write operation log of the Redis service to the log file, when the write operation is very frequent, it will also put a lot of pressure on the disk. Therefore, AOF's disk data landing (fsync function) also has three strategies:
Always: Indicates that the fsync function will be called as long as there is a write;
Everysec: Indicates that the fsync function is called once per second;
No: means that the fscyn function will not be called, and it will follow the system completely;
It is recommended to choose everysec, which is more conservative.
AOF rewrite
If the AOF file does not intervene, it will continue to grow until your disk is full. Fortunately, Redis provides a rewriting mechanism for AOF. We can directly execute the following command to rewrite AOF:
bgrewriteaof;After executing this command, the AOF file will be rearranged according to the persistent RDB file and the existing AOF file, and it will clear the useless write log, and finally achieve the purpose of slimming.
Of course, AOF also has a rewritten configuration with two parameters:
parameter |
illustrate |
auto-aof-rewrite-min-size |
The AOF file must not be lower than this size to trigger rewriting, and each subsequent rewriting will not be based on this variable (according to the size after the last rewriting is completed). This variable is valid only for initializing and starting redis |
auto-aof-rewrite-percentage |
If the value is defined as 80, it means that when the size of the AOF file grows more than 80% of the last size (the size of the AOF file after the last rewrite will be recorded) the rewrite operation will be triggered |
How to choose RDB and AOF
In the actual production environment, there are various persistence strategies according to different situations such as data volume, application security requirements for data, and budget constraints.
For example, do not use any persistence at all, use one of RDB persistence or AOF persistence, or enable snapshot persistence and AOF persistence at the same time. In addition, the choice of persistence must be considered together with Redis's master-slave strategy, because master-slave replication and persistence also have the function of data backup, and the master master and slave slave can independently choose the persistence scheme.
It doesn't matter if the data in Redis is completely discarded (for example, Redis is completely used as a cache for DB layer data), then no persistence is required whether it is a stand-alone machine or a master-slave architecture.
In a stand-alone environment (for individual developers, this situation may be more common), if you can accept data loss of more than ten minutes or more, choosing RDB persistence is more beneficial to the performance of Redis, if you can only accept second-level data Lost, AOF should be selected.
But in most cases, we will configure the master-slave environment. The existence of Slave can not only realize hot backup of data, but also perform read-write separation to share Redis read requests, and continue to provide services after the Master goes down. In this case, one possible approach is to:
Master: Turn off persistence completely, so that the performance of the Master can reach the best;
Slave: Turn off RDB persistence, turn on AOF (if the data security requirements are not high, you can turn on RDB persistence and turn off AOF), and regularly back up the persistent files (such as backing up to other folders, and mark the backup time ). Then turn off the automatic rewriting of AOF, then add a scheduled task, and call bgrewriteaof when Redis is idle every day (such as 12 o'clock in the morning).