SpringBoot+mybatis+redis项目示例中学习了redis在框架中的基本使用后，我想到了一件很重要的事
Redis的数据是存放在内存中，发生宕机后之前的数据会没了…
顺着这个思路，了解到redis持久化
一、 Redis持久化的意义
宕机后可以快速找回之前的数据，防止大量请求打入数据库，防止服务或系统宕机导致数据丢失。
二、 Redis持久化方式
Redis持久化的方式有两种：RDB持久化、AOF持久化。
在redis.conf文件中配置RDB和AOF两种持久化机制（我用的5.0.10版本，配置文件是redis.windows.conf）
配置文件修改需要重启redis服务
2.1 RDB持久化
每隔一段时间，将redis内存中的数据保存为RDB文件，Redis启动后会自动加载RDB快照文件，将数据从硬盘载入到内存。默认的文件名为dump.rdb。
RDB持久化机制，对redis中的数据执行周期性的持久化.
RDB提也分两种：save、bgsave
2.1.1 save
阻塞式的RDB持久化:
当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件（即上面的dump.rdb）中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。
## 900秒内，如果超过1个key被修改，则发起快照保存
save 900 1
## 300秒内，如果超过10个key被修改，则发起快照保存
save 300 10
## 60秒内，如果1万个key被修改，则发起快照保存
save 60 10000
## 持久化文件名称
dbfilename dump.rdb
## 持久化数据文件存放的路径
dir ./
除了通过修改配置文件，也可以通过命令行进行配置
#查看redis持久化配置
CONFIG GET save
#修改持久化，m:秒数，n:修改key数
CONFIG SET save "m n"
设置成 10秒内超过1个key被修改，发起快照保存
修改key后发现dump.rdb文件的修改日期变了
redis的服务日志server_log也更新了内容：
2.1.2 bgsave
非阻塞式的持久化:
异步方式生成快照，创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。
优点：即使后台保存操作出错,redis也仍然可以继续像平常一样工作。
缺点：等同于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。
stop-writes-on-bgsave-error yes
命令行
redis>bgsave
2.2 AOF持久化
跟RDB保存数据不同，AOF是通过记录Redis服务端的写命令来实现持久化。
#AOF文件存放目录
dir ./
#开启AOF持久化，默认关闭
appendonly yes
#AOF文件名称（默认）
appendfilename "appendonly.aof"
#AOF持久化策略
appendfsync no
开启AOF持久化后，输入以下命令：
127.0.0.1:6379>config set appendonly yes
127.0.0.1:6379>config set save ""
命令执行后会生成对应的aof文件用以保存命令，新命令会被追加到文件的末尾。
AOF策略分为三种:
always：每次操作都会立即写入aof文件中
everysec：每秒持久化一次(默认配置)
no：不主动进行同步操作，默认30s一次
2.3 RDB和AOF对比
| RDB | AOF | |
|---|---|---|
| 优点 | 1. 适合用于备份；2. 适用于灾难恢复（disaster recovery）；3. 性能最大化，子进程完成持久化的工作，极大的避免服务进程执行IO操作；4. 恢复大数据集时的速度比 AOF 的恢复速度要快 | 1. 带来更高的数据安全性，即数据持久性，默认策略为每秒钟 同步一次，发生故障停机，也最多只会丢失一秒钟的数据；2.采用append模式向日志文件写入内容，不会破坏日志文件中已经存在的内容 |
| 缺点 | 1. 出现宕机时，容易丢失未来得及写入磁盘的数据；2. 数据集较大时，可能导致服务器停止服务一段时间 | 1. AOF 文件的体积通常要大于 RDB 文件的体积；2 .AOF在运行效率上往往会慢于RDB |