Redis 持久化概览｜小册免费学

持久化分：RDB, AOF

目的

为了在Redis关闭或者意外宕机的情况下，能恢复内存中的数据。

1. 作为数据库使用，宕机之后恢复，这个效果很明显【但是没必要】
2. 虽然Redis挂掉不会影响我们的数据本身，但是 redis 重启，依然会对数据库造成瞬时压力。而且没有预热的过程。

分类

分为 RDB，AOF，下面来说说这两个的优缺点：

RDB

1. 某一个时间点的快照，是全量数据集。这就意味着数据很紧凑。
2. 恢复时间快。为什么呢？
   • RDB 是一个数据点的最终数据形态【就是不会出现同一个数据的中间转换形态】
   • RDB 内部存储的就是 Redis 的内部数据结构编码格式【不然也就不是快照】
3. 上面这个就是相对于 AOF 的优点：
   • AOF 占用空间比 RDB 大【因为可能存在多个操作记录】
   • AOF 存储的是操作记录【有点类似 WAL，只是事后日志】，需要重现操作记录才能恢复记录
4. 因为是全量数据，所以备份一次其实是很慢的，如果在备份完宕机了，就会缺失这个时间段的数据
5. 执行开销大。首先不能阻拦正常的主线程访问，所以就 fork() ，如果数据量庞大的情况下，在 fork 过程中页表复制等的开销会很大

AOF

1. 通过 fsync 策略执行，默认一秒一次，最多丢失 2s 的数据
2. 因为写入的其实是 RESP 协议命令，如果误操作了如 FLUSHALL，通过删除 AOF 文件最后的 FLUSHALL，并重启 redis 就可以恢复到之前的数据。
3. 对于相同的数据集来说，AOF 文件大小通常要大于 RDB 文件。数据恢复的比较慢

线上配置

对 no-appendfsync-on-rewrite 说明一下：

appendfsync 设置为 everysec 或 always ，也就意味着 AOF 执行 fsync() 刷盘时可能有阻塞性能问题。为了减轻这个问题，设置这个值 yes，在日志重写时，主进程不进行命令追加的刷盘操作，而只是将其放在缓冲区里，避免与重写造成DISK IO上的冲突，如果在重写过程中，redis 宕机丢失的数据就是整个重写过程数据。

未完待续。。。