什么是持久化：

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

为什么要进行持久化：

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

持久化方式：

RDB：数据（快照）：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

AOF：过程（日志）：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

RDB启动方式-save指令

马上执行，而且加入到任务执行队列中

重启redis可以自动恢复数据，如果没有save重启之后就没有了

但是save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用

RDB启动方式-bgsave指令

通过后台调用fork函数生成子进程来完成的

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

RDB启动方式-自动执行（save配置）

配置文件在conf文件夹（也可能放在其他路径下）下，例如：6379.conf

启动命令：redis-server redis-6379.conf

save second changes

限定时间范围内，key的变化数量达到执行数量即可进行持久化

second：监控时间范围

changes：监控key的变化量

save 300 10 300s内10个key发生了变化

RDB启动方式-特殊启动

• 全量复制：主从复制
• 服务器运行过程中重启：debug reload
• 关闭服务器时指定保存数据：shutdown save

RDB 持久化优点 RDB是一个紧凑压缩的二进制文件，存储效率高 RDB恢复数据速度比AOF快

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

RDB持久化缺点 无法做到实时持久化，具有较大可能丢失数据 存储数量较大时，效率较低，I／O性能较低 基于fork创建子进程，内存产生额外消耗 宕机带来的数据丢失风险

Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

AOF

AOF写数据的三种策略：

always（每次）：每次写入操作均同步到AOF文件中，数据零误差，性能较低（不建议使用）

everysec(每秒)：每秒将缓冲区中的指令同步到AOF文件中，数据准确性高，性能较高

在系统突然宕机的情况下丢失1s的数据

no（系统控制）：由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF功能开启：

配置：appendonly yes|no

作用：是否开启AOF持久化功能，默认为不开启状态

配置：appendfsync always|everysec|no

作用：AOF写数据策略

AOF相关配置：

配置：appendfilename filename

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

配置:dir

作用：AOF持久化文件保存路径，与RDB持久化文件保持一致即可。

AOF重写：

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。

将对同一个数据的若干条命令执行结果，转化成最终结果数据对应的指令进行记录。

AOF重写规则：

进程内已经超时的数据不再写入文件

忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令

对同一数据的多条写命令合并为一条命令

AOF重写方式：

手动重写：bgrewriteaof

自动重写：auto-aof-rewrite-min-size size

auto-aof-rewirte-percentage percentage

AOF重写流程：

RDB与AOF区别：

对于数据非常敏感，建议使用默认的AOF持久化方案

数据呈现阶段有效性，建议使用RDB持久化方案

持久化场景：

1、redis应用于抢购、限购类，限量发放优惠券、激活码等业务的数据存储设计

2、redis应用具有操作先后顺序的数据控制（也可以用mq）

3、redis应用于最新消息展示

4、redis应用于基于黑名单与白名单设定的服务控制（黑名单可以用）

5、redis应用于计数器组合排序功能对应的排序

6、redis应用于按次结算的服务控制