Redis持久化：RDB（快照）和AOF（写命令）

前言：

Redis之所以速度这么快，是因为Redis是基于内存的数据库，进行读写操作时，redis都会现在内存中完成，然后定时的刷新到磁盘中去，RDB和AOF就是两种持久化内存中数据的方式。笼统来讲，RDB可以将某一时刻的所有数据写入硬盘中，相当于复制了一份数据；而AOF会在redis执行写命令时，将被执行的写命令复制到磁盘中，恢复数据的时候，redis会在原有基础上依次执行AOF文件中的写命令，从而恢复数据。下面会详细的讲下RDB和AOF的原理和机制。

什么是持久化:         

        持久化，指将数据存储到可永久保存的设备中。
        例如，将内存中的数据存储到可永久保存的硬盘中。  

        Redis 是一个键值对数据库服务器。基于内存存储数据，它常被用做缓存数据库，用来替代         memcached     

为什么要做持久化:

1. Redis 基于内存存储，内存掉电后数据会丢失
2. 内存比硬盘贵得多，所以需要将一些不能丢失的数据持久化到硬盘上
3.     甚至，一些特别重要的数据，是需要存到 MySQL 的。

Redis 有两种持久化方式，一种是 RDB、一种是 AOF。 RDB：就是对 Redis 中的数据进行周期性的持久化。类似于快照 AOF：就是对每一条写入、删除记录做日志，Redis 重启的时候，重启 AOF 日志重构数据集 如果同时使用两种，Redis 就会优先实现 AOF，因为数据更加完整

两种持久化方式的使用场景

Redis 是内存型数据库，一般来用作缓存。保存在内存的数据有一个特点， 就是断电消失，因此一旦 Redis 宕机了，重启以后保存在 Redis 里面的数据就会消失， 此时服务器在 Redis 里面获取不到缓存，就会让缓存无法命中，导致缓存雪崩，请求直接打到 MySQL 上最后让 MySQL 也宕机。 因此我们需要 Redis 持久化来做灾难恢复、数据恢复还有数据库高可用。

RDB 持久化

RDB：Redis database 的简称。一看这个，你就应该能猜到，这是 Redis 的默认持久化方式。

RDB 中持久化生成的是一个经过压缩的二进制文件。

RDB 持久化时机：

1. 在客户端执行 SAVE 或者 BGSAVE
2. 根据配置规则自动快照（稍后会讲到）
3. 执行 FLUSHALL 命令
4. 执行复制（replication）

RDB 持久化步骤：

1. fork 复制出一个父进程的副本子进程
2. 子进程将内存中的数据写入到硬盘中的临时文件
3. 将临时文件替换旧的 rdb 文件

自动间隔保存（配置规则）：

save 900 1     # 每900秒检查一次，如果有1条数据修改了，那么执行 rdb
save 300 10    # 每300秒检查一次，如果有10条数据修改了，那么执行 rdb
save 60 10000  # 每60秒检查一次，如果有10000条数据修改了，那么执行 rdb

RDB 文件还原

服务器启动时，会直接载入 RDB 文件。
但是如果 AOF 文件存在，则会载入 AOF 文件。

AOF 持久化

AOF 是 Append Only File 的简称。

AOF 通过保存客户端传过来的写命令来记录数据库的状态。

- AOF配置：

配置在redis.conf文件中，通过将appendonly:yes打开创建AOF文件功能。

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

含义：
appendonly：是否打开 AOF 持久化功能
appendfilename：AOF 文件名称
appendfsync：同步频率
对于同步频率有三种方式

• always：redis执行每个写命令时，都同步写入硬盘，这样会严重降低redis性能；
• everysec：每秒执行一次，显示的在这一秒内执行的写命令同步到硬盘；
• no：不同步到硬盘（让操作系统来决定何时进行同步）。

AOF 持久化的步骤

主进程进行如文章末尾所示的三个步骤：

1. 命令追加
2. 文件写入
3. 文件同步

AOF 重写的时机

1. 配置：

# 当前 AOF 文件超过上次重写时的 AOF 文件大小的百分之多少时再次进行重写
# 如果之前没有冲写过，则以启动时的 AOF 文件大小为依据。
auto-aof-rewrite-percentage 100
# 允许重写的最小值
auto-aof-rewrite-min-size 64mb

1. 主动执行 BGREWRITEAOF 命令触发 AOF 重写。

- AOF文件生成机制：

生成过程包括三个步骤：命令追加、文件写入、文件同步。
redis打开AOF持久化功能之后，redis在执行完一个写命令后，把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾，此时缓冲区的记录还没有写到appendonly.aof文件中。然后，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程，只有经过了文件的同步过程，写命令才真正的被保存到了AOF文件中。appendfsync 就是配置同步的频率的选项。

- AOF重写：

redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，当AOF文件体积过大时，数据恢复的时间也是非常长的，因此，redis提供了重写或者说压缩AOF文件的功能。比如对key1初始值是0，调用incr命,100次，key1的值变为100，那么其实直接一句set key1 100 就可以顶之前的100局调用，AOF重写功能就是干这个事情的。
重写时，可以调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。

auto-aof-rewrite-percentage 100 #当前AOF文件大小和上一次重写时AOF文件大小的比值
auto-aof-rewrite-min-size 64mb  #文件的最小体积

重写步骤:
1.创建子进程进行AOF重写
2.将客户端的写命令追加到AOF重写缓冲区
3.子进程完成AOF重写工作后，会向父进程发送一个信号
4.父进程接收到信号后，将AOF重写缓冲区的所有内容写入到新AOF文件中
5.对新的AOF文件进行改名，原子的覆盖现有的AOF文件

AOF 写入与重写过程图：

- RDB快照持久化数据的优缺点：

优点：
1.采用子线程创建RDB文件，不会对redis服务器性能造成大的影响；
2.快照生成的RDB文件是一种压缩的二进制文件，可以方便的在网络中传输和保存。通过RDB文件，可以方便的将redis数据恢复到某一历史时刻，可以提高数据安全性，避免宕机等意外对数据的影响。

3.保存多份完整备份，对 IO 影响小，适合做冷备，并且在宕机后恢复更加快

缺点：
1.在redis文件在时间点A生成，之后产生了新数据，还未到达另一次生成RDB文件的条件，redis服务器崩溃了，那么在时间点A之后的数据会丢失掉，数据一致性不是完美的好，如果可以接受这部分丢失的数据，可以用生成RDB的方式；
2.快照持久化方法通过调用fork()方法创建子线程。当redis内存的数据量比较大时，创建子线程和生成RDB文件会占用大量的系统资源和处理时间，对 redis处理正常的客户端请求造成较大影响。

3.一般快照文件生成的间隙在 5min，一旦宕机，就会丢失 5min 的数据。同时如果快照文件过大，会让服务暂停几毫秒甚至一秒

- AOF持久化数据的优缺点：

优点：
1.优点：一般 1s 同步一次，最多丢失 1s 的数据。同步日志是使用 append-only 模式，写入快，并且日志文件不易破损，尾部破损也容易恢复。并且 AOF 文件大小不会影响性能。
2.如果AOF文件有错误，比如在写AOF文件时redis崩溃了，redis提供了多种恢复AOF文件的方式，例如使用redis-check-aof工具修正AOF文件（一般都是最后一条写命令有问题，可以手动取出最后一条写命令）；
3.AOF文件可读性交强，也可手动操作写命令。
缺点：
1.AOF 日志一般比 RDB 文件大，同时以前 AOF出过 Bug导致数据没有完整的恢复。
2.redis负载较高时，RDB文件比AOF文件具有更好的性能；
3.RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，因此从理论上来说，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些情况下，AOF的确也存在一些bug，比如使用阻塞命令时，这些bug的场景RDB是不存在的。

一般我们选择的话，不能单单使用 RBD 会丢失许多数据，也不能单单使用 AOF 恢复速度比较慢，也容易有 bug。推荐同时使用，AOF 保证数据不丢失，RBD 做冷备，一旦 AOF 丢失或者不可用的时候可以用于快速恢复。