美团面试原题：利用Redis的持久化机制有效避免数据丢失：技巧与最佳实践

Redis持久化机制的重要性

Redis的持久化机制是后端面试中一个极为常见的知识点，值得深入学习和掌握。即便你不是在为面试做准备，这些知识在日常开发中也会频繁用到。

缓存与数据持久化

在使用缓存时，我们常常需要将内存中的数据持久化，以便在机器重启或故障时能够恢复数据，或进行数据同步（例如，Redis集群的主从节点通过RDB文件进行数据同步）。

Redis与Memcached的一个显著区别在于，Redis支持持久化，并提供三种持久化方式：

快照（Snapshotting，RDB）
只追加文件（Append-Only File，AOF）
RDB与AOF的混合持久化（新增于Redis 4.0）

官方文档链接：Redis持久化

RDB持久化详解

RDB持久化的定义

Redis通过创建快照来获取内存中数据在某个特定时间点的副本。创建快照后，可以将其备份并复制到其他服务器，进而构建数据相同的服务器副本（适用于Redis的主从结构），这主要用于提高Redis的性能。

快照持久化是Redis默认的持久化方式。以下是redis.conf配置文件中的默认设置：

save 900 1          # 在900秒内，如果至少有1个key发生变化，Redis将自动触发bgsave命令创建快照。
save 300 10         # 在300秒内，如果至少有10个key发生变化，Redis将自动触发bgsave命令创建快照。
save 60 10000       # 在60秒内，如果至少有10000个key发生变化，Redis将自动触发bgsave命令创建快照。

RDB快照是否会阻塞主线程？

Redis提供两种命令来生成RDB快照文件：

save: 同步保存操作，会阻塞Redis的主线程；
bgsave: 通过创建子进程来执行，不会阻塞Redis的主线程，这是默认选项。

AOF持久化详解

AOF持久化的定义

相较于快照持久化，AOF（Append-Only File）持久化的实时性更强。Redis在默认情况下并未开启AOF持久化（在Redis 6.0及之后版本中，默认已开启），可以通过appendonly参数进行配置：

appendonly yes

开启AOF持久化后，每次执行更改Redis中数据的命令，Redis会将该命令写入AOF缓冲区server.aof_buf，然后再写入AOF文件（此时仍在系统内核缓存区中，尚未同步到磁盘）。

只有在数据同步到磁盘后，才算持久化保存，否则存在数据丢失的风险，例如：如果系统内核缓存区的数据尚未同步，而磁盘故障发生，则这部分数据将丢失。

AOF文件的保存位置与RDB文件相同，通过dir参数设置，默认文件名为appendonly.aof。

AOF工作流程

AOF持久化功能的基本流程如下：

命令追加（Append）：所有写命令会被追加至AOF缓冲区。
文件写入（Write）：将AOF缓冲区的数据写入AOF文件中。此时调用write函数（系统调用），并将数据写入系统内核缓冲区后直接返回（延迟写）。注意，此时并未同步至磁盘。
文件同步（Fsync）：根据持久化方式（fsync策略），AOF缓冲区向硬盘进行同步操作。此步骤需要调用fsync函数（系统调用），确保磁盘写入操作完成后返回，确保数据持久化。
文件重写（Rewrite）：随着AOF文件逐渐增大，需要定期对AOF文件进行重写，以达到压缩目的。
重启加载（Load）：当Redis重启时，可以加载AOF文件进行数据恢复。