Redis is an advanced key-value database. Data can be persisted, and a wide variety of data types are supported. There are strings, linked lists, sets and ordered sets. Support in the server side to calculate the set of union, intersection and complement (difference), but also support a variety of sorting functions. So Redis can also be considered a data structure server.

To ensure efficiency, Redis stores data in memory. Redis periodically writes updated data to disks or writes modification operations to additional record files to ensure data persistence.

Redis is a persistent in-memory database that synchronizes data in memory to disk to ensure persistence.

Redis persistence strategy: 2

  • RDB: In snapshot mode, memory data is directly saved to a dump file, which is periodically saved to save policies.
  • AOF: Store all Redis server modification commands in a file, a collection of commands. Redis is the snapshot RDB persistence mode by default

When Redis restarts, it uses AOF files to restore datasets in preference, since AOF files typically hold more complete datasets than RDB files. You can even turn off persistence so that data is stored only while the server is running.

RDB persistence

By default Redis persists data to disk in the form of snapshot “RDB”, a binary file, dump.rdb

Here’s how it works: When Redis needs to persist, it forks a child process that writes data to a temporary RDB file on disk. When the child process finishes writing the temporary file, it replaces the original RDB, which has the advantage of copy-on-write.

Redis is a snapshot RDB persistence mode by default. Data in memory is written to a binary file in snapshot mode. The default file name is dump. RDB. Of course, we can also manually perform save or BGSave (asynchronous) snapshot.

Redis.conf configuration: The default configuration is as follows

save 900 1 
save 300 10
save 60 10000
Copy the code
  • If more than one key is changed within 900 seconds, a snapshot is initiated and saved.
  • If more than 10 keys are modified within 300 seconds, a snapshot is initiated and saved.
  • If 10,000 keys are changed within one minute, snapshots are initiated for saving.

Advantages of RDB:

This type of file is perfect for backup: for example, you can back up an RDB file every hour for the last 24 hours and also back up an RDB file every day of the month. This way, if you run into problems, you can always revert the dataset to a different version. RDB is well suited for Disaster recovery.

Disadvantages of RDB:

If you need to avoid losing data in the event of a server failure, the RDB is not for you. Although Redis allows you to set different save points to control how often RDB files are saved, it is not an easy operation because RDB files need to hold the state of the entire data set. So you’ll probably save your RDB file at least once every 5 minutes. In this case, you could lose several minutes of data in the event of a malfunctioning outage.

AOF persistence

Each write command is appended to appendone. AOF using the AOF persistence function

Redis. Conf configuration

appendfsync yes   
appendfsync always     The AOF file is written every time a data change occurs.
appendfsync everysec   This policy is the default policy of AOF.
Copy the code

Appendonly Yes: after AOF is enabled, every command that Redis executes to modify data is added to the AOF file. When Redis restarts, The AOF file will be read and “played back” to the last moment before Redis was shut down.

The advantages of AOF

Using AOF persistence makes Redis much more durable: You can set different fsync policies, such as no fsync, fsync every second, or fsync every time a write command is executed. The default AOF policy is fsync once per second. In this configuration, Redis still performs well and loses at most a second of data in the event of an outage (fsync is performed in background threads, so the main thread can continue to struggle to process command requests).

The disadvantage of AOF

AOF files are usually larger than RDB files for the same data set. Depending on the fsync strategy used, AOF may be slower than RDB. Fsync per second performance is still very high under normal conditions, and turning off fsync allows the AOF to be as fast as the RDB, even under high loads. However, RDB can provide more guaranteed maximum latency when handling large write loads.

The difference between the two

  • RDB persistence refers to writing snapshots of data sets in memory to disks at a specified interval. The actual operation is to fork a sub-process to write data sets to temporary files first. After the data is written successfully, the original files are replaced and stored in binary compression.

  • AOF persistence records every write and delete operation processed by the server in the form of logs. The query operation is not recorded in the form of text. You can open the file to see detailed operation records.

RDB or AOF, which one should I use?

If you care deeply about your data, but can still afford to lose it within a few minutes, you can use RDB persistence only. AOF appends every command executed by Redis to disk. Handling large writes will slow down Redis performance. Database backup and disaster recovery: Periodic RDB snapshots are very convenient for database backup, and RDB can recover data sets faster than AOF.

Redis supports RDB and AOF at the same time. After the system restarts, Redis preferentially uses AOF to recover data to minimize data loss.