redis持久化包括rdb和aof两种方案
1、rdb持久化方案
- 持久化过程：按照redis.conf文件配置，如
save 900 1
save 300 10
save 60 10000
，在指定时间间隔内满足数据落盘策略时候，redis会fork一个和原进程一模一样的子进程，该进程先将数据存到一个临时文件里，待持久化结束后，用临时文件替换上次的持久化文件。
- 触发落盘：满足配置的策略、使用flushdb、使用flushall（效果是所用数据都删除了，落盘后dump.rdb（默认文件名，可配置）文件内容为空）
- 恢复数据：将dump.rdb复制到安装redis目录，并启动redis的服务。（连上redis后可以使用config get dir 获取redis的安装目录）
劣势：a、在一定间隔时间落盘一次，如果redis意外down，会吊事最后一次的redis中所有修改
b、fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
优势：适合对数据完整性和一致性要求不高的场景；适合大规模的数据恢复
2、aof持久化方案
- 持久化过程：按照redis.conf文件配置，如
#appendfsync always
appendfsync everysec
#appendfsync no
，根据同步策略为everysec，则每秒将写操作追加（读操作不会追加）到appendonly.aof文件。
- 恢复数据：将appendonly.aof文件复制到config get dir对应的目录，并重启redis
- 重写机制：appendonly.aof的内容是以追加的方式添加的，如果没有特殊机制，该文件会越来越大，为避免这个情况，redis针对aof持久化方式有重写机制
重写过程：当aof文件超过配置的阈值（满足配置文件的配置的策略），redis会fork出一个进程，该进程遍历内存中的数据，每条记录都对应一条set语句，写入临时的aof文件，重写完成后，用临时文件替换上次的持久化文件。
劣势：a、aof文件远大于rdb文件
b、数据恢复速度慢于rdb
优势：同步策略always->每次修改同步，性能差但完整性好；同步策略everysec->每秒同步，异步操作，如果一秒内down机会丢失数据；no->从不同步
3、疑问
如果两种持久化方式都配置了，那么redis重启时候，从哪里恢复数据呢？
从appendonly.aof文件恢复，因为aof持久化的数据更精确
是不是只使用aof持久化方式呢？
...