Redis深度历险(6)-持久化

1 快照（RDB）方式

快照是一种全量备份的持久化方式，默认生成的是名为dump.rbd的二进制文件；在Redis的配置文件中可以设置其触发条件，将当前的数据全量写入dump.rdb文件中，使用的是bgsave命令。

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

• 子进程执行备份命令

备份一次数据会耗费相当多的时间，bgsave命令的实质是启动一个子进程（注意Redis是单线程的，所以不能启动子线程，只可启动子进程）去执行备份的操作。

• CopyOnWrite

子进程备份时采用的是写时复制策略，即开始备份时子进程仍是对当前的二进制数据进行备份，当父进程更改了这份数据时，才将这份被更改的空间先复制出一份副本给子进程使用，这样就避免了副本的全量复制

• 使用快照备份的缺点

有一定的触发条件，且每次都需要进行全量的复制，时间效率较低，若在没有触发bgsave命令时发生宕机则会发生数据的损失

• 使用快照备份的优点

二进制文件占用空间小，并且在Redis启动时数据读取速度快

2 增量备份（Append-Only，aof）

增量备份每隔一段时间都会记录这段时间的写入命令和删除命令然后存储在一个名为appendonly.aof的文本文件中，与快照备份相比，增量备份速度很快，并且每隔一定时间进行备份，实时性好，默认不开启该模式，需要通过

appendonly yes

来开启

• aof重写

由于appendonly.aof文件存储的是Redis命令，所以时间一久，占用的空间会很大。并且在Redis重启时需要重放的命令数量很多。此时需要aof重写，即在一段时间后将备份文件删除并且重新进行一次备份，以减少备份文件中的命令数量和大小。aof重写使用bgrewriteaof命令来实现。

• fsync命令

在向aof文件中写入备份命令时，若突然宕机则会发生写入失败，此时要使用linux提供的glibc命令。这个命令能强制将内存中的数据刷新到磁盘中，如果Redis进程实时执行这个函数，那么就不会发生写入丢失，但是由于fsync命令执行很耗费时间，所以Redis默认每秒执行一次。

appendfsync always #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec #每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no #让操作系统决定何时进行同步

• 使用增量备份的缺点

增量备份文件中存储的是写入命令，在Redis启动时重放命令的时间较长，备份文件占用空间较大

3 Redis 4.0 混合式持久化

Redis重启时很少使用RDB文件来载入数据，因为可能发生大量的数据失效情况，而采用AOF重放的方式又会耗费很长时间，所以在Redis 4.0中为了解决这个问题，开始采用混合持久化的方式，即将dump.rdb文件和appendonly.aof文件放在一起，但是aof文件只保留了rdb持久化之后的那部分命令，所以aof文件会小很多。
在Redis重启时，先加载rdb中的二进制数据，然后使用aof对后续的那部分数据进行重放。