RDB快照（snapshot）

在默认情况下，Redis将内存数据库快照保存在名为 dump.rdb 的二进制文件中，可通过 redis.conf 的配置，让它在 N秒内数据集至少有M个改动的这一条件满足时，自动保存一次数据，具体redis.conf 配置如下：

# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 key changed
#   * After 300 seconds (5 minutes) if at least 100 keys changed
#   * After 60 seconds if at least 10000 keys changed
#
# You can set these explicitly by uncommenting the three following lines.
#
# save 3600 1
# save 300 100
# save 60 10000

还可以手动执行命令生产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对比

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

AOF（append-only file）

AOF持久化，将修改的每一条指令记录进文件appendonly.aof中（先写入os cache，每隔一段时间fsync到磁盘），Redis从1.1版本开始，增加了AOF耐久的持久化方式。RDB（快照）的持久化功能并不是非常耐久，如果Redis因为某个原因造成故障停机，那么服务器将丢失最近写入且仍未保存到快照中的那些数据。

AOF配置

修改redis.conf配置，开启AOF持久化配置

# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check https://redis.io/topics/persistence for more information.

appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

配置Redis多久将数据fsync到磁盘一次，配置信息如下：

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

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

AOF自动重写频率配置，配置信息如下：

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

AOF支持手动重写，在客户端执行命令bgrewriteaof重写。AOF重写redis会fork出一个子进程去做（与bgsave命令类似），不会对redis正常命令处理有太多影响。

AOF数据持久化

AOF持久化数据的格式是基于resp协议格式数据，如，执行 `set warrior 666`，持久化到AOF的数据文件格式如下：

*3
$3
set
$7
warrior
$3
666

星号：后面的数字代表命令有多少个参数

$号：后面的数字代表这个参数有几个字符

RDB与AOF对比

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

Redis4.0 混合持久化

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

redis.conf配置开启混合持久化：

# When loading, Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, then continues loading the AOF
# tail.
aof-use-rdb-preamble yes

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

混合持久化AOF文件结构如下：