图解分析redis的RDB和AOF两种持久化机制的工作原理

2019独角兽企业重金招聘Python工程师标准>>>

Redis强大的功能很大部分是由于他把数据缓存在内存中，为了使redis在重启的时候，数据不丢失，就需要已某种方式把数据持久化到磁盘中。Redis持久化的方式有俩种，RDB和AOF。

RDB原理分析

RDB：快照方式，允许你每隔一段时间对内存数据做一次快照然后存储到硬盘中。该方式是Redis默认的持久化方式。

RDB可以通过在配置文件中配置时间或者改动键的个数来定义快照条件，编辑配置文件redis.conf，找到

save 900 1  #15分钟之内至少有一个建被更改则进行快照
save 300 10  #5分钟之内至少有10个建被更改则进行快照
save 60 10000  #1分钟之内至少有1000个建被更改则进行快照

他们之间是或的关系，RDB持久化到磁盘的文件默认路径是在当前目录，文件名为dump.rdb，你可以通过配置文件配置dir和dbfilename来指定文件目录和文件名称，RDB文件还可以进行压缩，你可以通过配置rdbcompression参数来进行压缩。

总结下RDB的流程：

    

（1）redis根据配置自己尝试去生成rdb快照文件

（2）fork一个子进程出来

（3）子进程尝试将数据dump到临时的rdb快照文件中

（4）完成rdb快照文件的生成之后，就替换之前的旧的快照文件

dump.rdb，每次生成一个新的快照，都会覆盖之前的老快照

 

AOF原理分析

AOF持久化，默认是关闭的，默认是打开RDB持久化

AOF：通过将发送到服务器的写操作命令记录下来，形成AOF文件，文件默认名称是appendonly.aof，可以通过appendfilename来指定文件名称。你可以通过配置文件打开AOF功能

appendonly yes

AOF的原理是直接把用户插入到服务器的命令追加到结尾，那么文件会原来越大，一些重复的写命令也会越来越多，这时，我们可以利用BGREWRITEAOF 命令来重写AOF，重写的配置如下：

auto-aof-rewrite-percentage 100 #aof文件大小超过上次重写时文件大小的百分之几开始重写，如果之前没有写过，则根据启动时文件大小。

auto-aof-rewrite-min-size 64mb #限制允许重写时的最小文件大小。

AOF在同步内存数据到磁盘上时，并不是马上把文件写如到磁盘中，而是先把文件缓存到系统，然后每隔30秒将文件写入到磁盘中，我们可以在配置文件中配置同步的策略

appendfsync always #每次都同步，保证数据不会丢失，但会慢
appendfsync everysec #每秒同步，系统默认同步策略
appendfsync no #不主动同步，由操作系统决定，快，但数据容易丢失

AOF rewrite

redis中的数据其实有限的，很多数据可能会自动过期，可能会被用户删除，可能会被redis用缓存清除的算法清理掉。redis中的数据会不断淘汰掉旧的，就一部分常用的数据会被自动保留在redis内存中，所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，到很大很大，所以AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了; redis内存只剩下10万; 基于内存中当前的10万数据构建一套最新的日志，到AOF中; 覆盖之前的老日志; 确保AOF日志文件不会过大，保持跟redis内存数据量一致。redis 2.4之前，还需要手动，开发一些脚本，crontab，通过BGREWRITEAOF命令去执行AOF rewrite，但是redis 2.4之后，会自动进行rewrite操作在redis.conf中，可以配置rewrite策略

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

比如说上一次AOF rewrite之后，是128mb。然后就会接着128mb继续写AOF的日志，如果发现增长的比例，超过了之前的100%，256mb，就可能会去触发一次rewrite但是此时还要去跟min-size，64mb去比较，256mb > 64mb，才会去触发rewrite

AOF的流程如下：

（1）redis fork一个子进程

（2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志

（3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件

（4）子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中

（5）用新的日志文件替换掉旧的日志文件

 

AOF破损文件的修复

     如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件破损用redis-check-aof --fix命令来修复破损的AOF文件。

 

AOF和RDB同时工作

    

（1）如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting

（2）如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite

（3）同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整

转载于:https://my.oschina.net/u/2286631/blog/1057221