NoSQL之【Redis】学习（三）：Redis持久化 Snapshot和AOF说明

2026-06-01 4 花语

本文内容纲要：

一、对Redis持久化的探讨与理解

redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式，一种是Snapshot（RDB）<二进制文件>也是默认方式，另一种是Appendonlyfile（AOF）的方式。

我们应该明确持久化的数据有什么用，答案是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。

RDB就是Snapshot快照存储，是默认的持久化方式。即按照一定的策略周期性的将数据保存到磁盘。对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。Redis支持将当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢。Redis借助了fork命令的copyonwrite机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。

Client也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有client的请求，这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的。当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。并且Redis的RDB文件也是Redis主从同步内部实现中的一环:

第一次

Slave向Master同步的实现是：

Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。

第二次

以及以后的同步实现是：

Master将变量的快照直接实时依次发送给各个Slave。但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。

Redis的主从复制是建立在内存快照的持久化基础上的，只要有Slave就一定会有内存快照发生。

快照持久化过程：

1.redis调用fork,现在有了子进程和父进程。 2.父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copyonwrite)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。 3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

**不足：**就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了（因为刷写机制还没有发出）。RDB就是Snapshot快照存储，是默认的持久化方式。

相关参数：

1##############################APPENDONLYMODE############################### 2#是否开启AOF，默认关闭（no） 3appendonlyyes 4#指定AOF文件名 5appendfilenameappendonly.aof 6#Redis支持三种不同的刷写模式： 7#appendfsyncalways#每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。 8appendfsynceverysec#每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。 9#appendfsyncno#完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。 10 11#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISKIO上的冲突。 12#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes 13no-appendfsync-on-rewriteyes 14#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。 15auto-aof-rewrite-percentage100 16#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。 17auto-aof-rewrite-min-size64mb

从上面看出，RDB和AOF操作都是顺序IO操作，性能都很高。而同时在通过RDB文件或者AOF日志进行数据库恢复的时候，也是顺序的读取数据加载到内存中。所以也不会造成磁盘的随机读。

到底选择什么呢？下面是来自官方的建议：

通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。

很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。

在数据恢复方面：

RDB的启动时间会更短，原因有两个：

一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。

另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

注意：

上面说了RDB快照的持久化，需要注意：在进行快照的时候（save），fork出来进行dump操作的子进程会共享父进程的内存（真正的copy-on-write）。比如机器8G内存，Redis已经使用了6G内存，这时新操作100M的内存，save的话会再多生成100M（放到缓冲区里），总共进行RDB的时候会多出100M，既6.1G的内存。

目前，通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足，达到了数据可持久化。即Master上Snapshot和AOF都不做，来保证Master的读写性能，而Slave上则同时开启Snapshot和AOF来进行持久化，保证数据的安全性。

二、对Redis持久化的测试

通过上面的理论对snapshot和aof有了一定的理解，下面开始进行一些测试：

：

1、redis.conf基本配置:开启snapshot，关闭aof 1save9001 2save30010 3save6010000 4 5rdbcompressionno 6rdbchecksumno 7dbfilenamezhoujy.rdb 8dir/var/lib/redis 9 10appendonlyno

操作

1redis127.0.0.1:6379>keys*#查看0库下是否有key 2(emptylistorset) 3redis127.0.0.1:6379>setnamezhoujinyi#set操作 4OK 5redis127.0.0.1:6379>setsexman 6OK 7redis127.0.0.1:6379>setage27 8OK 9redis127.0.0.1:6379>keys* 101)"age" 112)"sex" 123)"name" 13redis127.0.0.1:6379> 14zhoujy@zhoujy:~$ls-lh/var/lib/redis/#rdb文件初始化大小 15总用量4.0K 16-rw-rw----1redisredis182013-05-2516:19zhoujy.rdb 17zhoujy@zhoujy:~$redis 18redis127.0.0.1:6379>save#保存，进行持久化，每执行一次save，会在日至里面记录一条：“*DBsavedondisk” 19OK 20redis127.0.0.1:6379> 21zhoujy@zhoujy:~$ls-lh/var/lib/redis/#文件大小改变，数据写入文件进行了持久化 22总用量4.0K 23-rw-rw----1redisredis522013-05-2516:20zhoujy.rdb 24 25验证持久化，重启redis： 26 27redis127.0.0.1:6379>keys* 281)"name" 292)"age" 303)"sex" 31redis127.0.0.1:6379>setaddresshangzhou#key没有被保存就重启了 32OK 33redis127.0.0.1:6379> 34zhoujy@zhoujy:~$sudo/etc/init.d/redis-serverrestart 35Stoppingredis-server:redis-server. 36Startingredis-server:redis-server. 37zhoujy@zhoujy:~$redis 38redis127.0.0.1:6379>keys*#发现刚才没有被保存的key也被持久化了，怎么回事？ 391)"name" 402)"address" 413)"sex" 424)"age" 43redis127.0.0.1:6379> 44 45查看日志，看看日志里面有什么信息： 46 47[21154]25May16:28:12.122#Userrequestedshutdown... 48[21154]25May16:28:12.122*SavingthefinalRDBsnapshotbeforeexiting. 49[21154]25May16:28:12.165*DBsavedondisk 50[21154]25May16:28:12.165*Removingthepidfile. 51[21154]25May16:28:12.165*Removingtheunixsocketfile. 52[21154]25May16:28:12.165#Redisisnowreadytoexit,byebye... 53 54从日志里面得到了解释，正常关闭redis，他会自己在关闭前执行save命令。那异常关闭呢？用kill的效果和上面一样，属于正常关闭。只能用kill-9才行： 54 55redis127.0.0.1:6379>keys* 561)"age" 572)"name" 583)"sex" 594)"address" 60redis127.0.0.1:6379>setcompanydxy 61OK 62redis127.0.0.1:6379>keys* 631)"name" 642)"sex" 653)"age" 664)"address" 675)"company" 68redis127.0.0.1:6379>#key没有被保存就重启了 69zhoujy@zhoujy:~$sudokill-921250 70zhoujy@zhoujy:~$redis 71CouldnotconnecttoRedisat127.0.0.1:6379:Connectionrefused 72notconnected> 73zhoujy@zhoujy:~$sudo/etc/init.d/redis-serverstart 74Startingredis-server:redis-server. 75zhoujy@zhoujy:~$redis 76redis127.0.0.1:6379>keys*#company没有被持久化，数据丢失，重启日志里没有“*DBsavedondisk”信息 771)"sex" 782)"age" 793)"address" 804)"name" 81redis127.0.0.1:6379>

总结1：从上面的结果看出，开启RDB持久化，在满足save条件、手动save、正常关闭的时候数据都会被持久化，而异常关闭终止的时候数据会丢失。

2、redis.conf基本配置:关闭snapshot，关闭aof

1#save9001 2#save30010 3#save6010000 4rdbcompressionno 5rdbchecksumno 6dbfilenamezhoujy.rdb 7dir/var/lib/redis 8 9appendonlyno

操作

1redis127.0.0.1:6379>keys*#查看0库下是否有key 2(emptylistorset) 3redis127.0.0.1:6379>setnamezhoujinyi#set操作 4OK 5redis127.0.0.1:6379>setsexman 6OK 7redis127.0.0.1:6379>setage27 8OK 9redis127.0.0.1:6379>save#保存，进行持久化，即使没有开始snapshot，执行save命令一样可以持久化，不手动的触发永远不会持久化。 10OK#每执行一次save，会在日志里面记录一条：“*DBsavedondisk” 11redis127.0.0.1:6379>setaddresshangzhou#set操作，但不save，正常重启 12OK 13redis127.0.0.1:6379> 14zhoujy@zhoujy:~$sudo/etc/init.d/redis-serverrestart#正常重启 15[sudo]passwordforzhoujy: 16Stoppingredis-server:redis-server. 17Startingredis-server:redis-server. 18zhoujy@zhoujy:~$redis 19redis127.0.0.1:6379>keys*#发现刚才没有被保存的key丢失了 201)"sex" 212)"name" 223)"age" 23redis127.0.0.1:6379>

总结2：从上面的结果看出，关闭持久化，只有在手动save的时候数据都会被持久化，正常关闭的时候数据丢失。要是从一开始到关闭写入数据的期间没有手动save，则数据全部丢失！既然能手动save间接的说明了快照一直都存在，所以不能说是禁止snapshot，应该是禁止自动snapshot功能。

通过1，2验证了之前说的：一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，下面看看AOF。

3、redis.conf基本配置:关闭snapshot，开启aof

1#save9001 2#save30010 3#save6010000 4 5appendonlyyes 6appendfilenamezhoujy.aof 7#appendfsyncalways 8appendfsynceverysec 9#appendfsyncno 10 11no-appendfsync-on-rewriteno 12auto-aof-rewrite-min-size64mb

操作

1#重启数据库之前有3个key： 2redis127.0.0.1:6379>keys* 31)"sex" 42)"age" 53)"name" 6#修改开启AOF参数，重启数据库： 7zhoujy@zhoujy:~$ls-lh/var/lib/redis/ 8总用量4.0K 9-rw-r-----1redisredis02013-05-2517:41appendonly.aof#aof持久化已经开启，0字节大小 10-rw-rw----1redisredis522013-05-2517:34zhoujy.rdb 11 12redis127.0.0.1:6379>keys*#数据库里面没有记录？之前还有3个key，Why？ 13(emptylistorset) 14redis127.0.0.1:6379> 15 16#查看日志： 17*DBloadedfromappendonlyfile:0.000seconds 18发现是从0字节的aof文件里面同步数据，为什么不同步rdb的数据？原来redis代码里面写好了优先级，AOF>RDB 19 20redis.c里的代码如下： 21 22voidloadDataFromDisk(void){ 23longlongstart=ustime(); 24if(server.aof_state==REDIS_AOF_ON){ 25if(loadAppendOnlyFile(server.aof_filename)==REDIS_OK) 26redisLog(REDIS_NOTICE,"DBloadedfromappendonlyfile:%.3fseconds",(float)(ustime()-start)/1000000); 27}else{ 28if(rdbLoad(server.rdb_filename)==REDIS_OK){ 29redisLog(REDIS_NOTICE,"DBloadedfromdisk:%.3fseconds", 30(float)(ustime()-start)/1000000); 31}elseif(errno!=ENOENT){ 32redisLog(REDIS_WARNING,"FatalerrorloadingtheDB:%s.Exiting.",strerror(errno)); 33exit(1); 34} 35} 36}

这里需要注意的是:当中途开启AOF，重启让他生效的时候，千万不能再让他第2次正常重启了。因为第一次重启让aof生效的时候，启动redis已经读取这个文件了，导致此时的redis数据为空的（优先级）。要是再重启的，则会把这个空的数据save到RDB文件，这样导致RDB原有的数据被替换，导致数据丢失。所以一定要小心，为了避免悲剧的发生，当要重启redis的时候最好都备份下RDB文件。

1redis127.0.0.1:6379>keys* 2(emptylistorset) 3redis127.0.0.1:6379>setnamezhoujinyi 4OK 5redis127.0.0.1:6379>save 6OK 7 8#开启aof参数，重启redis生效（第一次重启） 9root@m2:/var/lib/redis#/etc/init.d/redis-serverrestart 10Stoppingredis-server:redis-serverstop!. 11Startingredis-server:redis-serverstart! 12root@m2:/var/lib/redis#ls-lh#生成aof文件，已经生效 13总用量4.0K 14-rw-r-----1rootroot05月2601:12appendonly.aof 15-rw-rw----1rootroot365月2601:12dump.rdb 16 17redis127.0.0.1:6379>keys*#如上面所说的优先级原因:aof>rdb，结果为空 18(emptylistorset) 19 20#再重启（第2次正常重启），把上面空的结果save到了RDB，数据丢失。此时的db是空的，日志记录"*DBsavedondisk" 21root@m2:/var/lib/redis#/etc/init.d/redis-serverrestart 22Stoppingredis-server:redis-serverstop!. 23Startingredis-server:redis-serverstart! 24 25root@m2:/var/lib/redis#ls-lh#数据已经被初始化了，数据丢失。 26总用量4.0K 27-rw-r-----1rootroot05月2601:12appendonly.aof 28-rw-rw----1rootroot185月2601:13dump.rdb 29redis127.0.0.1:6379>keys* 30(emptylistorset)

这里就有一个问题，比如在用redis的时候，刚开始只开启RDB的持久方式，AOF没有开启，在跑一段时间之后想开启AOF，那如何把RDB的数据直接写到AOF文件呢

？有2种方法：

①:在开启AOF之前，先执行bgrewriteaof，再重启。 1redis127.0.0.1:6379>keys*#查看是否有数据 2(emptylistorset) 3redis127.0.0.1:6379>setnamezhoujinyi#生成数据 4OK 5redis127.0.0.1:6379>setsexman 6OK 7redis127.0.0.1:6379>setage27 8OK 9redis127.0.0.1:6379>keys* 101)"name" 112)"sex" 123)"age" 13redis127.0.0.1:6379>bgsave#保存数据 14Backgroundsavingstarted 15redis127.0.0.1:6379>keys* 161)"name" 172)"sex" 183)"age" 19root@m2:/var/lib/redis#ls-lh#只有一个RDB文件，没有AOF文件 20总用量4.0K 21-rw-rw----1rootroot525月2523:48dump.rdb 22 23redis127.0.0.1:6379>bgrewriteaof#执行合并重写功能，生成AOF文件 24Backgroundappendonlyfilerewritingstarted 25 26root@m2:/var/lib/redis#ls-lh#AOF文件生成成功 27总用量8.0K 28-rw-rw----1rootroot1225月2523:49appendonly.aof 29-rw-rw----1rootroot525月2523:48dump.rdb 30#这时候去打开redis.conf文件中的aof参数（appendonlyyes），重启生效。 31root@m2:/var/lib/redis#/etc/init.d/redis-serverrestart 32Stoppingredis-server:redis-serverstop! 33Startingredis-server:redis-serverstart! 34 35#日志里面出现：*DBloadedfromappendonlyfile:0.000seconds 36 37redis127.0.0.1:6379>keys*#数据还在 381)"sex" 392)"name" 403)"age"

②:利用CONFIGGET/SET的方法动态修改配置文件，和①比少了重启的操作。

1redis127.0.0.1:6379>setnamezhoujinyi 2OK 3redis127.0.0.1:6379>setsexman 4OK 5redis127.0.0.1:6379>setage27 6OK 7redis127.0.0.1:6379>keys* 81)"age" 92)"name" 103)"sex" 11redis127.0.0.1:6379>BGSAVE 12Backgroundsavingstarted 13redis127.0.0.1:6379> 14 15root@m2:/var/lib/redis#ls-lh#只有rdb文件 16总用量4.0K 17-rw-rw----1rootroot525月2600:09dump.rdb 18 19#动态修改参数，把aof功能开启：appendonlyyes 20 21redis127.0.0.1:6379>CONFIGGETappend*#在线查看参数 221)"appendonly" 232)"no" 243)"appendfsync" 254)"everysec" 26redis127.0.0.1:6379>CONFIGSETappendonlyyes#动态修改参数 27OK 28redis127.0.0.1:6379>CONFIGGETappend* 291)"appendonly" 302)"yes" 313)"appendfsync" 324)"everysec" 33redis127.0.0.1:6379> 34 35root@m2:/var/lib/redis#ls-lh#aof文件已经生成，并且有数据（同步rdb）。 36总用量8.0K 37-rw-rw----1rootroot1225月2600:10appendonly.aof 38-rw-rw----1rootroot525月2600:09dump.rdb 39 40#日志里面的信息：*Backgroundappendonlyfilerewritingstartedbypid3165 41#因为参数是动态修改的，在重启之后会失效，所以在维护的时候修改redis.conf文件的参数即可。

**总结3：**

从上面的结果看出，redis重启载入数据的时候，读取aof的文件要先于rdb文件，所以尽量一开始开启aof选项，不要在中途开启。通过日志可以很清楚的知道redis通过那个文件来取数据的：

RDB:*DBloadedfromdisk:0.000seconds

AOF：*DBloadedfromappendonlyfile:0.000seconds

保存数据则是：

RDB：*DBsavedondisk
AOF:*Callingfsync()ontheAOFfile.

4、redis.conf基本配置:开启snapshot，开启aof

1save9001 2save30010 3save6010000 4 5appendonlyyes 6appendfilenamezhoujy.aof 7#appendfsyncalways 8appendfsynceverysec 9#appendfsyncno 10 11no-appendfsync-on-rewriteno 12auto-aof-rewrite-min-size64mb

操作

1#同时开启这2个参数，在日志里面会记录: 2*Callingfsync()ontheAOFfile. 3*DBsavedondisk 4 5redis127.0.0.1:6379>keys* 6(emptylistorset) 7redis127.0.0.1:6379>setnamezhoujinyi 8OK 9redis127.0.0.1:6379>setage27 10OK 11redis127.0.0.1:6379>setsexman 12OK 13redis127.0.0.1:6379>keys* 141)"name" 152)"age" 163)"sex" 17 18root@m2:/var/lib/redis#ls-lh#aof,rdb2个文件已经生成，并且aof文件大小根据操作命令实时增加，而rbd需要手动save或则到了刷写机制的阀值才增加 19总用量8.0K 20-rw-r-----1rootroot1225月2600:39appendonly.aof 21-rw-rw----1rootroot185月2600:37dump.rdb 22 23redis127.0.0.1:6379>save#保存快照 24OK 25 26root@m2:/var/lib/redis#ls-lh#rdb文件大小增加 27总用量8.0K 28-rw-r-----1rootroot1365月2600:41appendonly.aof 29-rw-rw----1rootroot525月2600:41dump.rdb 30 31redis127.0.0.1:6379>flushall#清除所有数据 32OK 33 34root@m2:/var/lib/redis#ls-lh#数据清除之后，rdb文件大小初始化了，而aof文件却增加了，Why？ 35总用量8.0K 36-rw-r-----1rootroot1545月2600:43appendonly.aof 37-rw-rw----1rootroot185月2600:43dump.rdb 38#原来aof文件记录的是修改数据的操作，所以文件是追加形式的，flushall命令被追加到最后。 39 40root@m2:/var/lib/redis#/etc/init.d/redis-serverrestart#重启，看看通过aof的载入能否被读取到？ 41Stoppingredis-server:redis-serverstop!. 42Startingredis-server:redis-serverstart! 43root@m2:/var/lib/redis#ls-lh#aof文件大小不变，重启不能初始化aof文件 44总用量8.0K 45-rw-r-----1rootroot1545月2600:43appendonly.aof 46-rw-rw----1rootroot185月2600:45dump.rdb 47 48redis127.0.0.1:6379>keys*#日志里面记录“*DBloadedfromappendonlyfile:0.012seconds”，但没有数据，说明aof确实被初始化了。 49(emptylistorset) 50 51#因为数据都已经被清除了，想让aof文件大小也初始化掉，该如何操作呢？ 52很简单： 53redis127.0.0.1:6379>bgrewriteaof#让aof合并重写，因为aof文件的最后一条记录的flushall操作，前面的记录都无效了，合并所有操作之后就初始化了。 54Backgroundappendonlyfilerewritingstarted 55redis127.0.0.1:6379> 56 57root@m2:/var/lib/redis#ls-lh#aof文件被初始化 58总用量4.0K 59-rw-rw----1rootroot05月2600:51appendonly.aof 60-rw-rw----1rootroot185月2600:45dump.rdb

通过上面的这些测试，已经说明RDB和AOF他们的操作方式，以及如重启时的载入，重启时将按照以下优先级恢复数据到内存：

•如果只配置AOF,重启时加载AOF文件恢复数据。 •如果同时配置了RBD和AOF,启动是只加载AOF文件恢复数据。 •如果只配置RBD,启动是讲加载dump文件恢复数据。

为了防止悲剧的发生，我们应该进行备份。

三、对Redis备份

备份很简单，只需要把RDB，AOF的文件复制备份起来就可以了。相同版本的备份文件可以任意使用。不同版本没有试过。

1#redisA:A上生成测试数据 2redis127.0.0.1:6379>setnamezhoujinyi 3OK 4redis127.0.0.1:6379>setsexman 5OK 6redis127.0.0.1:6379>setage17 7OK 8redis127.0.0.1:6379>keys* 91)"age" 102)"name" 113)"sex" 12redis127.0.0.1:6379>bgsave 13Backgroundsavingstarted 19#redisB:B上没有数据 20redis127.0.0.1:6380>keys* 21(emptylistorset) 22 23#复制A的文件到B（rdb和aof文件） 24cpredis/*redis2/ 25#修改权限 26chown-Rredis.redis* 27#重启B 28zhoujy@m2:~$redis-p6380shutdown 29zhoujy@m2:~$redis-p6380 30#还原成功 31redis127.0.0.1:6380>keys* 321)"sex" 332)"name" 343)"age"

以上完成。

本文内容总结：

原文链接：https://www.cnblogs.com/zhoujinyi/archive/2013/05/26/3098508.html