【Redis】持久化——RDB和AOF

Redis持久化

1. 什么是持久化？

   利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

2. 为什么要持久化

   防止数据的意外丢失，确保数据安全性

Redis是一款单线程、高性能的基于内存的非关系型数据库，常用来做分布式缓存。Redis的数据全部都是存储在内存里，如果服务器突然宕机，数据就会全部丢失。Redis有持久化机制来保证服务器宕机的情况下数据不丢失。

Redis有两种持久化的方式，RDB和AOF。

• 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据（RDB）

• 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程(AOF)

当符合一定的条件的时候，redis会自动将内存中的所有数据生成一个副本并存储在硬盘上。这个过程被称为快照

【重点】

RDB	AOF(append only file)
原理是将Reids在内存中的数据库记录定时 dump到磁盘上的RDB持久化	原理是将Reids的操作日志以追加的方式写入文件
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储	AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

RDB

RDB过程

Redis会单独创建（fork）一个子进程来持久化，会先将内存中的数据写入一个临时文件中，待持久化过程结束了，再用临时文件把上次持久化的文件替换掉。整个过程中，主进程不需要进行任何IO操作，保证了主进程的性能。

Fork

fork的作用是复制一个与当前进程一样的进程。新进程为当前进程的子进程。子进程的数据和主进程一样，但是一个全新的进程。子进程读取内存中的数据，然后序列化到磁盘上。

何时触发RDB？

1. 自动触发

redis.conf文件中的配置位置SNAPSHOTTING：

#   save "" 

save 900 1
save 300 10
save 60 10000
复制代码

分别表示：“900秒内至少有一个key被改动、300秒内至少有10个key被改动、60秒内至少有10000个key被改动”时，触发一次RDB操作，自动保存数据集。

save “” 表示关闭RDB。

2. 手动触发

save或者是bgsave命令。

• save命令会阻塞，生产环境慎重。

  ​ save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。

• bgsave是在后台异步进行快照保存，同时还可以响应客户端的请求。

  

优劣势

1. 优势

• 整个redis中只有这一个备份文件，不用经常进行备份。适合大规模的数据恢复。
• 性能最大化。通过fork子进程来持久化，同时主进程又能继续处理客户端的请求。
• 相较于AOF机制，如果数据集很大，启动时数据恢复效率更高更快。

2. 劣势

• 如果服务器突然宕机，还未来得及持久化的数据将会丢失。如果对数据完整性要求较高，不建议采用这种方式。

• 由于是fork了一个与当前进程一样的进程，包含当前进程的所有数据，所以，内存中的数据增加了一倍，性能会有所影响。

AOF

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行 AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

什么是AOF机制？

• 原理

  由于是fork了一个与当前进程一样的进程，包含当前进程的所有数据，所以，内存中的数据增加了一倍，性能会有所影响。

• 存在的问题：AOF文件是追加写入命令方式实现持久化，随着redis的持续使用，AOF文件会越来越大。

• 解决方法：AOF文件的rewrite。

AOF重写原理？

AOF重写：随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。

AOF重写作用

• 降低磁盘占用量，提高磁盘利用率
• 提高持久化效率，降低持久化写时间，提高IO性能
• 降低数据恢复用时，提高数据恢复效率

Redis启动时会读取该文件重新构建数据，也就是将文件中保存的命令重新执行一遍，也就是重放。

• rewirte原理：

  AOF文件持续增长而过大时，会fork出一个新的进程来重写文件，创建出临时文件，将内存中的数据的set语句命令追加到临时文件中，然后用临时文件替换掉原来的aof文件。

  rewirte没有读取原来的AOF文件。

AOF三种触发机制？

• always: 每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低; 确保说redis里的数据一条都不丢，选择该策略.——数据零误差，性能较低
• everysec: 每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万.—— 准确性较高，性能较高
• no: 仅仅redis负责将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了.——不可控

AOF优势和劣势

• 优势

  • 更高的数据安全性和完整性。默认情况下每秒同步，最多丢失一秒的数据。
  • Fsync也是后台异步的，效率非常高。
  • 提供Redis-check-aof --fix机制，确保数据正确性。

• 劣势

  • AOF文件相较于RDB文件大得多，数据恢复效率低。
  • AOF虽然是后台异步fsync追加日志文件，无论是每秒同步还是每修改同步，都是消耗一部分性能。

RDB和AOF对比

RDB和AOF区别？

• RDB保存某一时刻内存数据集的快照。
• AOF以追加形式保存的命令日志文件。
• 通常AOF文件比RDB文件大，数据恢复效率较低。
• AOF数据安全性、完整性比RDB高，RDB丢失数据风险大。
• 根据fsync策略不同，AOF对redis的性能影响比RDB大。

	AOF	RDB
优点	【1】AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据 【2】AOF 日志文件以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。 【3】AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写. 【4】AOF 日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。	【1】RDB 会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去 【2】RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能 【3】相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
缺点	【1】对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大 【2】AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低AOF 这种较为复杂的基于命令日志 / merge / 回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式	【1】如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好 【2】RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

RDB和AOF实际项目中怎么选择？

• 如果同时开启两种持久化方式，redis重启时会采用AOF文件来恢复数据。因为AOF文件保存的数据比RDB要完整，RDB丢失数据的风险要大一些。

数据备份方案

• RDB非常适合做冷备，每次生成之后，就不会再有修改了。

1. 写crontab定时调度脚本去做数据备份
2. 每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份
3. 每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份
4. 每次copy备份的时候，都把太旧的备份给删了
5. 每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去

数据恢复方案

• 1. 如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据，最多就丢一秒的数据。
• 2. 如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复。AOF没有破损，也是可以直接基于AOF恢复的。如果AOF文件破损，那么用redis-check-aof fix方式修复破损文件。
• 3. 如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复
• 4. 当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，人为找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据。