Redis持久化机制
Redis为什么数据要持久化？
Redis是内存数据库，如果数据不进行持久化，一旦Redis服务器重启数据会全部丢失。
注意：如果Redis只做缓存，你也可以不使用任何持久化方式。
什么是Redis数据持久化
把数据存储到硬盘中，当服务器开启的时候再读入到内存中去，这就是redis数据的持久化。
Redis提供两种持久化机制：RDB 和 AOF
注意：修改的redis的配置文件，要重启redis才能生效。
RDB（默认机制）
在一段时间内，检测key的变化情况，然后持久化某一个时刻数据（快照）【对性能影响低，推荐使用】
# 900秒修改key 1次，会触发rdb机制
save 900 1
# 300秒修改key 10次，会触发rdb机制
save 300 10
# 60秒修改key 1000次，会触发rdb机制
save 60 10000每次触发save，就会把当前时刻的数据记录到dump.rdb文件中（快照）
rdb机制触发的时机
-
save的规则满足的情况下，会自动触发rdb机制
-
执行flushall命令，也会触发我们的rdb机制，但里面是空的，无意义
-
关闭redis服务器（使用 shutdown指令 ），也会触发我们的rdb机制
-
save/bgsave指令会执行，save用主进程持久化，效率低(同步)，不使用，gbsave用子进程持久化(异步)
持久化执行过程
Redis会fork一个子进程进行持久化，先将数据写到临时文件(dump.rdb)中，待持久化过程结束，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
数据恢复
只需要把dump.rdb放在redis的启动目录即可，redis启动时，会自动检查dump.rdb文件，恢复数据。
生产环境我们会对dump.rdb文件进行备份。
rdb文件名称
# The filename where to dump the DB
dbfilename dump.rdb优点
- 适合大规模的数据恢复。
- 对数据的完整性要求不高。
- 持久化的整个过程中，主进程不进行任何IO操作，这就确保了极高的性能。
缺点
- fork子进程会占用一定的内存空间。
- redis意外宕机，还没触发save，最后一次修改的数据就没了（不能保证数据不丢失）。
AOF
以日志的方式把所有写的操作都记录到文件中(无限追加写入)
恢复数据时，把这个文件中所有的写操作再执行一遍。
开启aof
# 开启aof，默认不开启的
# appendonly no
appendonly yes持久化策略
# appendfsync always 每一次操作都 sync（同步），性能影响严重
appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据（默认）
# appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快AOF是没有fork子进程的，使用主进程进行的持久化。
文件名称
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"redis-check-aof工具
如果aof文件有错误，redis是启动不起来的，我需要修改这个aof文件
redis给我们提供了一个工具redis-check-aof，执行指令来修复aof文件
redis-check-aof --fix appendonly.aof优点
- 每一次修改都同步，文件的完整性更好，
- 每一秒同步一次，可能会丢失一秒的数据，
- 从不同步，效率最高
缺点
- aof文件大小远远大于rdb，修复速度也比rdb慢，aof运行效率比rdb慢
RDB和AOF的对比
对于大规模恢复数据，且对数据恢复的完整性不是非常敏感，那RDB要比AOF更加高效。
AOF数据的安全性更好，但效率低
两种持久化机制同时开启，优先使用aof机制。