Redis持久化

RDB快照

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

save 60 1000

除了在配置文件中使用save关键字设置RDB快照，还可以在命令行中手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件。每次执行命令都会将所有redis内存快照保存到一个rdb文件里，并覆盖原有的rdb快照文件。save是同步命令，bgsave是异步命令，bgsave会从redis主进程fork出一个子进程专门用来生成rdb二进制文件。

AOF（append only file）

快照功能并不是非常durable，如果redis因为某些原因而造成故障停机，那么服务器将丢失最近写入且未保存到快照中的那些数据。从1.1版本，redis增加了一种完全durable的方式：AOF持久化，将修改的每一条指令记录进appendonly.aof中。修改配置文件来打开aof功能：

appendonly yes

打开aof功能，每当redis执行一个改变数据集的命令时，这个命令就会追加到aof文件的末尾。这样的话，当redis重新启动时，程序就会通过执行aof文件中的命令来达到重建数据集的目的。可以配置redis多久才将命令持久化到磁盘一次。

appendfsync always：每次有新命令追加到aof文件时就执行一个持久化，非常慢但是安全
appendfsync everysec：每秒执行一次持久化，足够快（和使用rdb持久化差不多）并且在故障时只会丢失1秒钟的数据
appendfsync no：从不持久化，将数据交给操作系统来处理。redis处理命令速度加快但是不安全。

默认情况下 ，每秒执行一次fsync， 这种fsync策略可以兼顾安全性和速度。rdb和aof的区别：

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

二、AOF重写aof文件里可能有太多“琐碎”指令，所以aof会定期根据内存的最新数据重新生成aof文件有两个配置可以控制aof自动重写的频率：

auto-aof-rewrite-min-size 64mb： aof文件至少要达到64m才会触发制动重写，文件太小恢复速度本来就很快，重写的意义不大
auto-aof-rewrite-percentage 100：aof文件上一次重写后文件大小增长了100%则再次触发重写

当然aof还可以手动重写，进入redis客户端执行命令bgrewriteaof重写aof。触发aof重写时，redis会fork一个子进程去做，不会对redis正常命令处理有太多影响。

Redis 4.0混合持久化

重启redis恢复数据集时，很少会使用rdb来恢复内存状态，因为会丢失大量数据。通常会使用aof日志恢复数据，但是重放aof日志性能相对rdb来说要慢很多，这样在redis实例很大的情况下，启动需要花费很长时间。Redis4.0为了解决这个问题，带来了新的持久化选项——混合持久化。

aof-use-rdb-preamble yes

混合持久化aof文件结构：

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

》》》相比赞赏，更喜欢被转发