简介

持久化是将内存中的瞬时数据，转换为存储在磁盘上的持久数据。Redis是一个将数据存储在内存中的数据库，这也是它高效率的原因之一。但是将数据存储在内存，如果遇到突发事件，可能会造成数据的丢失。所以我们需要将数据持久化，等下次redis启动时，再次将数据加载进去即可。

RDB和AOF

redis的持久化可以分为两类，一种是快照模式的RDB，一种是日志模式的AOF。

RDB

命令

save:手动保存一次数据

bgsave:手动启动后台存储，不会立刻执行。

配置

dbfilename dump.rdb:设置数据库持久话文件名称

dir:数据文件存储位置

rdbcompression yes:持久化数据是否启用压缩，默认启用。采用lzf压缩。关闭而已节省cpu时间，但是文件会巨大。

rdbchecksum yes:设置是否对rdb文件进行校验。

stop-writes-on-basave-error yes:后台存储的过程中，如果出现错误现象，是否停止保存操作，默认是开启的。

save second changes:限定时间内，key的变化数量达到指定数量，则进行持久化。second:时间 changes:变化数量

工作原理

save命令会将数据记录到 .rdb的文件当中，当下次redis启动时会自动加载这个文件。

因为redis是单线程的，所以当我们执行一个命令的时候，其他命令只能是阻塞状态。因为磁盘的IO是很慢的，在数据量大的情况下我们使用save指令来持久化数据时，可能会造成大量的其他命令造成阻塞，直到整个RDB完毕才会顺序执行其他命令。所以生产环境不会使用save命令。

解决方案

将RDB的过程放到后台执行，不会和其他命令一同放入“任务队列”中。

bgsave:以后台方式进行保存操作，但是不是立刻执行。

当我们执行bgsave命令时，redis会使用它的fork函数启动一个子进程来进行数据的持久化。bgsave是针对save命令阻塞问题进行的优化，建议关于RDB的操作。都使用bgsave

优缺点

• 缺点

• RDB是一个紧凑压缩的二进制文件，存储效率高

• RDB内存储的是redis某一个时间点的数据快照，非常适合数据备份，全量复制等场景。

• RDB恢复数据要比AOF快很多。

• 应用：服务器中每X小时，执行一次bgsave 并且将备份文件拷贝到远程机器，用于灾难恢复。

• 优点

• RDB无论是使用执行指令还是使用配置，都无法做到实时持久化，具有可能丢失一部分数据的可能性。

• bgsave执行每次都要创建一个新子进程，会牺牲一些性能，浪费一些内存。

• Redis各个版本中的RDB文件格式未统一，可能存在不兼容的情况。

AOF

AOF（append only file）以独立的日志方式记录每次操作影响数据的命令，重启时再重新执行一遍AOF文件中的命令以达到恢复数据的效果。与RDB相比可以描述为”该记录数据为记录数据产生的过程“

AOF解决了持久化的实时性，是主流的方式。

工作过程

在使用AOF时，redis会将影响数据的命令首先记录到一个缓存区域，当到达条件时写入到日志文件当中。

AOF写策略

• always

  每执行一次影响数据命令，就同步到日志文件当中，数据零误差，性能地下。当你的执行命令很快的时候，需要不停的进行io操作，所以这个不常用。

• everysec

  每秒将缓存区中的执行同步到日志文件当中，数据准确性高，性能较高。在系统宕机时，最坏会丢失1秒的数据。这个也是默认的配置。

• no

  系统控制，由操作系统控制每次同步到日志文件的的时间，过程不可控制。

配置

• 开启AOF

  • appendonly yes|no:开启AOF 功能，默认为不开启。

• 配置策略

  • appendfsync:上边三种策略

• 配置自动重写

  • auto-aof-rewrite-min-size:当当前的AOF文件尺寸达到这个值，则进行重写 aof_current_zie>auto-aof-rewrite-min-size

  • auto-aof-rewrite-percentage:当当前的AOF文件尺寸增长的百分比达到这个值，则重写

  	aof_current_size-aof_base_size/aof_base_size>auto-aof-rewrite-percentage
  

AOF重写

随着命令不断的写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF重写是将Redis内部的数据转化为写命令同步到新AOF文件的过程，简单言就是将若干数据转换为命令存储到AOF文件中。

作用

• 降低磁盘占用

• 提高持久化效率，降低写时间。

• 提高恢复效率

AOF规则

• 超时的数据不会再同步到AOF文件当中。

• 忽略无效指令，重写时使用内部数据直接生成。

• 合并同一条数据修改的命令 例如 lpush list1 1,lpush list1 2,lpush list1 3---->>> lpush list1 1 2 3。为了防止数据量过大，对客户端缓冲造成溢出，对于list,set,hash,zset最大只可以一次写入64个数据。

命令

• bgrewriteaof:手动重写,后台重写AOF，当我们执行这个命令时，redis会调用fork函数创建子进程进行，将数据转换为命令覆盖AOF文件。

AOF和RDB区别

AOF和RDB的选择

• 对数据非常敏感，建议使用AOF方案，因为持久化策略使用everysecond，每秒存储一次。该策略在性能上仍然可以保持很好的效果，最坏的情况也仅仅丢失1秒的数据。

• 数据呈现阶段有效性，建议使用RDB方案，数据可以良好做到阶段内无丢失（该阶段值运维手工维护的阶段），且恢复速度快，阶段点数据使用RDB。

• 如果不能承受分钟以内的数据丢失，对业务数据非常敏感，则使用AOF

• 如果能承受分钟以内的数据丢失，且追求大数据集的快速恢复，选用RDB

• 灾难恢复选择RDB

• 双保险策略，同时开启RDB和AOF。重启后，Redis会首先使用AOF恢复数据，降低数据丢失的量。