Redis 的缓存持久化有两种技术 ： RDB 和 AOF
RDB
Redis 的数据快照
简单说就是将缓存中的所有数据都记录到磁盘中，当Redis发生故障的时候，只需读取快照文件，就可恢复数据
相应的命令是 save 和 bgsave ，这两个命名都可以手动执行RDB持久化，不过
- save 由 Redis 主线程来执行RDB，会阻塞所有命令
- bgsave 开启子线程执行RDB，主线程不受影响
如果每次RDB都需要手动输入save或bgsave命令未免太麻烦
因此Redis内部有RDB触发机制，格式 ：save [时间] [key的修改次数]
比如 save 300 1 表示300秒内至少有一个key被修改了，则执行 bgsave
AOF
AOF全称 Append Only File （追加文件）。Redis 处理的每一个写命令都会记录在AOF文件中，相当于一个命令日志文件
AOF 的开启方法
找到 redis.conf 文件，其中有一行语句是 appendonly no，因为Redis默认关闭AOF，改为appendonly yes，就可开启AOF，下面还有一行语句 appendfilename “appendonly.aof” 指定AOF文件名
设置 AOF 的记录频率
AOF的执行频率也叫刷盘策略，同样是通过redis.conf 文件进行配置，总共有三档频率
- appendfsync always ： 同步刷盘，每执行一次写命令，就立刻记录到AOD文件
- appendfsync everysec ： 每秒刷盘，写命令先放入AOF缓冲区，然后每隔一秒将缓冲区数据写到AOF文件，这是Redis默认的AOF刷盘策略
- appendfsync no：操作系统控制，写命名都先放入AOF缓冲区，由操作系统决定何时将缓冲内容写回磁盘
三种刷盘策略由上到下，性能原来越好，但可靠性越来越差，因此实际开发过程中大部分选择 appendfsync everysec 刷盘策略
另外 AOF文件比RDB文件要大的多，而且AOF会记录对同一个key的多次写操作，但只有最后一次是有效的。我们可以通过 bgrewriteaof 命令，让AOF文件执行重写功能，用最少的命令达到相同的效果
比如：
set num 1
set name zyj
set num 3
执行bgrewriteaof命令后，可重写为 mset name zyj num 3
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：
- 找到语句 auto-aof-rewrite-percentage [百分比]，该语句表示 AOF文件比上次文件增长超过多少百分比触发重写
- 语句 auto-aof-rewrite-min-size [AOF文件大小]，该语句表示AOF文件达到多大就触发重写
RDB 和 AOF 对比
RDB -
优点 ： 文件小； 宕机恢复速度快
缺点 ： 数据完整性较低； 占用的CPU和内存资源较大
AOF -
优点 ：数据完整性较高； 在记录时占用的CPU和内存资源较小（但重写的时候占有很大）
缺点 ：文件体积大，较占用磁盘空间；宕机恢复速度较慢
RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。
