Redis持久化

1. 什么是持久化？

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

2. 为什么要持久化

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

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

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

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

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

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

【重点】

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大。

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里面去，就可以恢复到某一个小时的数据。