In memory database Redis persistence summary

Because Redis is memory databases, so in order to prevent because of a system crash causes such as data loss problem, Redis provides two different persistence method to store the data in the hard disk, a kind of method is a snapshot (RDB), it can be found in all the data at a certain moment are written to the hard disk, the other one kind of method is only an additional file (AOF), it will be, when performing a write command will be executed to write commands are written to the hard disk.

Snapshot persistence

Redis can create a snapshot to get a copy of the data in memory at a certain point in time. After the snapshot is created, the user can back up the snapshot, copy it to another server to create a copy of the server with the same data, or leave the snapshot in place for use when the server is restarted.

There are two commands you can use to generate RDB files, one is SAVE, and one is BGSAVE.

When only snapshot persistence is used to save data, if the system does crash, the user will lose all data that has changed since the last snapshot was generated. Therefore, snapshot persistence applies only to applications where even a partial loss of data is not a problem.

SAVE

Features: the SAVE command blocks the Redis server process until the RDB file is created. The server cannot process any command requests while the SAVE command is blocked.

Disadvantage: the server cannot accept other requests during persistence.

BGSAVE

Features: the BGSAVE command will produce a child process, which will then create the RDB file, while the server process continues to process the command request.

Cons: the time spent creating child processes increases with the amount of memory consumed by Redis.

AOF persistence

AOF persistence records changes in the data by writing the executed write command to the end of the AOF file, so Redis can restore the data set recorded by AOF by re-executing all the write commands contained in the AOF file once from beginning to end.

When setting the synchronization frequency, there are three options:

选项	同步频率
always	每个Redis写命令都要同步写入硬盘，但是这样做会占用Redis所拥有的内存，严重降低Redis的速度
everysec	每秒执行1次同步，显式地将多个写命令同步到硬盘
no	让操作系统来决定应该何时进行同步

It is best to use everysec, can avoid that impact the performance of write every time, and can avoid operating system crash may not lost, as a result of the quantitative data, even if the system crashes, most users will only have lost less than a second data, when hard busy executive write Redis elegant will slow down their speed in order to adapt to the hard disk write speed.

Cons: because Redis constantly records the write commands being executed in AOF files, the size of the AOF files grows as Redis continues to execute, and in extreme conditions, AOF may even run out of free disk space.

To address this shortcoming, Redis provides the BGREWRITEAOF command, which overwrites the AOF file by removing redundant commands from the AOF file, making the AOF file as small as possible. The principle is similar to that of the BGSAVE command. Redis will create a subprocess and then the subprocess will be responsible for rewriting the AOF file. Since the AOF file rewrite also requires the subprocess, there are also performance and memory footprint problems caused by creating the subprocess.