16. Redis 持久化机制-RDB与AOF

Redis 是一款基于内存的Nosql 数据库, 提供高速存取服务，通常会被用做高速缓存中间件。但是，Redis 除了将数据库存储在内存，也可以将数据存储在磁盘。 Redis 提供了两种持久化方式: RDB 和 AOF. 默认情况下只开启了RDB方式， 官方建议混合使用两种方式.

1. RDB 方式

RDB 持久化方式能搞在指定的时间间隔内对内存中的数据进行数据快照, 即持久化到磁盘. 默认开启

1.1 RDB 的优点

• RDB 保存的是某个时间点的数据集, 非常适合数据集的备份和恢复.
• RDB 时一个单一的文件, 文件较小，便于传输，适合灾备和恢复
• RDB 在保存RDB文件时，父进程会fork一个子进程，其它工作由子进程来做，父进程不需要再有IO, 所以RDB不会影响Redsis 性能.
• RDB 在数据恢复时会更快

1.2 RDB 的缺点

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

1.3 RDB的工作原理

当Redis 需要保存RDB文件时, 服务器会执行以下操作:

1. Redis 创建fork 子进程, 同时拥有父子进程。父进程处理客户端命令， 子进程生成RDB文件
2. 子进程将数据集写入一个临时的RDB文件中
3. 当子进程完成新的RDB文件写入时, Redis会用新的RDB文件替换原来的RDB文件，并删除旧的RDB文件.

1.4 数据快照

• 默认情况下, Redis会将数据库数据快照dump.rdb的二进制文件中，文件名可以自定义.
• 默认情况下, Redis 会根据Redis 的配置条件， 当满足N 秒中至少有M 个改动条件时, 自动触发一次快照操作
• 可以通过sav 或者 bgsave命令手工让redicaozuos 进行数据集保存操作.

save N M

2. AOF 方式

AOF 持久化方式能记录Redis的每次操作命令, 当服务器重启时，会重新执行所有命令，进行数据恢复. 默认未开启

2.1 AOF 的优点

• AOF 文件是一个只进行追加的日志文件, 所以写入性能会很快。当遇到某些原因（磁盘已满，突然宕机）时，可以使用redis-check-aof工具来修复
• AOF 可以设置不同的fsyn策略, 当使用默认的每秒一次时, 也不会怎样影响Redis 性能。fsync 时由后台线程进行处理的，主线程会尽力处理客户端请求
• 当发生故障时，AOF可以最多丢失1秒的数据，数据完整性比RDB更高
• AOF 文件时以Redis 协议的格式保存的，因此AOF文件可以读懂，也可以进行解析
• 当AOF文件体积过大时, Redis 会自动对AOF文件进行重写.重写后的AOF文件包含了回复当前数据集所需的最小命令集合。整个重写操作时绝对安全的，因为Redis 在创建新的文件时，会继续将命令追加到现有的AOF文件中，当新文件完成后，才会将旧AOF文件切换到新的AOF文件.

2.2 AOF 的缺点

• AOF 文件的体积会大于RDB的文件的体积
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）

2.3 AOF的重写原理

当AOF文件体积过大时, Redis 会对AOF 文件进行重写, 重写也利用了Redis的写时复制机制(copy-on-write),执行步骤：

1. Redis fork子进程, 父子进程同时工作, 父进程接收客户端骑牛，子进程重写AOF文件
2. 子进程将旧的AOF文件的内容写如临时文件
3. 主进程接收到的新的AOF命令，会将新的AOF命令存储到一个内存缓存中，同时追加到现有AOF文件的末尾。以保证在重写的过程中突然发生宕机，现有的AOF文件也时完整的
4. 当子进程完成重写工作时，子进程会给父进程发送一个信号，父进程接收到信号之后， 会将缓存中所有的数据追加到新的AOF文件的末尾。
5. Redis 进行原子行替换AOF文件，即删除旧AOF文件，将新的AOF文件重命名

2.4 AOF 的fsync策略

Redis 提供了三种将数据fsync到磁盘的策略, 默认为每秒执行一次. 这也是官方推荐的方式, 这种策略可以兼顾安全性和Redis 响应性能。当发生故障时，最多只丢失1秒的数据.

• always: 每次新命令追加AOF文件时就执行一次fsync， 安全性最高，但是性能最慢
• everysec： 每秒执行一次，性能足够快，足以媲美RDB方式。默认方式，也是官方推荐的方式
• no: 从不fsync， 性能最快，足以媲美RDB方式，但是最不安全.

2.5 AOF 文件损坏

如果当Redis 正在对AOF文件进行写入时突然宕机，那么可能会导致AOF文件损坏。 当Redis重启时，会检查AOF文件，当AOF文件是损坏文件时，Redis 会拒绝载入AO文件， 从而保证数据的一致性不会被破坏。 当发生这种情况时, 可以用以下方式来修复AOF文件.

1. 为现有的AOF文件创建一个备份
2. 使用Redis 自带的命令 redis-check-aof 来对AOF文件进行修复.
3. 适应diff -u 命令对比修复后的AOF文件和原始的AOF备份文件，查看两个文件的不同之处，查看修复的内容
4. 重启Redis 服务器。

3. Redis 数据容灾备份

对于数据库而言，定时备份是非常有必要的，对于Redis的备份而言推荐备份RDB文件. 因为Redis 对于RDB文件的复制是非常友好的， 可以在运行时对RDB文件进行复制. 一旦RDB文件被创建，就不会进行任何修改。当服务器需要创建一个新的RDB文件时，它会先将文件的内容保存在一个临时文件内，当临时文件写如完毕后，程序才使用rename原子地用临时文件替换原来的RDB文件. 备份策略:

• 创建定时任务(cron job), 每小时将RDB文件备份到一个文件夹, 并且每天将REB备份到另一个文件夹。
• 快照名称应带有相应的时间信息, 可以通过文件名等删除过期数据.
• 每天一次，将RDB文件备份到数据中心或其它服务器上，以实现容灾备份.