Redis 持久化（RDB 和AOF）（四）

1. 持久化简介

1.1 什么是持久化

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

1.2 为什么要进行持久化

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

1.3 持久化过程保存什么

• 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据 ，RDB方式。
• 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程 ，AOF方式。
  

2. RDB

2.1 RDB 简介

• RDB其实就是把数据以快照的形式保存在磁盘上。什么是快照呢，你可以理解成把当前时刻的数据拍成一张照片保存下来。
• RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
• 在我们安装了redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化机制的各种配置。
• 既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存，那么就应该有一种触发机制，是实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。

2.2 RDB 三种触发方式

save 触发方式

• 命令执行

谁执行：redis 操作者（用户）
什么时间执行：即时（随时执行）
干什么事：保存数据

• 命令

save   手动执行一次保存操作

如果是第一次执行save指令，会生成一个.rdb文件，之后再执行save，都会更新.rdb文件。
当再次启动redis服务器和客户端的时候，redis 会根据.rdb 文件将数据加载内存。

• save 指令相关配置

• dbfilename 文件名
  说明：设置生成的二进制文件名，默认值为 dump.rdb
  经验：通常设置为dump-端口号.rdb
• dir
  说明：设置存储.rdb文件的路径
  经验：通常设置成存储空间较大的目录中，目录名称data
• rdbcompression yes / no
  说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩
  经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
• rdbchecksum yes / no
  说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
  经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

• save 指令工作原理

redis只支持单线程，当多个客户端向服务器发送指令时，指令按顺序执行，save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。

bgsave 触发方式

• 后台执行

谁执行：redis操作者（用户）发起指令，redis服务器控制指令执行
什么时间执行：即时（发起），redis服务器合理的时间执行
干什么事情：保存数据

• 命令

bgsave  手动启动后台保存操作，但不是立即执行

• bgsave 指令工作原理

执行该命令时，Redis会在后台异步进行快照操作，同时还可以响应客户端请求。 bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

• bgsave 指令的相关配置

• dbfilename
• dir
• rdbcompression
• rdbchecksum yes
• stop-writes-on-bgsave-error yes/no
  说明：后台存储过程中如果出现错误现象，是否停止保存操作
  经验：通常默认为开启状态

自动触发（save 配置）
自动触发是由我们的配置文件（通过设置save属性）来完成的，底层还是通过bgsave 来执行的。

• 自动执行

谁执行：redis服务器发起指令（基于条件）
什么时间执行：满足条件的时候执行
干什么事：保存数据

• 配置

save second changes 

• 作用
  满足限定时间范围内，key的变化次数达到指定数即进行持久化，然后重新计数，如果指定的时间范围内，没有那么多次变化，就重新计时计数。
• 参数
  second ：监控时间范围,单位是秒
  changes：监控key的变化量，增删改都算一次变化，get操作不算
• 位置
  在conf中进行配置
• 范例
  save 900 1 900秒内，每改变一次，就进行持久化
  save 300 10 300秒内，如果改变10次就持久化一次

• save配置 原理
  
• 注意

• save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
• save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
• save配置启动后执行的是bgsave操作

save配置的相关配置和save指令的相关配置一样。

2.3 RDB三种触发方式对比

自动触发方式底层使用的还是bgsave指令。

2.4 RDB 优缺点

• RDB 优点

• RDB是一个紧凑压缩的二进制文件，存储效率较高
• RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度要比AOF快很多
• 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

• RDB 缺点

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
• 大数据量下，IO的性能较低
• bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
• Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

3. AOF

3.1 AOF 概念

• AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
• AOF工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到.aof文件中
• AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

3.2 AOF 工作流程

当客户端向服务器发送set指令，服务器接受到这条指令，并没有马上记录，而是放到了一个临时的区域（AOF 写命令刷新缓冲区），根据AOF的触发机制来决定什么时候将命令写入AOF文件中。

3.3 AOF 三种触发机制（appendfsync）

• always(每次） 每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
• everysec（每秒） 每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置 在系统突然宕机的情况下丢失1秒内的数据
• no（系统控制） 由操作系统控制每次同步到AOF文件的周期，整体过程不可控

优缺点

3.4 AOF 相关配置

 appendonly yes|no  是否开启AOF持久化功能，默认为不开启状态

appendfsync always|everysec|no  AOF触发方式

 appendfilename filename  AOF持久化文件名，默认文件名未appendonly.aof建议配置为
 						  appendonly-端口号.aof 

 dir   AOF持久化文件保存路径，与RDB持久化文件保持一致即可 

3.5 AOF 重写

• AOF 遇到的问题

当对同一个key,连续进行多次同样的操作，AOF会记录多次，而一般我们需要的是最后一次的结果，前n-1次的操作对我们来说并没有用，记录的话，会浪费内存。

• AOF 重写

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

• AOF 重写作用

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

• AOF 重写规则

• 进程内已超时的数据不再写入文件
• 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令 ，比如当对同一个key进行set,重写之后，只保存最后一条set记录，如果删除这个key,因为这个key已经不存在了，重写之后，没有key的相关记录了。
• 对同一数据的多条写命令合并为一条命令 如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。 为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

• AOF 重写方式（手动）

bgrewriteaof

• AOF 手动重写原理

AOF 手动重写原理和bgsave 的原理类似，都是服务器调用Linux的fork函数生成一个子进程执行相关操作。

• AOF 重写方式（自动）

• 自动重写触发条件设置
  auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
• 自动重写触发比对参数（运行指令info Persistence 获取具体信息）
  aof_current_size
aof_base_size
• 自动重写触发条件(满足一个即可）
  aof_current_size > auto-aof-rewrite-min-size
  （ aof_current_size - aof_base_size ）/ aof_base_size >= auto-aof-rewrite-percentage
  也就是说，当缓冲区当前尺寸（aof_current_size）大于你设置的自动重写最小尺寸（auto-aof-rewrite-min-size ）时就重写，或者缓冲区当前尺寸（aof_current_size）与基础尺寸的差再比上基础尺寸得到的百分比当大于你自己设置的自动重写百分比（auto-aof-rewrite-percentage）

• AOF 重写原理

  非重写

  

  重写

  

3.6 AOF 优缺点

• 优点

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

• 缺点

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

4. RDB 与 AOF 区别

5. RDB 与 AOF的选择

• 对数据非常敏感，建议使用默认的AOF持久化方案
  AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。
  注意：由于AOF文件存储体积较大，且恢复速度较慢
• 数据呈现阶段有效性，建议使用RDB持久化方案
  数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案
  注意：利用RDB实现紧凑的数据持久化会使Redis降的很低
• 综合比对

1. RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
2. 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
3. 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
4. 灾难恢复选用RDB  双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

6. 参考

• 112节Redis入门到精通【黑马程序员】
• 详解Redis中两种持久化机制RDB和AOF（面试常问，工作常用）