Redis持久化详解与持久化方式对比
- RDB持久化
- RDB持久化方式的启动
- save命令进行数据持久化
- bgsave命令进行数据持久化
- RDB两种持久化启动方式对比
- RDB的优缺点
- AOF持久化
- AOF持久化的启动
- AOF重写机制
- RDB与AOF的区别与选择
- RDB与AOF的区别
- RDB与AOF如何选择
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有三种持久化策略：
- always，操作每次都同步到AOF文件中，数据零误差，性能较差。
- everysec，每秒将缓冲器中的指令同步到AOF中，数据准确性较高，性能较高（默认设置）。系统突然宕机会丢失1秒内的数据。
- no，由操作系统控制每次同步到AOF文件的中期，整体过程不可控。
AOF写数据过程：
AOF会将命令写入命令刷新缓冲区，之后再将命令同步到AOF文件中。
配置
appendonly yes|no 是否开启AOF持久化功能，默认不开启
appendfsync everysec(策略) 配置AOF写数据策略AOF重写机制
重写，是将同一个数据的若干命令执行结果转化为对应的指令进行记录（若对一个key多次set值，命令只保存最后set）。
AOF重写作用：
- 降低磁盘占用量，提高利用率。
- 提高持久化效率，降低持久化写时间，提高IO性能。
- 降低数据恢复时长，提高数据恢复效率。
AOF重写规则：
- 进程内已超时的数据不再写入文件。
- 忽略无效指令，重写时使用进程内直接生成的数据。
- 对同一数据的多条写命令合并为一条数据。
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-percentageAOF重写流程
- 执行指令，主进程执行指令，fork函数创建子进程进行持久化，之后的命令存储到aof缓冲区，生成非重写的.aof文件。
- 执行重写指令，主进程执行指令，fork函数创建子进程进行重写，同时给予提示信息。从aof重写缓存区中获取数据进行重写，将重写后的.aof文件与未重写的.aof文件合并替换。
RDB与AOF的区别与选择
RDB与AOF的区别
持久化 | RDB | AOF |
占用内存空间 | 小（数据级别：压缩） | 大（指令级别：重写） |
存储速度 | 慢 | 快 |
恢复速度 | 快 | 慢 |
数据安全性 | 会丢失数据 | 依靠策略决定 |
资源消耗 | 高/重量级 | 低/轻量级 |
启动优先级 | 低 | 高 |
RDB与AOF如何选择
- 对数据敏感，建议使用默认的AOF持久化方案
- AOF持久化策略采用everysecond，每秒钟持久化一次。该策略Redis仍可以保持很好的处理性能，最多丢失0-1秒的数据。
- 注意：AOF文件存储体积大，恢复速度较慢。
- 数据呈现阶段有效性，建议使用RDB方案
- 数据可以做到阶段内无丢失，且恢复速度快。
- 注意：利用RDB实现紧凑的数据持久化会使Redis性能大幅降低。
综合对比：
- 如果不能承受数分钟以内的数据丢失，对业务数据非常敏感，采用AOF。
- 如果能够承受数分钟内的数据丢失，且追求大数据量的恢复速度，选用RDB。
- 容灾回复采用RDB。
- 双保险策略，同时开启RDB和AOF，重启后Redis有限使用AOF来恢复数据，降低丢失数据数量。
