【redis】redis持久化

一、简介

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

持久化发生了什么？

Redis 作为一个 "内存数据库"， 要做的关于持久化的事情要经历几件事情。

通常来说，从客户端发起请求开始，到服务器真实地写入磁盘，需要经过如下步骤：

1. 客户端向数据库 发送写命令 (数据在客户端的内存中)

2. 数据库 接收 到客户端的 写请求 (数据在服务器的内存中)

3. 数据库 调用系统 API 将数据写入磁盘 (数据在内核缓冲区中)

4. 操作系统将 写缓冲区 传输到 磁盘控控制器 (数据在磁盘缓存中)

5. 操作系统的磁盘控制器将数据 写入实际的物理媒介 中 (数据在磁盘中)

注意: 上面的过程其实是极度精简的，在实际的操作系统中，缓存和缓冲区 会比这 多得多...

在 上述步骤 3 成功返回之后，我们就认为成功了。即使进程崩溃，操作系统仍然会帮助我们把数据正确地写入磁盘。

二、Redis 中的两种持久化方式

方式一：RDB(快照)

1.手动执行持久化数据命令:

save命令:save操作在Redis主线程中工作，因此会阻塞其他请求操作，应该避免使用。

bgsave命令:bgSave则是调用Fork,产生子进程，父进程继续处理请求。子进程将数据写入临时文件，并在写完后，替换原有的.rdb文件。不阻塞其他请求进程。

 快照持久化 可以完全交给子进程 来处理，父进程 则继续 处理客户端请求。子进程 做数据持久化，它 不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对 内存数据结构进行不间断的修改。

这个时候就会使用操作系统的 COW 机制来进行 数据段页面 的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复 制一份分离出来，然后 对这个复制的页面进行修改。这时 子进程 相应的页面是 没有变化的，还是进程产生时那一瞬间的数据。

子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化 叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。

2.根据你所配置的配置文件 的 策略，达到策略的某些条件时来自动持久化数据

这是配置文件默认的策略，他们之间的关系是或，每隔900秒，在这期间变化了至少一个键值，做快照。或者每三百秒，变化了十个键值做快照。或者每六十秒，变化了至少一万个键值，做快照。

3.优势

1. RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
2. 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

4.劣势

RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

方式二：AOF

快照不是很持久。如果运行 Redis 的计算机停止运行，电源线出现故障或者您 kill -9 的实例意外发生，则写入 Redis 的最新数据将丢失。尽管这对于某些应用程序可能不是什么大问题，但有些使用案例具有充分的耐用性，在这些情况下，快照并不是可行的选择。

1.AOF(Append Only File - 仅追加文件) 

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

2.AOF 重写

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

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

3.优点

1. AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
2. AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
3. AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
4. AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

4.缺点

1. 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
3. 以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

三、数据恢复

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据（隔一段时间备份一次）。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多（快照恢复快），这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是 自持久化开始到持久化结束 的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。