1 Redis持久化简介
1.1 什么是持久化
1.2 持久化过程保存什么
2 RDB
2.1 save指令
2.2 save指令相关配置
2.3 RDB启动方式——save指令工作原理
2.4 RDB启动方式——后台执行bgasve
2.5 RDB启动方式——save配置
2.6 RDB特殊启动形式
2.7 RDB的优点
2.8 RDB缺点
3 AOF
3.1 RDB弊端的解决思路
3.2 AOF概念
3.3 AOF写数据过程
3.4 AOF功能开启
3.5 AOF重写
3.6 AOF重写流程
3.7 RDB和AOF区别
Redis的持久化
1 Redis持久化简介
1.1 什么是持久化
在操作系统中，内存和硬盘以块为单位交换信息。内存中可以选择当某个块不再使用时再将内容中刷新到硬盘，也可以选择硬盘和内存同步更新数据(实现数据保护)。
Redis是工作在内存上的，一旦出现断电等意外情况，那么redis中的数据将会丢失。因而redis有自己的持久化方案来确保数据安全性。
1.2 持久化过程保存什么
**保存数据快照：**将操作中的所有数据都保存下来 **保存日志：**将操作过程记录下来
redis使用了以上两种的保存方案——RDB
和AOF
2 RDB
2.1 save指令
持久化命令：save
。相当于用户主动使用ctrl+s
保存数据，保存到一个rdb文件中。需要用户主动去保存。
2.2 save指令相关配置
2.3 RDB启动方式——save指令工作原理
假如有多个客户端，因为redis是单线程，它们与服务器的通信是通过任务队列完成的。而save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用
2.4 RDB启动方式——后台执行bgasve
使用命令——bgsave
。与save
指令不同的是，它的执行时间不是立刻执行，而是服务器根据实际情况来选择什么时候保存。
2.5 RDB启动方式——save配置
配置
save second changes
作用
满足限定时间范围内key的变化达到指定数量就触发持久化
参数
second：监控时间范围
changes：监控key的变化
位置
在conf文件中进行配置
save配置原理
“save配置需要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的。save配置启动后执行的是bgsave操作
2.6 RDB特殊启动形式
全量复制：主从复制有关 服务器运行过程中重启： debug reload关闭服务器时指定保存数据： shutdown save
2.7 RDB的优点
RDB是一个紧凑压缩的二进制文件，存储效率较高 RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据、全量复制等场景 RDB恢复数据的速度要比AOF快很多 应用：服务器每X小时执行bgsave，并将RDB文件拷贝到远程机器中，用于灾难恢复
2.8 RDB缺点
RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据 bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能 Redis的众多版本中未进行RDB文件格式的统一，有可能出现各版本服务之间数据格式无法兼容现象 存储数据量大，大数据情况下效率低，IO性能较低
3 AOF
3.1 RDB弊端的解决思路
不记录所有数据，而是记录部分数据 改记录数据为记录操作过程 对所有操作均进行记录，排除丢失数据的风险
3.2 AOF概念
以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。
AOF主要作用是数据持久化的实时性，目前已经是Redis持久化的主流方式
3.3 AOF写数据过程
Redis每次接收一条数据不会马上执行，而是将指令存储到AOF写命令刷新缓存区
。然后通过命令将这些指令存储到.aof
文件当中。这中间有三种写策略：
AOF写数据三种策略
always（每次）：每次写入操作都存储到AOF文件中，数据0误差，性能较差。 everysec（每秒）：每秒将缓冲区中指令同步到AOF文件中，数据准确性较高，性能较高 no（系统控制）：由操作系统控制，整体过程被可控
3.4 AOF功能开启
配置： appendonly yes|no
作用：是否开启AOF持久化功能，默认为不开启状态。配置： appendfsync always|everysec|no
作用：AOF写策略配置： appendfilename filename
作用：AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof配置： dir
作用：AOF持久化文件保存路径
3.5 AOF重写
AOF遇到的问题
随着命令不断写入，AOF文件会越来越大。为了解决这个问题，Redis引入AOF重写机制压缩文件体积。也就是只记录会对最终结果造成影响的操作。
AOF重写作用
降低磁盘占用量，提高磁盘利用率 提高持久化效率，降低持久化写时间 降低数据恢复用时，提高数据恢复效率
AOF重写规则
进程内已超时的数据不再写入文件 忽略无效指令，只保留最终数据的写入命令 对同一数据的多条写命令合并为一条命令
AOF重写方式
手动重写：
bgrewriteaof自动重写：
auto-aof-rewrite-min-size size # 当aof文件达到size时就开始重写，比对当时的文件大小 —— aof_current_size
auto-aof-rewrite-percentage percentage # 使用一个增量的比较方式，当文件大小达到总文件大小 —— aof_base_size 百分比时就重写
AOF重写工作原理
3.6 AOF重写流程
3.7 RDB和AOF区别
RDB和AOF如何选择？
简单来说：如果对数据非常敏感，不允许数据出错，建议使用默认的AOF持久化方案；如果数据呈现阶段有效性（阶段内无丢失），建议使用RDB持久化方案
综合对比
RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB 灾难恢复用RDB 双保险策略，同时开启RDB和AOF，重启后，Redis优先使用AOF恢复数据，降低丢失数据的量。
