Redis持久化详解与持久化方式对比

Redis是在内存中工作，如果线上环境宕机，重启Redis后，所有缓存数据全部丢失，这时候如果只靠用户的访问进行缓存写入的方式，无疑进一步增大了线上环境的压力。针对这一类情况，Redis有自己的持久化方式。
Redis有两种持久化方式，一为RDB，一为AOF。RDB是保存数据快照，重点在数据。AOF保存命令日志，重点在命令。

RDB持久化

RDB持久化方式的启动

在文件中进行配置：

dbfilename dump.rdb 设置本地rdb文件名，默认值为dump.rdb
dir /etc/redis/ 设置.rdb文件的保存路径，也是进行数据恢复的路径。
rdbcompression yes 设置存储至本地数据库时是否压缩数据，默认为yes，采用LZF压缩算法。默认开启 如果采用no，可以节省CPU运行时间，但存储的文件会变大。
rdbchecksum yes 设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行。默认开启 如果采用no，可以节约读写时间，但是存在数据损坏的风险

save命令进行数据持久化

save命令保存数据，生成.rdb文件，保存数据快照。
注意：save指令的执行会阻塞当前Redis服务器，直到RDB过程完成为止，有可能造成长时间阻塞，线上环境不建议使用。
数据恢复：服务启动时自动恢复。

bgsave命令进行数据持久化

在手动执行bgsave命令后，后台进行保存操作，但不是立即执行（可以解决线上保存缓慢可能出现的问题）。
bgsave原理：bgsave命令发出后，Redis服务器立即返回"Background saving started"，同时调用fork函数生成子进程来创建rdb文件。

RDB配置启动后，会在满足条件时，redis自动发起指令，进行数据保存。

配置：

save second changes
满足限定范围的key的变化数量达到指定数量即进行持久化。
save配置启动后，执行的是bgsave操作。

RDB两种持久化启动方式对比

方式	save	bgsave
读写	同步	异步
阻塞客户端指令	是	否
额外内存消耗	否	是
启动新进程	是	否

RDB的优缺点

RDB优点：

• RDB是紧凑的二进制文件，存储效率较高。
• RDB内部存储的是redis在某一时间节点的数据快照，适用于数据备份，全量复制等场景。
• RDB恢复速度比AOF快。

应用：服务器固定时间执行bgsave备份，并将RDB文件拷贝进远程机器中，用于容灾恢复。
RDB缺点：

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据。
• bgsave指令每次运行要执行fork操作创建子进程，消耗性能。

RDB存储弊端：

• 存储数据量较大，效率较低。基于快照思想，每次读写全部数据，当数据量大时，效率非常低。
• 大数据量下的IO性能低。
• 基于fork创建子进程，内存产生额外消耗。
• 宕机带来的数据丢失风险较大。

AOF持久化

AOF持久化的启动

AOF有三种持久化策略：

1. always，操作每次都同步到AOF文件中，数据零误差，性能较差。
2. everysec，每秒将缓冲器中的指令同步到AOF中，数据准确性较高，性能较高（默认设置）。系统突然宕机会丢失1秒内的数据。
3. no，由操作系统控制每次同步到AOF文件的中期，整体过程不可控。

AOF写数据过程：
AOF会将命令写入命令刷新缓冲区，之后再将命令同步到AOF文件中。

配置

appendonly yes|no 是否开启AOF持久化功能，默认不开启
appendfsync everysec(策略) 配置AOF写数据策略

AOF重写机制

重写，是将同一个数据的若干命令执行结果转化为对应的指令进行记录（若对一个key多次set值，命令只保存最后set）。

AOF重写作用：

1. 降低磁盘占用量，提高利用率。
2. 提高持久化效率，降低持久化写时间，提高IO性能。
3. 降低数据恢复时长，提高数据恢复效率。

AOF重写规则：

1. 进程内已超时的数据不再写入文件。
2. 忽略无效指令，重写时使用进程内直接生成的数据。
3. 对同一数据的多条写命令合并为一条数据。

AOF重写方式：

• 手动重写 bgrewriteaof
• 自动重写配置

自动重写配置
auto-aof-rewrite-min-size size 触发重写的aof文件最小size
auto-aof-rewrite-percentage percentage aof文件增长比例
自动重写触发对比参数
aof_current_size aof文件当前size
aof_base_size aof文件上一次重写后的大小
自动重写触发条件
aof_current_size > auto-aof-rewrite-min-size
(aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage

AOF重写流程

1. 执行指令，主进程执行指令，fork函数创建子进程进行持久化，之后的命令存储到aof缓冲区，生成非重写的.aof文件。
2. 执行重写指令，主进程执行指令，fork函数创建子进程进行重写，同时给予提示信息。从aof重写缓存区中获取数据进行重写，将重写后的.aof文件与未重写的.aof文件合并替换。

RDB与AOF的区别与选择

RDB与AOF的区别

持久化	RDB	AOF
占用内存空间	小（数据级别：压缩）	大（指令级别：重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依靠策略决定
资源消耗	高/重量级	低/轻量级
启动优先级	低	高

RDB与AOF如何选择

• 对数据敏感，建议使用默认的AOF持久化方案
  • AOF持久化策略采用everysecond，每秒钟持久化一次。该策略Redis仍可以保持很好的处理性能，最多丢失0-1秒的数据。
  • 注意：AOF文件存储体积大，恢复速度较慢。
• 数据呈现阶段有效性，建议使用RDB方案
  • 数据可以做到阶段内无丢失，且恢复速度快。
  • 注意：利用RDB实现紧凑的数据持久化会使Redis性能大幅降低。

综合对比：

1. 如果不能承受数分钟以内的数据丢失，对业务数据非常敏感，采用AOF。
2. 如果能够承受数分钟内的数据丢失，且追求大数据量的恢复速度，选用RDB。
3. 容灾回复采用RDB。
4. 双保险策略，同时开启RDB和AOF，重启后Redis有限使用AOF来恢复数据，降低丢失数据数量。