We all know that Redis is an in-memory database, and all data is stored in memory. Once the Redis process on the server exits, the data in the database is lost.

What does persistence do? Persistence simply means making a backup of data in memory.

There are two methods of Redis persistence, namely RDB persistence and AOF persistence. This article will cover these two persistence methods and how they work in two parts. RDB persistence

Redis data persistence saves data in memory to disk to avoid accidental data loss. RDB persistence generates an RDB file, which is a compressed binary file. This file can be used to restore the data in the Redis database. Persistence of the RDB can be performed manually or automatically on a regular basis based on server configuration items.

Let’s learn how to create an RDB file. There are two commands to create an RDB file, one is SAVE and the other is BGSAVE.

Executing the SAVE command blocks the Redis server process until the RDB file is created, and the server cannot process any command requests while the server process is blocked.

Executing the BGSAVE command gives birth to a child process, which then creates the RDB file, and the server parent process continues to process the command requests.

Both the SAVE command and the underlying BGSAVE command invoke the same function, rdbSave, except that the SAVE command invokes the function directly, while BGSAVE forks () the child process to invoke the function. The pseudocode is as follows:

The loading of RDB files is performed automatically at server startup, as long as the Redis server detects the existence of RDB files at startup. It is worth mentioning that the Redis server blocks the load of the RDB file until the load is complete.

BGSAVE commands are executed without blocking the server process, so Redis allows the user to have the server execute BGSAVE commands automatically every once in a while by setting the server’s Save option.

The BGSAVE command is executed if one of the above conditions is met:

The server executes the BGSAVE command when it has modified the database at least once in 900 seconds. The server executes the BGSAVE command when it has modified the database at least 10 times in 300 seconds. The server executes the BGSAVE command if it has made at least 10,000 changes to the database in 60 seconds

AOF persistence

In addition to RDB persistence, Redis also provides AOF persistence, which is implemented in very different ways. RDB persistence records database state by saving key-value pairs in the database, while AOF persistence records database state by saving write commands executed by Redis server.

How is AOF persistence implemented? AOF persistence consists of three steps: command append, file write, and file synchronization.

Command appending: When AOF persistence is enabled, the server appends a write command to the AOF buffer in a certain format after executing the write command. The AOF buffer is a property of an SDS structure maintained by the redisServer structure.

File writing: File writing refers to writing from Redis’ AOF buffer to the operating system’s memory buffer. This process is intended to improve file writing efficiency, but carries the risk that data in the memory buffer will be lost in the event of a server failure.

File synchronization: This process is to write data from the memory buffer to the AOF file on the hard disk. Redis implements RDB persistence by default. Let’s first look at the AOF configuration items:

Appendonly: This is an AOF switch, set to yes to enable AOF persistence. Appendfsync: We know that Redis has an event loop, and at each event loop Redis writes the contents of the AOF buffer to the operating system’s memory buffer. This parameter is used to configure the update frequency for synchronizing data from the memory buffer to the AOF file on the hard disk. The values are always, Everysec, and no. Always means that every time a write is performed, the contents of the memory buffer are immediately synchronized to the AOF file on disk. This configuration has poor performance but ensures that data is not lost. Everysec synchronizes data from the operating system’s memory buffer to an AOF file on disk once per second. This operation is performed by a single thread with high performance. No indicates that the operating system controls when to synchronize data from the memory buffer to the AOF file on the hard disk. This operation loses some data in the event of a server exception.

We know that AOF files store all the write commands that have been executed, so the server only needs to read and re-execute the write commands saved in AOF files to restore the database contents before the server is shut down.

At the same time, in order to solve the problem that AOF files are getting bigger and bigger in the process of running Redis, Redis also provides AOF rewriting function. The principle of AOF rewriting is not specifically introduced here, but we can discuss privately if you are interested.

Iii. The difference and connection between RDB and AOF, and the situation when they work at the same time

First of all, let’s summarize the differences and connections between the two ways:

RDB persistence: enabled by default; Full backup, save the entire database at one time; Small size, fast data recovery; Some data may be lost when the server is faulty. The SAVE operation blocks; BGSAVE does not.

AOF persistence: off by default; Incremental backup, which saves commands to modify the database one at a time; Large volume, slow data recovery. Backup frequency can be set by oneself; There is no blocking.

When RDB and AOF start at the same time:

If RDB does snapshotting, redis will not do AOF rewrite; If Redis were doing AOF rewrite, then RDB snapshotting would not be done.

If the RDB is running snapshotting and the BGREWRITEAOF command is executed, AOF rewrite will be executed only after the RDB snapshot is generated.

If there are RDB snapshot files and AOF log files at the same time, when Redis restarts, AOF will be used for data recovery first because the logs are more complete.

The above content hopes to help you, more free PHP factory PDF, PHP advanced architecture video materials, PHP wonderful good article can be wechat search concerns: PHP open source community

2021 Jinsanyin four big factory interview real questions collection, must see!

Four years of PHP technical articles collation collection – PHP framework

A collection of four years’ worth of PHP technical articles – Microservices Architecture

Distributed Architecture is a four-year collection of PHP technical articles

Four years of PHP technical essays – High Concurrency scenarios

Four years of elite PHP technical article collation collection – database