Redis 持久化

持久化简介

Redis 的数据全部存储在内存中，如果突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制，它会将内存中的数据保存到磁盘中。

持久化的过程：

1. 客户端向数据库发送写命令（数据在客户端的内存中）
2. 数据库接收到客户端的写请求（数据在服务器的内存中）
3. 数据库调用系统 API 将数据写入磁盘（数据在内核缓冲区内）
4. 操作系统将写缓冲区传输到磁盘控制器（数据在磁盘缓存中）
5. 操作系统的磁盘控制器将数据写入实际的物理媒介中（数据在磁盘中）

如果故障仅仅涉及软件管理层面（该进程被管理员终止或程序崩溃）并且没有接触到内核，那么在步骤3成功返回之后，我们就认为成功了。

如果是停电之类的事情，那么只有在完成第五步之后，我们才认为成功了。

Redis 的两种持久化方式

方式一：RDB（快照）

快照是包含整个数据库的单个 .rdb 文件生成。
Redis 快照是最简单的 Redis 持久化模式。当满足特定条件时，它将生成数据集的时间点快照。Redis 默认配置为：

save 900 1
save 300 10
save 60 10000

其含义是，先前的快照是在 60 秒之前创建的，并且到现在至少有 10000 次写入，则将创建一个新的快照（另外两行同理）。这个条件可以有用户自己设置。

Redis 是一个单线程的程序，这意味着，Redis 不仅要响应用户的请求，还需要进行内存快照。而后者需要 Redis 必须进行 IO 操作，这会严重拖累服务器的性能。

所以 Redis 在持久化时调用 glibc 的函数 fork 创建子进程，主进程和子进程共享内存里面的代码和数据段。所以快照持久化可以完全交给子进程来处理，父进程则继续处理客户端请求。

快照持久化的方式会导致部分数据的丢失，前面说了快照的产生是有时间间隔的，也就是说如果 Redis 发生宕机，那么会丢失最后一次生成快照之后的数据。

方式二：AOF（Append Only File 仅追加文件）

它的工作方式非常简单：每次执行写操作时，都会记录该操作。假设 AOF 日志记录了自 Redis 实例创建以来的所有修改性指令序列，那么就可以通过对一个空的 Redis 实例顺序执行所有的指令，也就是重放，来恢复 Redis 的数据。

AOF 在 Redis 中默认是关闭的，如果要使用，需要开启。
appendonly no --> yes

如果 AOF 文件被破坏，可以通过 redis-check-aof --fix 进行修复。

Redis 是先执行指令在将日志存盘。和 MySQL 等存储引擎不同。

AOF 重写

Redis 在长期运行的过程中，AOF 文件会越来越长。如果实例宕机重启，重放整个 AOF 文件会非常耗时，导致长时间 Redis 无法对外提供服务。所有需要对 AOF 日志进行“瘦身”。

Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件 中。序列化完毕后再将操作期间发生的增量 AOF 日志 追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

fsync

AOF 日志是以文件的形式存在的，当程序对 AOF 日志文件进行写操作时，实际上是将内容写到了内核为文件描述符分配的一个内存缓存中，然后内核会异步将脏数据刷回到磁盘的。

我们需要借助 glibc 提供的 fsync(int fd) 函数来将指定的文件内容强制从内核缓存刷到磁盘。

Redis 提供了3种 fsync 的策略。

1. Redis 每隔 1s 左右执行一次 fsync 操作就可以了。
2. 永不 fsync，来让操作系统来决定什么时候同步磁盘，很不安全
3. 另一个是来一个指令就 fsync 一次，非常慢。

混合持久化

由于 RDB 和 AOF 都有缺点：RDB 会丢失数据，AOF 恢复数据非常耗时。
所以在 Redis 4.0 带来了一个新的持久化选项——混合持久化

将 RDB 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。

于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。