Redis persistence mechanism-RDB and AOF
In Redis, data is usually stored in memory, so Redis has extremely high read and write performance. However, as an in-memory database, its high performance also brings a potential problem - data loss.
To cope with this problem, Redis provides two persistence mechanisms: RDB (Redis DataBase) snapshot and AOF (Append Only File) logs, allowing us to recover data when the system restarts or fails.
These two persistence methods have their own advantages and disadvantages, and their selection and optimization in practical applications are crucial to the stability and performance of Redis.
1. RDB persistence mechanism
1. Introduction to RDB
RDB (Redis DataBase) is a snapshot-based persistence method.
When RDB persistence is enabled, Redis periodically takes snapshots of data in memory (snapshots) and saves them to disk.
RDB files are a compressed binary file, usually saved as, located in the data directory of Redis.
2. How RDB works
RDB creates a child process by calling the fork() system call and lets the child process write data in memory to disk.
The main process continues to provide services, while the child process completes the snapshot saving process in the background. The generated RDB file is a compressed file containing all key-value pairs of the database.
The frequency and conditions of RDB persistence can be set through configuration files. Common configuration items include:
- save: Specifies how many write operations occur within a certain period of time, triggering RDB persistence.
- For example:
save 900 1 # If there is a write operation within 900 seconds, it will be persistedsave 300 10 # If there are 10 write operations within 300 seconds, persistsave 60 10000 # 60Within seconds,If there is10000Write operation,Just do it last
3. Pros and cons of RDB
advantage:
- High performance: Since RDB uses fork() method, the main process can continue to process requests while saving snapshots, without significant impact on performance.
- Fast data recovery: The RDB file loads faster, so when Redis restarts, the recovery speed is faster than AOF.
- Small storage space: RDB files are compressed, which can effectively save storage space.
shortcoming:
- Risk of data loss: RDB is a periodic persistence method, and the risk of data loss is high. If Redis suddenly goes down, the latest write operation may be lost.
- Persistence process blocking: Although Redis can save snapshots through fork(), there is still a certain performance overhead, especially when the amount of memory data is large, the RDB saving time and overhead will also increase.
4. Applicable scenarios
- Moderate data volume: RDB is suitable for scenarios where data persistence is not high, such as applications that do not update frequently, or have little data loss.
- High data recovery speed requirements: Since RDB recovers relatively fast, it is suitable for systems with high requirements for recovery speed.
2. AOF persistence mechanism
1. Introduction to AOF
AOF (Append Only File) is another persistence method for Redis. It records all write operations of Redis (including SET, DEL, etc.) into an append log file (i.e. AOF file).
Unlike RDB, AOF does not save memory snapshots, but ensures data persistence by gradually recording each write operation.
2. How AOF works
Whenever Redis performs a write operation, the operation is appended to the AOF file as a command. Redis will provide three synchronization methods for AOF files:
- always: Each write operation is synchronized to disk (the safest, but the worst performance).
- everysec: Synchronize AOF files once a second (recommended configuration, balanced security and performance).
- no: The operating system controls data refresh (the performance is best, but the risk of data loss is the greatest).
3. Pros and cons of AOF
advantage:
- High data security: AOF records data changes by command-by-command, so higher data security can be achieved. Even if Redis goes down, AOF can guarantee minimal data loss.
- Log rewriting mechanism: AOF files will gradually grow over time. Redis compresses the files into the simplest set of commands through the AOF log rewrite mechanism (bgrewriteAOF command) to avoid the AOF files becoming too large.
shortcoming:
- Large performance overhead: Each write operation will be appended to the AOF file, so AOF will cause a large performance overhead in scenarios where write operations are frequent.
- AOF file is larger: AOF files are usually larger than RDB because they record all write commands instead of compressed data snapshots.
4. Applicable scenarios
- High data security requirements: AOF is suitable for applications with extremely low tolerance for data loss, such as banking systems, payment systems, online transactions, etc.
- Frequently updated data: If data in the application is updated frequently and requires each operation to be persisted, AOF can provide higher security.
3. Selection and optimization of RDB and AOF
1. Choose a suitable persistence mechanism
RDB and AOF have their own advantages and disadvantages, how to choose depends on the specific application scenario:
- High performance requirements and low tolerance for data loss: If you require Redis to maintain high performance under load and the tolerance for data loss is relatively low, it is recommended to choose RDB.
- High data security requirements: If data security is crucial and data loss cannot be tolerated, it is more appropriate to choose AOF. The persistence method of AOF is more fine-grained and can provide higher data security.
2. Mix RDB and AOF
In actual production environment,RDB and AOF persistence can be enabled at the same time, to ensure data security while taking into account performance. In this case, Redis will perform both RDB snapshot and AOF logging:
- RDBProvides fast restart recovery speed.
- AOFProvides higher data persistence and minimizes data loss.
The optimization point of this method is: using AOF to ensure data security, and using RDB to accelerate restart.
3. AOF's log rewrite optimization
The growing AOF files may affect performance, so Redis providesAOF log rewrite mechanism, regularly compress commands in AOF files into the simplest command sequence.
The frequency of AOF rewrite can be controlled through the following configuration items:
# Control the conditions for triggering AOF rewriteauto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
This configuration will trigger AOF rewrite when the size of the AOF file reaches 100% of the current AOF file size, thus effectively avoiding the problem of excessive AOF file.
Summarize
When choosing Redis persistence, you must weigh the risk of data loss and performance requirements:
- RDBSuitable for scenarios where data volume is small, high performance requirements, and moderate tolerance for data loss.
- AOFSuitable for scenarios with extremely high data security requirements and frequent data updates.
-
Enable RDB and AOF at the same timeIt can improve recovery speed while ensuring data security and provide better performance.
In an actual production environment, rationally configuring the persistence strategies of RDB and AOF and performing corresponding optimizations (such as the AOF rewrite mechanism and a reasonable RDB saving strategy) can ensure system performance while minimizing data loss and ensuring high system availability.
The above is personal experience. I hope you can give you a reference and I hope you can support me more.