一、RDB持久化
（一）、RDB介绍
可以在指定的时间间隔内生成数据集的 时间点快照（point-in-time snapshot），新快照会覆盖老快照
（二）、优点
压缩格式，恢复速度快，适合于用做备份，主从复制也是基于RDB持久化功能实现的
（三）、缺点
不是实时的，会有数据丢失，操作比较重量
（四）、原理
（五）、配置方法
第一步：修改配置文件
vim /data/6379/redis.conf
#添加
dir /data/6379 #持久化文件存储位置
dbfilename dump.rdb #RDB持久化数据文件
save 900 1 #900秒内如果有一次变更则进行一次持久化
save 300 10 #300秒内如果有10次变更则进行一次持久化
save 60 10000 #60秒内如果有10000次变更则进行一次持久化第二步：重新启动redis
redis-cli -a 123456 shutdown
redis-server /data/6379/redis.conf注意事项
1、没配置save参数时
1.shutdown/pkill/kill都不会持久化保存
2.可以手动执行bgsave
3、配置save参数时
1.shutdown/pkill/kill均会自动触发bgsave持久化保存数据
2.pkill -9 不会触发持久化
3、恢复时
1.持久化数据文件名要和配置文件里定义的一样才能被识别
2.RDB文件只有一个数据文件，迁移和备份只要这一个RDB文件即可
二、AOF持久化
（一）、AOF介绍
AOF（append-only log file）：记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集
AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾
（二）、优点
可以最大程度保证数据不丢
（三）、缺点
日志记录量级比较大，持久化时间较长
（四）、原理
（五）、配置方法
第一步：修改配置文件
vim /data/6379/redis.conf
#添加
appendonly yes #开启AOF持久化
appendfilename "redis.aof" #持久化存储文件
appendfsync always #每次操作成功都执行一次持久化
#或者 建议设置
appendfsync everysec #每秒钟提交一次持久化
#或者
appendfsync no #不进行持久化第二步：重启redis
redis-cli -a 123456 shutdown
redis-server /data/6379/redis.conf（六）、AOF重写机制
1、重写机制原理
（1）redis主进程通过fork创建子进程
（2）子进程根据当前redis内存中的数据生成数据库重建命令序列到临时文件中
（3）父进程继承client的新请求，把请求中的写操作继续追加至原来的AOF文件(而不是直接写入临 时文件，避免写操作失败带来的问题)；额外地，这些新的写请求还会被放置于一个缓冲队列中
（4）子进程重写完成，会通知父进程，父进程把缓冲中的命令写到临时文件中
（5）父进程将临时文件替换掉旧的AOF文件
2、重写机制注意事项
和RDB一样，如果当前的数据量巨大，那么创建子进程的过程会很耗时。
在大数据的处理工作中，文件的删除也是一项比较麻烦的工作。
像我们普通的笔记本电脑，删除一个几GB的文件都是一项很耗时的工作，
更何况大数据的量级远远大过我们日常使用的数据。
所以在替换aof文件时，如果旧的aof很大，删除它也是一个很耗时的过程。
当然这并不是aof或者redis的缺点，只是可能会出现的一个客观情况
AOF注意事项
1.aof修复命令不要⽤，因为他的修复⽅案⾮常粗暴，⼀⼑切，从出错的地⽅到最后全部删除
2.任何操作之前，先备份数据
三、redis 持久化方式有哪些？有什么区别？
rdb：基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能
aof：以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全，类似于mysql的binlog
四、save bgsave 区别？
共同点：都能实现redis持久化功能。
不同点：
SAVE： 前台，阻塞redis正常写入，直到持久化完成。
BGSAVE：后台，开启子线程，异步的持久化功能，不会阻塞redis正常写入。
五、AOF和RDB如何选择
1.开启混合模式
2.开启aof
3.不开启rdb
4.rdb采⽤定时任务的⽅式定时备份
5.可以从库开启RDB进⾏备份
