Redis系列五：持久化

持久化简介

场景
在写文档的时候，很多人都会遇到断电或者电脑意外死机的状况，等重启电脑后电脑一般会有个备份文件，打开备份文件就可以恢复到文档最近的编辑状态。这是MS为我们做的持久化。

什么是持久化

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

为什么要进行持久化

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

持久化过程保存什么

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

虚拟机的快照为第一种方式，在写文档的时候我们撤销操作，返回上一步为第二种方式。

RDB

RDB采用的存储策略是以快照形式存储数据。

RDB启动方式————save指令

• 命令

save

• 作用
  手动执行一次保存操作

save指令的相关配置

• dbfilename dump.rdb
  设置保存的本地数据库名，默认为dump.rdb。通常设置为dump-端口号.rdb

• dir
  设置.rdb文件的路径，一般户放在较大的存储空间中，目录名称设置为data。

• rdbcompression yes
  设置存储到本地时是否压缩，默认为yes.可以节省空间

• rdbchecksum yes
  设置是否进行RDB校验，默认为yes，会增加读写时间消耗。

注意：redis是单线程的，save指令会阻塞当前Redis服务器，知道当前RDB过程完成为止，可能会造成长时间的阻塞，线上环境不建议使用。如何避免这个问题？采用后台执行save指令

RDB启动方式————bgsave指令

• 命令

bgsave

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

注意：bgsave命令是最save阻塞问题的优化。redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用

bgsave指令相关配置

• dbfilename dump-端口号.rdb
• dir
• rdbcompression yes
• rdbchecksum yes
• stop-writes-on-bgsave-error yes
  后台存储过程中如果出现错误现象，是否停止保存操作。通常默认为开启状态

反复执行保存指令，忘记了怎么办？

RGB启动方式————save配置

• 配置

save second changes

• 作用
  满足限定时间范围内key的变化数量达到指定数量时进行持久化
• 参数
  • second:监控时间范围
  • changes：监控key的变化量
• 位置
  在conf文件中进行配置
• 示例

save 900 1
save 300 10
save 60  10000

注意：

1. save配置根据实际业务情况进行设置，频度过高或者过低都会出现性能问题
2. second和changes设置通常具有互补关系，尽量不要设置成包含关系。例如1s1次和100s100次，就没有太大意义
3. save配置后执行的是bgsave操作

RDB三种启动方式对比

save配置和bgsave指令是同一种性质，因此在此比较save和bgsave指令

RDB的优缺点

RDB优点

• RDB存储效率高，它是一个紧凑压缩的二进制文件
• 基于某个时间点的数据快照，非常适用于数据备份，全量复制等场景
• RDB恢复数据的速度比AOF快很多

RDB缺点

• 无法实时持久化，会丢数据
• bgsave每次运行要执行fork操作创建子进程，要牺牲性能
• Redis各个版本中RDB文件格式未统一，可能出现各版本服务之间的数据格式无法兼容

AOF

AOF采用的过程日志的方式存储数据。

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

AOF写数据的过程

先将写命令刷新在缓存区中，当满足条件后将命令同步到AOF文件中。

AOF写数据的三种策略

• always
  每次写入操作均同步到AOF文件中，数据零误差，性能较低。

• everysec

  每秒将缓冲区指令同步到AOF文件中，数据准确性较高，性能较高。推荐，也是默认配置
  宕机的时候回丢失1s内的数据

• no
  由操作系统控制，过程不可控。

AOF功能开启

• 配置

appendonly yes|no

• 作用
  是否开启AOF持久化功能，默认不开启，开始时优先级高于RBD
• 配置

appendfsync always|everysec|no

• 作用
  AOF写策略

AOF相关配置

• 配置

appendfilename filename

• 作用
  AOF持久化文件名，默认为appendonly.aof，建议为appendonly-端口号.aof
• 配置

dir

• 作用
  AOF持久化保存路径，与RDB文件同位置即可。

AOF写数据时遇到的问题

如果连续执行如下指令

在备份恢复的时候，会执行三次set name操作，但最终的结果只是得到ww，前两次的set操作是无效的。

AOF重写

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

AOF重写作用

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

AOF重写规则

• 进程内已超时的数据不再写入文件
• 忽略无效指令，只保留最终数据的写入命令
• 对同一数据的多写命令合并为一条命令

lpush list1 a、lpush alist1 b、 lpush alist c可以转化为 lpush list1 a b c

AOF重写方式

• 手动重写

bgrewriteaof

• 自动重写

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

RDB和AOF的区别

RDB VS AOF

如何选择RDB与AOF

• 对数据非常敏感，建议使用默认的AOF方案
• 数据呈现阶段有效性，使用RDB持久化方案
• 综合对比
  • 不能承受数分钟以内的数据丢失，对数据非常敏感，使用AOF
  • 可以承受数据的部分丢失，且追求大数据集的恢复速度，选用RDB
  • 灾难恢复选用RDB