How to use Redis's RDB and AOF methods

Redis persistence solution

Redis is an in-memory database, and data is stored in memory. In order to avoid permanent loss of data caused by process exit, the data in Redis needs to be stored in some form on a regular basis. (Data or commands) are saved from memory to hard disk. When Redis restarts next time, use the persistent file to achieve data recovery. In addition, persistent files can be copied to a remote location for disaster backup purposes.

Redis provides multiple different levels of persistence methods: one is RDB and the other is AOF.

RDB persistence can generate a point-in-time snapshot of the data set within a specified time interval, and save the database snapshot to the disk in binary form.

AOF persistently records all change operation commands executed by the server. All commands in the AOF file are saved in the format of the Redis protocol, and new commands will be appended to the end of the file. Redis can also rewrite the AOF file in the background so that the size of the AOF file does not exceed the actual size required to save the data set state.

Redis can use AOF persistence and RDB persistence at the same time. In this case, when Redis restarts, it will give priority to using the AOF file to restore the data set, because the data set saved by the AOF file is usually more complete than the data set saved by the RDB file. You can even turn off persistence so that the data only exists while the server is running.

It is very important to understand the similarities and differences between RDB persistence and AOF persistence. The following sections will introduce these two persistence functions in detail and explain their similarities and differences. .

RDB snapshot

Let’s talk about Redis’s first persistence strategy, RDB snapshot. Redis supports a persistence mechanism that saves a snapshot of the current memory data into a data file. How does a continuously written database generate a snapshot? Redis cleverly uses the copy on write mechanism of the fork command to fork the current process into a child process. The child process cyclically persists the data into RDB files based on the memory snapshot.

By default, Redis saves the database snapshot in a binary file named dump.rdb in the root directory. You can specify the save directory through parameter dir configuration, and dbfilename specifies the file name. You can set Redis, such as "save N M", which means that when there are M changes in the data items within N seconds, when this condition is met, the data set will be automatically saved. For example, you can configure to generate a snapshot when there are 100 writes within 10 minutes, or you can configure to generate a snapshot when there are 1,000 writes within 1 minute. It supports multiple rules to take effect at the same time, and which rule will take effect when it matches. The definition of these rules is in the Redis configuration file. You can also set the rules while Redis is running through the Redis CONFIG SET command without restarting Redis.

For example, the following setting will cause Redis to automatically save a data set when it meets the condition of "at least 1000 keys have been changed within 60 seconds":

save 60 1000

You can also Manually let Redis save the data set by calling SAVE or BGSAVE. The SAVE command performs a synchronization operation and saves a snapshot of all data in the form of an RDB file. The SAVE command is rarely used directly in a production environment because it blocks all client requests. Do not use it in a production environment. You can use the BGSAVE command instead. The BGSAVE command is executed by forking a child process, so the client request will not be blocked. Only forking the child process will block the server. In addition, when automatically triggering RDB persistence, Redis will also choose BGSAVE instead of SAVE for persistence.

Redis automatic RDB persistence is implemented internally through the serverCron periodic operation function, dirty counter, and lastsave timestamp. ServerCron is executed every 100ms to check the server status, which includes checking whether "save N M" meets the conditions, and if so, executes BGSAVE; of course, it also includes AOF rewrite check. The dirty counter is a state maintained by the Redis server. It records how many times the server status has been modified (including additions, deletions and modifications) since the last execution of the BGSAVE/SAVE command. When the BGSAVE/SAVE execution is completed, dirty will be reset to 0. . The lastsave timestamp is also a state maintained by the Redis server. It records the time when BGSAVE/SAVE was last successfully executed. The current time minus lastsave must satisfy M.

In addition to manual and automatic, there are some other situations that will trigger BGSAVE:

In the master-slave replication scenario, if the slave node performs a full copy operation, the master node will execute the BGSAVE command. And send the rdb file to the slave node. When executing the shutdown command, RDB persistence is automatically performed. In addition, you need to understand that because the writing operation is performed in a new process, when a new RDB file is generated, the child process generated by Redis will first write the data to a temporary file, and then call the atomic rename system Rename the temporary file to an RDB file so that if a failure occurs at any time, the Redis RDB file is always available.

这种持久化方式被称为快照（snapshot）。但是，我们可以很明显的看到，RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，如果可以忍受间隔内数据丢失，我们也推荐这些业务使用RDB的方式进行持久化，因为开启RDB的代价并不高。但是对于另外一些对数据安全性要求极高的应用，无法容忍数据丢失的应用，RDB就无能为力了，所以Redis引入了另一个重要的持久化机制，AOF日志方式持久化。

为了尽可能使RDB文件体积减小，Redis默认采用LZF算法对RDB文件进行压缩。虽然压缩耗时，但是可以大大减小RDB文件的体积，因此压缩默认开启，参数为rdbcompression。需要注意的是，RDB文件的压缩并不是针对整个文件进行的，而是对数据库中的字符串进行的，且只有在字符串达到一定长度(20字节)时才会进行。

除了压缩，你也可以检验RDB文件，通过参数rdbchecksum设置，默认为yes。在写入文件和读取文件时都起作用，关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现。

另外，当bgsave出现错误时，Redis是否停止执行写命令。Redis提供了一个参数stop-writes-on-bgsave-error，设置为yes，则当硬盘出现问题时，可以及时发现，避免数据的大量丢失；设置为no，则Redis无视bgsave的错误继续执行写命令，当对Redis服务器的系统(尤其是硬盘)使用了监控时，该选项考虑设置为no。

说说FORK的开销？

父进程通过fork操作可以创建子进程，第一代Unix系统实现了一种傻瓜式的进程创建：当执行fork系统调用时，内核复制父进程的整个用户空间并把复制得到的那一份分配给子进程。这种行为时非常耗时的，因为它需要完成以下几项任务：为子进程的页表分配页面、为子进程的页分配页面、初始化子进程的页表、把父进程的页复制到子进程对应的页中。

现在Linux的fork()使用写时拷贝（copy-on-write）页实现。写时拷贝是一种可以推迟甚至免除拷贝数据的技术。内核此时并不复制整个进程地址空间，而是让父进程和子进程共享同一个拷贝。只有在需要写入的时候，数据才会被复制，从而使各个进程拥有各自的拷贝。也就是说，资源的复制只有在需要写入的时候才进行，在此之前，只是以只读方式共享。这种技术使地址空间上的页的拷贝被推迟到实际发生写入的时候。所以就算fork很大内存的进程，对内存的消耗和耗时都很小。

现在虽然fork时，子进程不会复制父进程的数据空间，但是会复制内存页表（页表相当于内存的索引、目录）；父进程的数据空间越大，内存页表越大，fork时复制耗时也会越多。这个问题也是导致Redis内存不宜过大的原因之一，当然还有导致故障恢复时间延长也是Redis内存不宜过大的原因。

AOF日志

通过上面的分析，我们知道RDB快照有大概率丢失最近写入、且仍未保存到快照中的那些数据。尽管对于某些程序来说，数据安全并不是最重要的考虑因素，但是对于那些追求数据安全的程序来说，快照功能就不太适用了。从1.1版本开始，Redis增加了一种实时性更好的持久化方式，即AOF持久化。AOF日志的全称是append only file，从名字上我们就能看出来，它是一个追加写入的日志文件。与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

AOF文件与MySQL数据库的binlog不同的是，AOF是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点，它记录的内容就是一个个的Redis标准命令。开启AOF持久化命令如下：

appendonly yes
appendfilename "appendonly.aof"

从现在开始，每当Redis执行一个改变数据集的命令时（比如SET），这个命令就会被追加到AOF文件的末尾。这样的话，当Redis重新启时，程序就可以通过重新执行AOF文件中的命令来达到重建数据集的目的。

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程：

命令追加（append）

Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。

文件写入（write）和文件同步（sync）

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下：

In order to improve file writing efficiency, in modern operating systems, when users call the write function to write data to a file, the operating system usually temporarily stores the data into a memory buffer. When the buffer is filled or After the specified time limit is exceeded, the data in the buffer is actually written to the hard disk. Although such an operation improves efficiency, it also brings security issues: if the computer shuts down, the data in the memory buffer will be lost; therefore, the system also provides synchronization functions such as fsync and fdatasync, which can force the operating system to immediately transfer the data in the buffer to The data is written to the hard disk to ensure data security.

The synchronization file strategy of the AOF cache area is controlled by the parameter appendfsync. The meaning of each value is as follows:

always: Immediately after the command is written to aof_buf, the system fsync operation is called to synchronize to the AOF file. After fsync is completed The thread returns. In this case, every write command must be synchronized to the AOF file, and hard disk IO becomes a performance bottleneck. Redis can only support about a few hundred TPS writes, seriously reducing the performance of Redis; even if a solid-state drive (SSD) is used, It can only handle tens of thousands of commands per second, and it will greatly reduce the life of the SSD.

no: After the command is written into aof_buf, the system write operation is called, and fsync synchronization of the AOF file is not performed; the synchronization is handled by the operating system, and the synchronization period is usually 30 seconds. In this case, the file synchronization time is uncontrollable, and there will be a lot of data accumulated in the buffer, and data security cannot be guaranteed. everysec: After the command is written into aof_buf, the system write operation is called. The thread returns after the write is completed; the fsync synchronization file operation is called once per second by a dedicated thread. everysec is a compromise between the two aforementioned strategies, a balance between performance and data security. Therefore, it is the default configuration of Redis and our recommended configuration.

File rewrite (rewrite)

Because AOF operates by continuously appending commands to the end of the file, as the number of write commands continues to increase, the size of the AOF file will also increase. getting bigger and bigger. For example, if you call INCR 100 times on a counter, then the AOF file needs to use 100 entries just to save the current value of the counter. However, in reality, using only one SET command is enough to save the current value of the counter, and the remaining 99 records are actually redundant. In addition, there are some expired data and invalid data that can also be removed.

AOF files that are too large will not only affect the normal operation of the server, but also cause data recovery to take too long. In order to handle this situation, Redis supports an interesting feature that can rebuild the AOF file without interrupting the service client. Execute the BGREWRITEAOF command, Redis will generate a new AOF file, which contains the minimum commands required to reconstruct the current data set.

The AOF REWRITE (rewrite) generation process is similar to the RDB snapshot, both of which cleverly utilize the copy-on-write mechanism. It also forks a child process (the main thread is blocked at this time). The child process writes to the new AOF file according to the memory snapshot and the command merging rules. When the main process forks the child thread and continues to accept requests, all write commands are still written to the AOF buffer (aof_buf) and synchronized to the hard disk according to the appendfsync policy to ensure the correctness of the original AOF mechanism. However, since the fork operation uses copy-on-write technology, the child process can only share the memory data during the fork operation. Since the parent process is still responding to commands, Redis uses the AOF rewrite buffer (aof_rewrite_buf) to save this part of the new log to prevent this part of the data from being lost during the generation of the new AOF file. In other words, during the execution of bgrewriteaof, the Redis write command is appended to the two buffers aof_buf and aof_rewirte_buf at the same time.

When the child process finishes writing the new AOF file, it sends a signal to the parent process, and the parent process updates the statistical information, which can be viewed through info persistence. Then the parent process writes the data in the AOF rewrite buffer to the new AOF file, thus ensuring that the database state saved in the new AOF file is consistent with the current state of the server. Then call the atomic rename command to replace the old AOF file with the new AOF file to complete the AOF rewriting.

You need to pay attention here because the main process appends the aof_rewrite_buf cache to the new log file. When the main process appends logs, it will not process other requests. If aof_rewrite_buf is particularly large, such as hundreds of M, it may cause Redis to not respond for several seconds or even dozens of seconds.

We can see from the above process that RDB and AOF operations are both sequential IO operations, and their performance is very high. When restoring the database through RDB files or AOF logs, the data is also read sequentially and loaded into memory. So it will not cause random reading of the disk.

Triggering of file rewriting is divided into manual triggering and automatic triggering:

Manual triggering: Directly call the bgrewriteaof command. The execution of this command is somewhat similar to bgsave: both are fork sub-processes to perform specific operations. work, and they only block when forking.

Automatic triggering: Determine the triggering time based on the auto-aof-rewrite-min-size and auto-aof-rewrite-percentage parameters, as well as the aof_current_size and aof_base_size status.

auto-aof-rewrite-min-size indicates the minimum size of the file when performing AOF rewriting. The default value is 64MB.

auto-aof-rewrite-percentage表示执行AOF重写时，当前AOF大小（即aof_current_size）和上一次重写时AOF大小（aof_base_size）的比值，即增长比例达到设定值。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

其中，参数可以通过config get命令查看：

127.0.0.1:6391> CONFIG GET auto-aof-rewrite-min-size
1) "auto-aof-rewrite-min-size"2) "64000000"127.0.0.1:6391> CONFIG GET auto-aof-rewrite-percentage
1) "auto-aof-rewrite-percentage"2) "100"

状态可以通过info persistence查看：

127.0.0.1:6379> info persistence# Persistenceaof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_current_size:40876638
aof_base_size:2217565
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0

另外在aof rewrite过程中，是否采取增量”文件同步”策略，由参数aof-rewrite-incremental-fsync控制，默认为”yes”，而且必须为yes。rewrite过程中，每32M数据进行一次文件同步，这样可以减少”aof大文件”写入对磁盘的操作次数。

bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。

如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候Redis挂掉，就会丢失数据。丢失多少数据呢？在Linux的操作系统的默认设置下，最多会丢失30s的数据。因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

AOF刷新策略？

前面提到过，在AOF中，如果AOF缓冲区的文件同步策略为everysec，则：在主线程中，命令写入aof_buf后调用系统write操作，write完成后主线程返回；fsync同步文件操作由专门的文件同步线程每秒调用一次。这种做法的问题在于，如果硬盘负载过高，那么fsync操作可能会超过1s；如果Redis主线程持续高速向aof_buf写入命令，硬盘的负载可能会越来越大，IO资源消耗更快；如果此时Redis进程异常退出，丢失的数据也会越来越多，可能远超过1s。

为此，Redis的处理策略是这样的：主线程每次进行AOF会对比上次fsync成功的时间；如果距上次不到2s（也就是延迟了1s），主线程直接返回；如果超过2s，则主线程阻塞直到上一次fsync同步完成。因此，如果系统硬盘负载过大导致fsync速度太慢，会导致Redis主线程的阻塞；此外，使用everysec配置，AOF最多可能丢失2s的数据，而不是1s。具体看Redis AOF刷新策略分析

AOF追加阻塞问题定位的方法，监控info Persistence中的aof_delayed_fsync，当AOF追加阻塞发生时（即主线程等待fsync而阻塞），该指标累加。另外，AOF阻塞时的Redis日志：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

如果AOF追加阻塞频繁发生，说明系统的硬盘负载太大；可以考虑更换IO速度更快的硬盘，或者通过IO监控分析工具对系统的IO负载进行分析。

对于pipelining有什么不同？

对于pipelining的操作，其具体过程是客户端一次性发送N个命令，然后等待这N个命令的返回结果被一起返回。通过采用pipilining就意味着放弃了对每一个命令的返回值确认。由于在这种情况下，N个命令是在同一个执行过程中执行的。所以当设置appendfsync为everysec时，可能会有一些偏差，因为这N个命令可能执行时间超过1秒甚至2秒。但是可以保证的是，最长时间不会超过这N个命令的执行时间和。

如果AOF文件出错了，怎么办？

服务器可能在程序正在对AOF文件进行写入时停机，如果停机造成了 AOF 文件出错（corrupt），那么Redis在重启时会拒绝载入这个AOF文件， 从而确保数据的一致性不会被破坏。当发生这种情况时，可以用以下方法来修复出错的 AOF 文件：为现有的AOF文件创建一个备份。然后使用Redis附带的redis-check-aof –fix程序对原来的AOF文件进行修复。

然后可选使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。再次重启Redis服务器，等待服务器载入修复后的AOF文件，并进行数据恢复。

But if the end of the AOF file is incomplete (a sudden machine downtime can easily cause the end of the file to be incomplete), and the aof-load-truncated parameter is turned on, a warning will be output in the log, and Redis will ignore the end of the AOF file and start success. The aof-load-truncated parameter is enabled by default.

Advantages and Disadvantages of RDB and AOF

What are the advantages of RDB?

RDB is a very compact file with small size and fast network transmission. It saves the Redis data set at a certain point in time. This kind of file is very suitable for backup, and the recovery speed is much faster than AOF. Of course, one of the most important advantages of RDB is that it has a relatively small impact on performance compared to AOF. The only thing the parent process has to do when saving the RDB file is to fork out a child process, and then the child process will handle all subsequent saving work. The parent process does not need to perform any disk I/O operations.

Disadvantages of RDB?

The fatal shortcoming of the RDB file is that the persistence method of its data snapshot determines that it cannot be persisted in real time. Today, when data is becoming more and more important, a large amount of data loss is often unacceptable. Therefore, AOF persistence has become mainstream. In addition, RDB files need to meet a specific format and have poor compatibility (for example, the old version of Redis is not compatible with the new version of RDB files).

Advantages of AOF?

Corresponding to RDB persistence, the advantage of AOF is that it supports second-level persistence and has good compatibility. You can set different fsync policies, such as no fsync, fsync every second, or fsync every time a write command is executed. The default policy of AOF is fsync once per second. Under this configuration, Redis can still maintain good performance, and even if a failure occurs, only one second of data will be lost at most. The AOF file is a log file that only performs append operations (append only log), so writing to the AOF file does not require seeking, even if the log contains incomplete commands for some reasons (such as writing The disk is full, writing is stopped during writing, etc.), the redis-check-aof tool can also easily fix this problem.

Redis can automatically rewrite the AOF in the background when the AOF file size becomes too large: the rewritten new AOF file contains the minimum set of commands required to restore the current data set. The entire rewriting operation is absolutely safe, because Redis will continue to append commands to the existing AOF file during the process of creating a new AOF file. Even if there is a shutdown during the rewriting process, the existing AOF file will not be lost. . Once the new AOF file is created, Redis will switch from the old AOF file to the new AOF file and start appending to the new AOF file. The AOF file saves all write operations performed on the database in an orderly manner. These write operations are saved in the format of the Redis protocol, so the content of the AOF file is very easy to read and it is easy to analyze the file (parse). Exporting (exporting) AOF files is also very simple: for example, if you accidentally execute the FLUSHALL command, but as long as the AOF file has not been overwritten, then just stop the server, remove the FLUSHALL command at the end of the AOF file, and restart Redis. You can restore the data set to the state before FLUSHALL was executed.

Disadvantages of AOF?

The size of AOF files is usually larger than that of RDB files, and the recovery speed is slow. For the same data set, AOF may be slower than RDB depending on the fsync strategy used. Under normal circumstances, the performance of fsync per second is still very high, and turning off fsync can make AOF as fast as RDB. In addition, AOF has had such a bug in the past. Due to certain commands, when the AOF file is reloaded, the data set cannot be restored to the original state when it was saved. Although this kind of bug is not common in AOF files, in comparison, it is almost impossible for RDB to have this kind of bug.

RDB and AOF, which one should I use?

First of all, you must understand that whether it is RDB or AOF, turning on persistence comes at a performance cost: for RDB persistence, on the one hand, the Redis main process will be blocked when bgsave performs a fork operation, and on the other hand, the main process of Redis will be blocked when bgsave performs a fork operation. On the other hand, writing data to the hard disk by the child process will also bring IO pressure. But if the business can tolerate data loss of a few minutes to 10 minutes (and does not use a standby database), RDB is a good choice; otherwise, choose AOF.

For AOF persistence, the frequency of writing data to the hard disk is greatly increased (second level under everysec policy), the IO pressure is greater, and may even cause AOF append blocking problems (this blocking will be described in detail later). In addition, the rewriting of AOF files is similar to RDB's bgsave, and there will be problems of blocking during fork and IO pressure of the child process. Relatively speaking, because AOF writes data to the hard disk more frequently, it will have a greater impact on the performance of the Redis main process.

在实际生产环境中，根据数据量、应用对数据的安全要求、预算限制等不同情况，会有各种各样的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一种，或同时开启RDB和AOF持久化等。此外，持久化的选择必须与Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能，而且主机master和从机slave可以独立的选择持久化方案。比如完全关闭master持久化（包括RDB和AOF），这样可以让master的性能达到最好；而slave可以只开启AOF。但这种情况下，如果master服务因为故障宕掉了，如果系统中有自动拉起机制（即检测到服务停止后重启该服务）将master自动重启，由于没有持久化文件，那么master重启后数据是空的，slave同步数据也变成了空的，意味着数据丢失。所以尽量避免这种情况出现。

RDB和AOF之间的相互作用？

在版本号大于等于2.4的Redis中，BGSAVE执行的过程中，不可以执行BGREWRITEAOF。反过来说，在BGREWRITEAOF执行的过程中，也不可以执行BGSAVE。这可以防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

如果BGSAVE正在执行，并且用户显示地调用BGREWRITEAOF命令，那么服务器将向用户回复一个OK状态，并告知用户，BGREWRITEAOF已经被预定执行： 一旦BGSAVE执行完毕，BGREWRITEAOF就会正式开始。当Redis启动时，如果RDB持久化和AOF持久化都被打开了，那么程序会优先使用AOF文件来恢复数据集，因为AOF文件所保存的数据通常是最完整的。

RDB和AOF数据导入

这些持久化的数据有什么用，当然是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB或AOF进行恢复的时候，会读取RDB或AOF文件，重新加载到内存中。相对于MySQL等数据库的启动时间来说，会长很多，因为MySQL本来是不需要将数据加载到内存中的。

但是相对来说，MySQL启动后提供服务时，其被访问的热数据也会慢慢加载到内存中，通常我们称之为预热，而在预热完成前，其性能都不会太高。而Redis的好处是一次性将数据加载到内存中，一次性预热。这样只要Redis启动完成，那么其提供服务的速度都是非常快的。

而在利用RDB和利用AOF启动上，其启动时间有一些差别。RDB的启动时间会更短，原因有两个，一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作。在CPU消耗上要远小于AOF日志的加载。

注意：当redis启动时，如果rdb持久化和aof持久化都打开了，那么程序会优先使用aof方式来恢复数据集，因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了，则启动之后数据库内容为空。

注意：如果想把正在运行的redis数据库，从RDB切换到AOF，建议先使用动态切换方式，再修改配置文件，重启数据库。(不能直接修改配置文件，重启数据库，否则数据库中数据就为空了。) 在Redis 2.2或以上版本，可以在不重启的情况下，从RDB切换到AOF ：

为最新的dump.rdb文件创建一个备份，将备份放到一个安全的地方。执行以下两条命令：

127.0.0.1:6379> CONFIG SET dir /apps/redis/data/redis-8836
127.0.0.1:6379> CONFIG SET appendonly yes
127.0.0.1:6379> CONFIG SET save ""

确保命令执行之后，数据库的键的数量没有改变。确保写命令会被正确地追加到 AOF 文件的末尾。

步骤2是开启了AOF功能，Redis会阻塞直到初始AOF文件创建完成为止，之后Redis会继续处理命令请求，并开始将写入命令追加到AOF文件末尾。

步骤3用于关闭RDB功能，这一步是可选的，如果你愿意的话，也可以同时使用RDB和AOF这两种持久化功能。

The above is the detailed content of How to use Redis's RDB and AOF methods. For more information, please follow other related articles on the PHP Chinese website!