简介

1.什么是持久化

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

2.为什么要持久化

防止数据的以外丢失，确保数据安全性，做好灾备的工作

3.持久化过程中保存什么

RDB:将当前数据状态进行保存模块找形式，存储数据结果，存储格式简单，关注点在数据上

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

前期准备

1.下载redis镜像

2.创建文件夹

mkdir /usr/local/docke

mkdir /usr/local/docker/redis

mkdir /usr/local/docker/redis/conf/

vi /usr/local/docker/redis/conf/redis-6379.conf -->redis-6376的内容可以在官网http://download.redis.io/redis-stable/redis.conf 下载

mkdir /usr/local/docker/redis/data/ -- 创建数据挂载目录

3.修改配置文件

bind 127.0.0.1 #注释掉这部分，这是限制redis只能本地访问

protected-mode no #默认yes，开启保护模式，限制为本地访问

daemonize no#默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程，改为yes会使配置文件方式启动redis失败

requirepass 密码 #配置redis访问密码 重启后输入密码为 auth 密码

4.启动

docker run

-p 6379:6379 // 端口映射

--name myredis //制定容器名称

-v /usr/local/docker/redis/conf:/etc/redis //配置文件映射

-v /usr/local/docker/redis/data:/data //数据映射

-d redis //后台启动

redis-server /etc/redis/redis-6379.conf //以配置文件的方式启动redis

RDB（全量数据，关注点数据）

1.save指令

1.1指令

save -->手动执行一次保存操作

save以后会多个dump.rdb的文件

1.2.save指令相关配置

dbfilename dump.rdb #设置本地数据库文件名，默认值为dump.rdb

通常设置为dump-端口号.rdb

dir #设置存储.rdb文件的路径

通常设置成存储空间较大的目录中，目录名称data

rdbcompression yes #设置存储至本地数据库时是否压缩数据，默认为yes门采用LZF压缩

通常为开启状态，如果设置为NO，可以节省CPU运行时间，但是会导致存储的文件变大

rdbchecksum yes #设置是否机型RDB文件格式校验，该校验过程在写文件和读文件过程中均进行

通常默认开启，如果要设置为NO，可以节约读写过程中约10% 时间消耗，但是存在一定的数据损坏的风险

1.3备注

save指令的执行会组扫当前redis服务器，知道RDB过程完成为止，可能会造成长时间阻塞，线上环境不建议使用

2.bgsave指令

2.1指令

bgsave -->手动保存后台执行，不是立即执行

2.2工作原理

备注：bgsave命令是针对save阻塞问题的我话，redis内部所有涉及到RDB操作都才用bgsave的方式，save命令可以放弃使用

2.3bgsave指令相关配置

stop-writes-on-bgsave-error yes #后台存储过程中如果出现错误现象，是否停止保存操作

通常默认为开启状态

3.save配置

save second changes #满足限定时间范围内key的变化数量达到指定数量即进行持久化

second为监控时间

changes监控key的变化量

例：

save 900 1
save 300 10
save 60 10000

备注：save配置根据实际业务情况机型设置，如果频率过高或频率过低都会出现性能问题

save配置中对于second和changes设置通常具有互补对应关系，如时间长变更次数小和时间短变更次数多尽量不要设置成包含行关系

save配置启动后执行的是bgsave操作

4.RDB三种方式对比

RDB其他启动方式

1.全量复制 如主从复制

2.服务器运行过程中重启 debug reload

3.关闭服务器是制定保存数据 shutdown save

5.RDB的优缺点

5.1优点

RDB是一个紧凑压缩的二进制文件，存储效率较高

RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景

RDB恢复数据的速度要比AOF快很多

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

5.2缺点

RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据

bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能

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

AOF（关注点，操作过程）

1.介绍

AOF持久化：一独立日志的方式记录每次命令，重启时再重新执行AOF文件中命令以达到恢复数据的目的

AOF主要的作用问了解决数据持久化的实时性

AOF存在缓存区，定时将缓存写入AOF文件中

2.AOF写数据三种策略

2.1 always

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

2.2 everysec

每次讲缓存区中的指令同步到AOF文件中 -->数据准确性较高，性能较高，建议使用，也是默认配置

在系统突然停机的情况下丢失1秒内的数据

2.2 no

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

3.AOF功能开启

appendonly yes|no #是否开启AOF持久化功能，默认为不开启

appendfsync always|everysec|no #配置AOF写数据策略

appendfilename filename #AOF持久化文件名，默认名称为 appendonly.aof，建议配置为appendonly-端口号.aof

dir #AOF持久化文件保存路径，与RDB持久化文件保持一致即可

发现已经写文件成功了

4.AOF重写

随着命令不断写入AOF文件中，文件会越来越大，为了解决这个问题，则引入了AOF重写机制压缩文件体积，AOF文件重写是将redis进程中的数据转化为写命令同步到新AOF文件的过程，简单来说就是将对数据的若干条指令执行结果转化为最终结果数据对应的指令

作用：

降低磁盘占用量，提高磁盘利用率

提交持久化效率，降低持久化写时间，提高IO性能

降低数据恢复用时，提交数据恢复效率

4.1指令

bgrewriteaof --手动重写

添加数据

查看文件

执行重写

查看文件

变小了有没有

4.2规则

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

忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令 如del key1、 hdel key2、srem key3、set key4 111、set key4 222等

对同一数据的多条写命令合并为一条命令 如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。 为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

4.3配置

auto-aof-rewrite-min-size size # 超过大小重写

auto-aof-rewrite-percentage percentage #超过百分比重写

自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ）

aof_current_size

aof_base_size

自动重写触发条件

4.4重写流程

RDB和AOF对比总结

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

​ 1.1 AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。

​ 1.2 注意：由于AOF文件存储体积较大，且恢复速度较慢

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

​ 2.1 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案

​ 2.2注意：利用RDB实现紧凑的数据持久化会使Redis性能降的很低，慎重使用；

3 综合比对

​ 3.2 RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊

​ 3.3如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF

​ 3.4如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB

	3.5灾难恢复选用RDB  双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量