redis持久化

RDB

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。

Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。

可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件

Save是同步的，会阻塞

bgSave是异步的

Rdb缺陷：在执行rdb前，宕机会丢数据

AOF

修改配置文件来打开 AOF 功能：# appendonly yes

每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾。

这样的话， 当 Redis 重新启动时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

1 appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。

2 appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。

3 appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

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

AOF重写

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

例如多个incr命令

incr readcount

incr readcount

会重写为 set readcount 2

1 # auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大

2 # auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写。

总结：

Rdb因为是二进制，所以恢复快，但是容易丢数据

Aof不丢数据，存储的指令顺序，可读行强。只记录更新插入指令。但是恢复慢

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

通过如下配置可以开启混合持久化(必须先开启aof)：

1 # aof‐use‐rdb‐preamble yes

混合持久化工作流程：

如果开启了混合持久化，就会在AOF重写的时候，先对此刻之前的内存数据生成二进制快照，然后追加aof修改内存数据的命令，放到一个文件中，刚开始不叫appendonly.aof，等追加命令完成后再改为appendonly.aof,替换掉老的文件。于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的AOF 全量文件重放，因此重启效率大幅得到提升。

Redis数据备份策略：

1. 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48

小时的备份

2. 每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份

3. 每次copy备份的时候，都把太旧的备份给删了

4. 每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏。