面试官：Redis 持久化机制你都不了解吗？。。
引言：小 X 去面试一家杭州公司，面试官看项目有使用 Redis 做一个缓存预热，并且简历上写着经典的熟悉缓存穿透、击穿、雪崩的解决方案，于是问出了这样一个问题 Redis 持久化机制介绍一下，而小 X 连 Redis 怎么做持久化都不知道，认为 Redis 和 MySQL 的Memory 一样，面试官没蚌住...
题目
面试官：Redis 持久化机制你都不了解吗？。。
推荐解析
Redis 持久化方式有几种？
1）快照（snapshotting，RDB）一般用于全量同步
2）只追加文件（append-only file, AOF）一般用于增量同步
3）RDB 和 AOF 的混合持久化(Redis 4.0 新增)
RDB 持久化详解
RDB 持久化是什么？
通过创建 SnapShotting 快照来获取内存里面的某个时间点上的副本，利用快照可以进行方便的进行主从复制。
默认持久化方式是 RDB，默认文件 dump.rdb。
redis.conf 文件可以检查在 x 秒内如果至少有 y 个 key 发生变化就会触发命令进行持久化操作。
RDB 持久化命令
1）Save 同步保存，阻塞主进程。
2）bgsave 利用 Fork 操作，得到子进程，子进程执行，不阻塞主进程，默认用的 bgsave。
bgsave流程（重点)
1）检查子进程（检查是否存在 AOF/RDB 的子进程正在进行），如果有返回错误
2）触发持久化，调用 rdbsaveBackGroud
3）开始 fork，子进程执行 rdb 操作，同时主进程响应其他操作。
4）RDB 完成后，替换原来的旧 RDB 文件，子进程退出。
注意事项（重点）
1）Fork 操作会产生短暂的阻塞，微秒级别操作过后，不会阻塞主进程，整个过程不是完全的非阻塞。
2）RDB 由于是快照备份所有数据，而不是像 AOF 一样存写命令，因为 Redis 实例重启后恢复数据的速度可以得到保证，大数据量下相对来说 AOF 会慢很多。
3）Fork 操作原理是利用了写时复制，类似与 CopyOnWriteArrayList。
小知识-写时复制
在多线程创建时，新的进程不是在创建的时候将主进程地址空间全部复制，此时，多个进程可以同时自由读取内存，之后如果任意一个进程需要对内存进行修改操作，内存会重新复制一份提供给修改的进程单独使用，起到了隔离的作用。
AOF 持久化详解
为什么要有 AOF 持久化？
学习完 RDB 后，我们可知 RDB 持久化的方式，假如在 X 秒内没有达到 Y 个 key 修改，此时 Redis 实例挂了，就会导致多数据的丢失，而 AOF 可以做到更好的实时性。
AOF 持久化是什么？
Redis6.0 版本以前，AOF 持久化没有被默认开启，6.0 以后默认开启。
开启 AOF 持久化后，每次修改 Redis 中的数据，就会将该次命令写入 AOF 缓冲区（Server.aof_buf)，然后再写入到 AOF 文件中（此时还在系统内核缓存区未同步到磁盘），最后根据持久化方式(fsync策略)的配置，决定了刷盘的时机。
默认文件名：appendonly.aof。
AOF 持久化流程
1）append：写命令追加到 AOF 缓冲区。
2）write（系统调用）：AOF 缓冲区写入 AOF 文件，此时数据到达系统内核缓冲区（非磁盘）
3）根据刷盘策略(fsync策略)进行同步机制，此时会阻塞直到写入磁盘完成。
4）文件重写机制，AOF 文件变大，定期会对 AOF 做重写，一个参数是超过 X MB，一个参数是百分比（相对于上次重写文件大小）。
5）重启加载，检验和机制（CRC64循环冗余校验)
刷盘策略
1）always，每次 write 系统调用后，立刻进行同步机制，性能低，安全高
2）everysec（推荐）：调用 write 函数后返回，后台线程每秒钟调用 fsync 函数同步 AOF。
3）no：由操作系统决定同步时机，一般 Linux 为 30 秒。
持久化恢复数据流程
1）先检查是否存在 AOF，存在加载 AOF，利用校验和（CRC64)检查修改情况，无异常后成功恢复。
2）不存在 AOF，检查是否存在 RDB，存在 RDB，利用 RDB 进行恢复。
3）不存在 RDB，启动失败。
RDB 和 AOF 优缺点对比
RDB 优点
1）存储二进制压缩数据，文件小，适合数据备份灾难恢复。
2）RDB 恢复数据，直接解析即可还原数据，速度快，适用大数据量。
RDB 缺点
1）实时性差。
2）bgsave 对机器的 CPU 和内存产生影响。
3）RDB 新老版本的兼容性差。
4）可读性差，二进制压缩数据。
AOF 优点
1）实时性高
2）命令比较轻量级，丢失数据少
3）可读性强，存放的是写命令，可以在没有 AOF 刷盘时，取消某些操作。
AOF 缺点
1）大数据量时，恢复比较慢
2）AOF 重写期间会使用大量内存，可能会有安全问题，需要人工控制参数和具体的流程。
其他补充
鱼聪明 AI 的回答：
鱼聪明 AI 地址：https://www.yucongming.com/
Redis是一种内存数据库，为了保证数据持久化，Redis提供了两种持久化方式：RDB持久化和AOF持久化。下面对这两种持久化方式进行详细介绍，并对它们的优缺点进行比较。
RDB持久化：
RDB持久化是将Redis在内存中的数据以二进制形式快照保存到磁盘上。它是通过fork一个子进程来完成持久化操作，可以在指定的时间间隔内自动执行持久化操作，也可以手动执行。 RDB持久化的优点是快速、紧凑和可恢复性好。由于是将整个数据集保存到磁盘，所以恢复数据时非常快速。同时，RDB文件是紧凑的二进制文件，占用的磁盘空间相对较小。 RDB持久化的缺点是可能会丢失最后一次持久化之后的数据，因为它是定期执行的。此外，如果数据集较大，fork子进程可能会导致系统短暂的停顿。
AOF持久化是将Redis的写操作以追加的方式记录到一个日志文件中。通过重放日志文件中的写操作，可以恢复数据集的状态。 AOF持久化的优点是数据完整性好和可读性强。由于是记录每个写操作，所以数据完整性较好。同时，AOF日志文件是文本文件，可以直接查看和修改。 AOF持久化的缺点是文件体积相对较大，恢复数据的速度可能较慢。由于是记录每个写操作，所以AOF日志文件相对较大。同时，恢复数据时需要重放所有写操作，可能会比RDB持久化慢。
两者的优缺点对比如下：
RDB持久化适合数据备份和全量恢复，文件体积小、恢复速度快，但可能会丢失最后一次持久化之后的数据。 AOF持久化适合数据完整性要求高的场景，文件体积大、恢复速度相对慢，但数据完整性好。
在实际应用中，可以根据业务需求和数据重要性来选择适合的持久化方式，或者结合使用两种持久化方式，以提高数据的安全性和可恢复性。
欢迎交流
本篇文章主打用简练的语言去做一个概括，如果想要对某个地方进行深究可以网上进行学习，有疑问的小伙伴欢迎在评论区进行回答，在回答问题的时候去结合 408 的基础会更好，能够了解某个点的底层是非常不错的，文末附上三个问题，检验学习成果。
1）在使用AOF持久化时，AOF日志文件可能会变得很大，有哪些方式可以控制AOF文件的大小并进行压缩？
2）RDB持久化和AOF持久化两种方式在性能方面有何不同？哪种方式更适合在高负载场景下使用？
3）如何进行Redis的数据恢复操作？在RDB持久化和AOF持久化中，哪种方式更适合用于数据恢复？
点燃求职热情！每周持续更新，海量面试题等你挑战！赶紧关注面试鸭公众号，轻松备战春招和暑期实习！
往期推荐