redis 持久化
便于灾难恢复，相当于高可用，在 redis 宕机之后可以很快的恢复数据，保证数据不丢失。默认俩种持久化都开启时，redis 使用 aof 恢复数据
rdb
快照方式，每次存储记录的时候都是通过 fork 出一个子线程，子线程首先将数据存放到一个临时文件中，等到将数据写完后，在采用原子的方式将旧的 dump.rdb 文件替换掉
fork：Linux fork 函数，对本来的进程复制出一份子进程，父进程可以继续做自己的事情（响应客户端的写操作），子进程进行 rdb 的写磁盘
- 优点：
-
- rdb 保存的是某一个时间点的全量数据，所以可以对每一个时间点的数据进行备份，在恢复的时候可以恢复到不同的版本
- rdb 持久化的时候 fork 一个子线程去执行，父线程继续执行自己的事情
-
- rdb 恢复数据的速度比 aof 快
- 缺点：
-
- 容易丢失数据，因为 rdb 持久化的时候是根据每秒有多少数据写来完成，如果这个时候机器坏了，就会丢失这些数据
- 如果数据量大的话，fork 的子线程就会频繁的 io ，影响性能
使用方式：save <seconds> <changes>
save "" 禁用 rdb
例如：save 60 1 ：六十秒内有一个 set 操作就会备份，如果这六十秒内 redis 宕机，就会丢失这部分数据
aof
日志记录，以追加文件的方式来持久化，每当有新的写命令，就将命令追加到日志文件中
fsync：强制刷新 os 缓存到磁盘
-
优点
-
比 rdb 方式更加持久，因为 redis 提供了三种 fsync(强制刷新) 策略来写入磁盘，fsync 也相当于 fork 出一个子线程，然后来处理日志记录，父线程继续处理业务请求
-
always：每一条指令都写入磁盘，频繁的 io，不推荐
-
everysec：每秒写入一次，默认
-
no：交给操作系统来完成，没有保障
-
-
redis 可以在后台对日志文件进行重写，减少冗余，在重写的时候会新创建一个 aof 文件，而如果有写入命令还是会追加到原来的文件并且在内存中缓存一份，当新文件重写完后，会通知父线程，然后用新的文件替换旧的文件，并将缓存中的记录加入新的文件中，在 redis 4 之后对重写做了优化，在重写的时候不需要重写原来的命令，而是会生成一个 rdb 快照，加入 aof 文件中，然后替换原来的 aof 文件，以后直接追加在这个 aof 文件后即可
-
是否开启使用 rdb 快照方式
aof-use-rdb-preamble yes
可以手动执行命令重写或者达到条件自动重写
命令：BGREWRITEAOF
auto-aof-rewrite-percentage 100：百分比
auto-aof-rewrite-min-size 64mb：aof 文件大小
-
aof 的文件比较容易看懂，如果不小心执行了 flushall 命令，在你没有重写 aof 的前提下，可以找到 aof 文件，删除最后的 flushall 命令，然后做数据恢复
-
缺点
- aof 的体积要比 rdb 大，恢复的时候也比较慢，因为需要重新执行命令
模拟恢复数据
当同时开始 rdb 和 aof 的时候，恢复时会使用 aof 文件，因为 aof 文件保存的更完整
1、rdb
使用 save 命令，保存当前时刻的全量数据，将 dump 文件替换掉原来的 dump 文件，重启 redis，就会重新使用新的 rdb 文件恢复数据