Ridis持久化

Redis持久化

RDB（Redis DataBase）

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行io操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据的恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。Rdb的缺点是最后一次持久化后的数据可能丢失，我们默认的就是RDB，一般情况下不需要修改这个配置。

rdb保存的文件时dump.rdb

有时候在生产环境 我们会将dump.rdb备份

触发机制

1. save规则满足的情况下，会自动触发rdb规则
2. 执行flushall命令，也会触发rdb规则
3. 退出redis，也会产生rbd文件

备份就自动生成dump.rdb

如何恢复rdb文件

1. 只需要将rdb文件放在我们的redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据
2. 查看需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/" # 如果这个目录下存在dump.rdb文件，启动就会自动恢复其中的数据

优点：

1. 适合大规模的数据恢复
2. 对数据的完整性要求不高

缺点：

1. 需要一定的时间间隔取操作，如redis意外宕机，这个最后一次修改数据就没有的了
2. fork进程的时候，需要一定的内存空间

AOF（append only file）

以日志的形式来记录每个写操作，将Redis执行过的指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

Aof保存的是appendonly.aof

默认是不开启的，需要手动配置。只需要将appendonly 改为yes就开启了aof

重启redis就可以生效了

如果这个aof文件有错误，这时候redis是启动不起来的，我们需要修复这个aof文件

redis给我们提供了一个工具 redis-check-aof

优点和缺点

appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用
appendfilename "appendonly.aof" # 持久化的文件的名字

# appendfsync always # 每次修改都会 sync 消耗性能
appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据
# appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快
	

如果aof文件大于64m，fork一个新进程来将我们的文件重写。

优点：

1. 每一次修改都同步，文件的完整性会更加好
2. 每秒同步一次，可能会丢失一秒的数据
3. 从不同步，效率最高

缺点：

1. 相对于数据文件来说，aof远远大于rdb，修复的速度比rdb慢
2. Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化