持久化主要有3种模式，RDB快照,AOF,RDB+AOF，
当aof文件跟rdb文件都存在的时候，他会优先用aof文件去还原持久化，因为aof数据会比较完整一点
1. RDB快照（snapshot）
在默认情况下， Redis用的是RDB快照，他会将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
路径我们可以配置，多久保存一次我们也可以配置，不过相比aof还是会漏一部分的数据
-
保存文件路径
dbfilename dump.rdb
-
保存频率配置
save 900 1 900秒内至少有1个修改
save 300 10 900秒内至少有10个修改
save 60 10000 60秒内至少有10000个修改
关闭rdb的话其实就是把这几个注释掉就行
有一个100ms的job在扫描这些配置，保存着操作次数跟最后一次save时间。判断当前时间减去配置时间，是否能满足配置的修改数
2 AOF(append-only-file)每一条修改都会记录到文件里面
-
开启命令及保存文件路径
appendonly yes 开启
appendfilename "appendonly.aof" 保存路径
-
aof写入流程及其策略
系统每次执行命令请求会先先往 AOF 缓冲区里面写一条命令，之后再定期写人并同步到 AOF 文件，可以配置写入的策略：
(1)：appendfsync always 每次修改都写入
(2)：appendfsync everysec 有修改的时候每秒写入 一般用这个可以兼容性能跟完整性
(3)：appendfsync no 从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择
-
aof重写：会自动优化整合我们的redis命令，比如把3次+1直接替换为+3
配置修改命令
auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就
很快，重写的意义不大
auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写
我们也可以手动调用bgrewriteaof来实现重写
-
aof注意点
AOF 重写是一个有歧义的名字，他会新生成一个aof文件，并且该功能是通过读取数据库中的键值对来实现的，程序无须对现有 AOF 文件进行任何读人、分析或者写入操作。
在执行BGREWRITEAOF命令时，Redis 服务器会维护一个AOF 重写缓冲区该缓冲区会在子进程创建新AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个 AOF 文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的AOF 文件，以此来完成AOF 文件重写操作。
3. RBD+AOF
-
开启命令(需要先开启aof保存appendonly yes)
aof‐use‐rdb‐preamble yes
他是基于aof的，他生成的rdb跟aof备份都是在同一个文件，也就是我们上面配置的appendonly.aof，
刚开始的时候他就是一个普通的aof持久化文件，当aof发生重写的时候他会把之前的aof格式命令全部重构成rdb格式的写到aof里面，后面的命令还是aof格式文件
像这边重写后的aof文件，上面是rbd格式，下面是aof
-
优缺点
环境准备
docker部署的话是没有配置文件的，首先我们需从官网拉取配置文件http://download.redis.io/releases/
docker部署语句，
如果是本地连的话需要把配置文件里面的bind 127.0.0.1注释掉，把protected-mode 改为no
docker run -p 6379:6379 --name redis \
-v /mydata/redis/data:/data \
-v /mydata/redis/redis.conf:/etc/redis/redis.conf \
-d redis:5 redis-server /etc/redis/redis.conf
