「这是我参与2022首次更文挑战的第10天，活动详情查看：2022首次更文挑战」
Redis的持久化
redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一单服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能。
1.RDB（Redis DataBase）
在指定的时间间隔将内存中的数据集快照写入磁盘，也就是Snapshot快照，回复时将快照文件直接读到内存。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据库写入到一个临时文件，待持久化过程结束后，再将这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何io操作，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据回复的完整性不是非常敏感，那么RDB方式比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。默认的是RDB，一般情况下不需要修改，在生产环境也需要对dump.rdb文件进行备份。
rdb保存的文件是dump.rdb
触发机制
1.save的规则满足的情况下，会自动触发rdb规则
2.执行flushall命令，也会触发我们的rdb规则
3.退出redis，也会产生rdb文件
备份会自动生成一个dump.rdb
恢复过程
1.需要将rdb文件放在redis的启动目录就可以了，redis启动的时候会自动检查
dump.rdb恢复其中的数据！
2.通过命令查看dump.rdb需要存放的位置
优缺点
优点：适合大规模里的数据恢复，对数据的完成整性要求不高
缺点：需要一定的时间间隔进行进程操作，如果意外宕机，将会丢失最后一次修改的数据。另外，fork进程的时候，会占用一定的把内存空间。
2.AOF（Append Only File）
将所有的命令都记录下来，恢复的时候再将这个全部执行。
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只允许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
Aof保存的是appendonly.aof文件
默认是不开启的，我们需要手动进行配置，只需要将appendonly改为yes即可启动aof！然后重启redis即可生效。
aof文件可以被直接编辑，如果aof文件有错误，这时候人Redis就无法启动，需要对aof文件进行修复，使用工具redis-check-aof --fix，aof文件正常则可以直接启动
重写规则：aof默认就是文件的无限追加，文件会越来越大，如果文件大于64m，就会fork一个新的进程来将文件进行重写
优点和缺点：
优点：每一次修改都同步数据，文件的完整性更好！
每秒同步一次，可能会丢失一秒的数据
从不同步，效率最高
缺点：相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢
Aof运行效率也要比rdb慢，所以redis默认的配置就是rdb持久化
