前言
本章主要讲述redis的持久化机制（RDB/AOF）
一、RDB持久化(默认方式)
RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。
save 900 1 # 900s内若执行1次CURD就会触发
save 300 10 # 300s内若执行10次CURD就会触发
save 60 10000 # 60s内若执行10000次CURD就会触发
1）配置快照文件目录
配置dir指定rdb快照文件的位置
# Note that you must specify a directory here, not a file name.
dir ./
2）配置快照文件的名称
设置dbfilename指定rdb快照文件的名称
# The filename where to dump the DB
dbfilename dump.rdb
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20～30秒钟。
3）问题总结
通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。
如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。
4）什么时候会触发rdb持久化？（重要）
- 1.shutdown时，若未开启aof就会触发
- 2.根据配置文件默认快照配置
save 900 1 # 900s内若执行1次CURD就会触发
save 300 10 # 300s内若执行10次CURD就会触发
save 60 10000 # 60s内若执行10000次CURD就会触发
- 3.手动执行save/bgsave时
save只管保存,其他不管,全部阻塞
bgsave：redis会在后台异步进行快照操作,同时响应客户端的请求
- 4.执行flushall命令，但是里面是空的,无意义
二、AOF持久化
默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过修改redis.conf配置文件.
1、相关配置
1）开启aof持久化
appendonly yes
2）AOF文件的保存位置
dir ./
3）默认文件名appendonly.aof
appendfilename appendonly.aof
2、触发机制（根据配置文件配置项）
appendfsync everysec(默认每s写入磁盘)
- no：等操作系统进行数据缓存同步到磁盘（快,不安全）
- always：同步持久化,每次发送数据变更,立即记录（慢,安全）
- everysec：每s执行一次（默认）（快,但是可能会丢失1s内的数据）
3、aof重写机制
当AOF文件增长到一定大小的时候,Redis能够调用Bgrewriteaof对日制文件进行重写
auto-aof-rewrite-percentage 100 #当aof文件大小的增长率大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb #当aof文件大小大于该配置项时自动开启重写
三、总结
1.redis提供了rdb,为何还要aof？
优化数据丢失问题,因为rdb会丢失最后一次快照后的数据
aof丢失不会超过2s的数据
2.若rdb和aof同时存在听谁的？
听aof的
3.rdb和aof的优劣
rdb适合大规模数据恢复，aof根据配置项而定
官方建议：两种持久化机制同事开启,若同时开启,优先使用aof
4.性能建议（只针对单机版redis）
因为rdb只做后备用途,只需15分钟备份一次即可,只保留save 900 1
若允许aof ：
- 好处：在最恶劣情况下也只会丢失不超过2s数据,启动脚本很简单,只需要load自己的aof文件即可
- 坏处：带来了持续的IO，AOF重写的最后将重写过程中产生的新数据写到新文件后造成的阻塞不可避免.（只要硬盘许可,应该尽量减少aof重写的频率,aof重写的基础大小默认4M太小了,可以设置5G以上）