【Redis】RDB AOF

AOF和RDB是两种redis持久化的机制。

RDB:
RDB是将支持当前数据的快照存成一个数据文件的持久化机制。
1.在生成快照时，将当前进程fork出一个子进程.
2.然后在子进程中循环所有的数据，将数据写入到二进制文件中。
3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
优点:
1.一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这样非常方便进行备份。比如你可能打算每1天归档一些数据。
2.方便备份的同时，我们也很容易的将一个RDB文件移动到其他存储物质上。
3.RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
劣势:
如果你想在服务器上避免数据的丢失，那么RDB就不适合了，因为RDB文件需要保存整个数据集的状态，因为你可能会在5分钟才保存一次RDB文件，在这种情况下，一旦发生故障停机，你可能会损失好几分钟的数据。
每次在保存RDB的时候，Redis都要fork出一个子进程，并由子进程来进行实际的持久化工作，如果在数据集比较庞大时，fork可能会非常耗时，造成服务器在那么一瞬间会停止处理客户端；虽然AOF重写也需要进行fork，但AOF重写的执行时间间隔有多长，数据的耐久性都不会有任何损失。

AOF:
AOF: Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。AOF的工作原理就是是将写操作追加到文件中，文件的冗余内容会越来越多。所以Redis 新增了重写机制。当AOF文件的大小超过所设定的最大值时，Redis就会对AOF文件的内容压缩。
优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

总结
Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，将内存中的数据写入到磁盘中。
RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
若只打算用Redis 做缓存，可以关闭持久化。
若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

 

RDB快照(snapshot)

在默认情况下，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。
你可以对Redis进行设置，让它在"N秒内数据集至少有M个改动“这一条件被满足时，自动保存一次数据集。比如说，以下设置会让Redis在满足”60秒内有至少有1000个键被该栋“这一条件时，自动保存一次数据集。

# save 60 1000 #关闭RDB只需要将所有的save保存策略注释掉即可

还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件中里，并覆盖原有rdb快照文件。

bgsave的写时复制(COW)机制

Redis借助操作系统提供的写时复制技术(Copy-On-Write COW),在生成快照的同时，依然可以正常处理写命令。简单来说，bgsave子进程是由主线程fork生成的，可以共享主线程的所有内存数据。bgsave子进程运行后，开始读取主线程的内存数据，并把它们写入RDB文件，此时如果主线程对这些数据也都是读操作，那么，主线程和bgsave子进程相互不影响。但是，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本，然后，bgsave子进程会把这个副本数据写入RDB文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

save与bgsave对比：

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis其它命令	是	否(在生成子进程执行调用fork函数时会有短暂阻塞)
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，消耗内存

配置自动生成rdb文件后台使用的是bgsave方式。

AOF(append-only file)

快照功能并不是非常耐久(durable):如果Redis因为某些原因造成故障停机，那么服务器将都是最近写入，且仍未保存到快照中的那些数据，从1.1版本开始，Redis增加了一种完全耐久的持久化方式:AOF持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache,每隔一段时间fsync到磁盘）你可以通过修改配置文件来打开AOF功能：

# appendonly yes

从现在开始，每当Redis执行一个改变数据集的命令时（比如SET），这个命令就会追加到AOF文件的末尾。这样的话，当Redis重新启动时，程序就可以通过重新执行AOF文件的命令来达到重建数据集的目的。你可以配置Redis多久才将数据fsync到磁盘一次。
有三个选项：

appendfsync always: 每次有新命令追加到AOF文件时就执行一次fsync,非常慢，非常安全。
appendsync everysec: 每秒fsync一次，足够快，并且在故障时只会都是1秒中的数据。
appendfsync no: 从不fsync,将数据交给操作系统来处理，更快，也更不安全的选择。

推荐（并且也是默认）的措施未每秒fsync一次，这种fsync策略可以兼顾速度和安全性。

AOF重写

AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件。

执行bgrewriteaof过后

 

将多条命令转化成一条命令执行。

如果两个配置可以控制AOF自动重写频率

# auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
# auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写
当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF。

注意，AOF重写redis会fork出一个子进程去做(与bgsave命令类似），不会对redis正常命令处理有太多影响。

RDB和AOF，我应该用哪一个？

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	容易丢数据	根据策略决定

生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更安全一点。

Redis 4.0 混合持久化

重启Redis时，我们很少使用RDB来恢复内存状态，因为会丢失大量数据，通常使用AOF日志重放，但是重放AOF日志性能相对RDB来说要慢很多，这样在Redis实例很大的情况下，启动需要花费很长的时间。Redis4.0为了解决这个问题，带来了一个新的持久化选项--混合持久化。
通过如下配置可以开启混合持久化(必须先开启aof):

# aof-use-rdb-preamble yes

image.png

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成后旧两个AOF文件的替换。于是在Redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放，因此重启效率大幅度得到提升。
混合持久化AOF文件结构如下：