Redis提供了RDB和AOF两种持久化方式

RDB

RDB(Redis Database)，在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里。

备份执行流程

Redis会单独创建（fork）一个子进程来进行持久化，会现将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

RDB的缺点是最后一次持久化后的数据可能丢失。

Fork

• Fork的作用是复制一个与当前进程一样的子进程。新进程的所有数据数值都和原进程一致，但是是一个新进程，并作为原进程的子进程。
• 在Linux进程中，Fork会产生一个和父进程完全相同的子进程，但子进程在此后会exec系统调用，出于效率考虑，引入了“写时复制技术”。
• 一般情况，父进程和子进程会共用同一段物理内存，只有进程空间的各段内容要发生变化时，才会将父进程的内容复制一份给子进程。

持久化流程

RDB文件

在redis.conf中配置文件名字，默认为dump.rdb。

# 配置备份文件名称
dbfilename dump.rdb
# 备份目录，即应用启动的目录
dir ./

• stop-writes-on-bgsave-error：当Redis无法写入磁盘时，进行的操作。默认yes，直接关闭Redis的写操作。
• rdbcompression：是否启用压缩，默认yes，Redis采用LZF算法进行压缩
• 假如不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但推荐启用。
• rdbchecksum：是否检查完整性，默认yes
• 在存储快照后，还可以让Redis还有CRC64算法进行数据校验，但是这样会增加大约10%的性能消耗。如果希望获取到最大的性能提升，可以关闭此功能。
• 但是推荐启用。
• save：写操作次数
• RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件。
• 默认，1分钟内修改了1万次，或5分钟内修改了10次，或15分钟内修改了1次。
• save只管保存，会阻塞其它命令，手动操作，不建议使用
• 建议：不设置save指令，或者给save传入空字符串
• bgsave
• Redis会在后台异步进行快照操作，同时也可以响应其它操作，
• 可以同lastsave命令获取最后一次成功执行快照的时间

优势

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更合适
• 节省磁盘空间
• 恢复速度更快

缺点

• Fork时，内存中的数据被克隆了一份，大致膨胀2倍，需要考虑性能
• 虽然使用了写时拷贝技术，但是如果数据庞大时，还是比较消耗性能
• 一定时间间隔做一次备份，如果Reids意外宕机等情况下，会丢失最后一次快照后的所有修改

总结

• RDB是一个非常紧凑的文件
• 在保存RDB文件时，父进程需要fork一个子进程，由子进程完成任务，父进程不需要做其它IO操作。所以RDB持久化方式可以最大化Redis性能。但当数据集较大时，比较耗时，会影响其它操作。
• 与AOF相比，在恢复大的数据集时，RDB方式会更快一些
• RDB数据丢失风险很大

AOF

AOF(Append Of File)，是以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有指令记录下来，只需要追加文件但不可以改写文件。

Redis启动时会读取该文件重新构建数据。换言之，Redis启动时会依次执行该文件中所有的指令，以完成数据的恢复工作。

流程

• 客户端的请求写命令会被追加到AOF缓冲区内
• AOF缓冲区，根据持久化策略将操作同步到磁盘AOF文件中
• AOF文件大小超过重写策略或手动重写时，会对AOF文件重写，压缩AOF文件
• Redis服务重启时，会重新加载aof文件，并执行写操作，以达到数据恢复的目的

AOF默认是不开启的，可以在redis.conf中配置文件名称，默认为appendonly.aof.

# 是否启用AOF
appendonly yes
# AOF文件名
appendfilename "appendonly.aof"

AOF文件保存路径与RDB文件路径保持一致。

AOF和RDB可以同时使用吗?

AOF和RDB同时开启，系统默认读取AOF的数据（数据不存在丢失）

AOF启动、修复、恢复

• AOF的备份机制和性能虽然和RDB不同，但是备份和回复的操作同RDB一样，都是拷贝备份文件，需要恢复时，再拷贝到Redis工作目录下，启动系统即加载
• 正常恢复
• 启用AOFredis.conf
• appendonly yes
• 将aof文件复制到备份目录下
• # 查看目录
  config get dir
• 重启Redis，会自动加载aof文件
• 异常恢复
• 启用aofredis.conf
• appendonly yes
• 备份受损aof文件
• 恢复受损的aof文件
• // 修复命令
  redis-check-aof --fix appendonly.aof
• 重启redis

AOF同步频率设置

appendfsync [always|everysec|no]

• always：始终同步，每次Redis的写入都会立刻记入日志
• 虽然性能较差，但数据完整性还是比较好
• everysec：每秒记入日志一次，如果宕机，最后一秒的数据可能丢失
• no：Redis不主动进行同步，把同步时机交给操作系统

Rewrite压缩

AOF采用文件追加方式，随着时间变化，文件会越来越大。为了避免出现这种情况，新增了重写机制，只保留可以恢复数据的最小指令集。

AOF文件过大时，会fork一条新进程来将文件重写（先写入临时文件，在重命名）。

Redis 4.0+版本后的重写是指把RDB快照，以二进制的形式附在新的AOF文件头部，作为已有的历史数据，替换掉原来的流水账操作。

何时重写？

Redis会记录上次重写时的AOF大小，默认配置是当前AOF文件大小是上次重写后大小的一倍，且文件大于64MB时触发。

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是由一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的两倍时触发）。

重写流程

1. bgrewriteaof触发重写，判断是否当前有bgsave 或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行
2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞
3. 子进程变量redis内存中数据到临时文件，客户端的写请求同时写入aof_buf和aof_write_buf，保证原AOF以及新AOF文件生成期间的新的数据修改动作不会丢失
4. 子进程写入完成后，向主进程发信号，父进程更新统计信息。同时，主进程把aof_write_buf中的数据写入到新的AOF文件。
5. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

优势

命令请求网络协议格式的命令内容客户端服务器AOF文件

• 备份机制更稳健，丢失数据概率较低
• 可读的日志文件，通过操作AOF文件，可以处理误操作

劣势

• 占用更多的磁盘空间
• 恢复备份速度慢，需要依次执行写操作命令
• 每次读写都同步的话，有一定的性能压力

RDB vs AOF

官方推荐两个都启用。

如果对数据不敏感，可以单独用RDB。但不建议单独使用AOF，可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

总结

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

• AOF持久化方式记录每次的写操作。当服务器重启时，会重新执行这些命令来恢复原始的数据。AOF命令以Redis协议追加保存每次写的操作到文件末尾
• Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于太大
• 如果你只希望你的数据在服务器运行时存在，你可以不使用任何持久化方式
• 建议同时开启两种持久化方式
• 当Redis重启时，会优先加载AOF文件，因为AOF文件相对于RDB文件保存的数据要完整
• 性能建议
• 因为RDB文件只用作第二方案，建议只在Slave上使用RDB持久化，而且只要15分钟备份一次就够了，只保留save 900 1 这条规则