机器环境：
redis服务器，6c16G的普通pc，cpu是i5 8400。
redis服务本身没有做特别优化，版本为：5.0.3。
首先对比不同持久化方案对读写性能的影响：
1·快照 rdb
rdb 是将当前redis库中的数据快照保存到日志中。重启时，直接恢复日志中的数据快照；
rdb快照保存，可以通过手动也可以通过自动。手动是调用save函数或者bgsave函数，save函数是同步命令，bgsave是异步命令；bgsave执行时，redis主进程会fork一个子进程来完成快照保存
rdb 可以设置快照保存时机
2·aof
aof是将用户输入的命令全部记录到日志中。重启时，通过重放日志中的命令来实现数据恢复
aof 有三种模式，对应三种保存时机
客户端持续10W次的读写。
| 策略 | 子选项 | 耗时 |
|---|---|---|
| aof | 每秒持久化一次(appendfsync everysec) | 109.50019216537 s |
| aof | 每次有新命令就持久化（appendfsync always） | 6822.3529829979 s |
| aof | 不主动持久化，（ appendfsync no） | 101.27058696747s |
| rdb | save 900 1; save 300 10; save 60 10000 | 102.0494949817s |
启动恢复时长：
aof因为是记录的操作命令，所以即使redis库中数据全部删除，aof的日志文件依旧不会变小，这也就导致了aof策略下，恢复redis的时长会越来越长。
rdb因为是数据库快照，所以不会受历史影响，恢复速度理论上会更快；但是rdb的持久化策略可能会丢数据。
redis 4.0 之后，推出混合持久化模式。aof在持久化的时候，不是直接将内存中的数据转换为命令保存。而是保存当前时间节点的内存快照以及之后的增量命令。
这样，在恢复的时候，先从日志恢复内存快照，然后再重放增量命令，以达到快速恢复的能力。
| 数据量 | 策略 | 启动耗时 |
|---|---|---|
| 110W（33m日志文件） | rdb | 0.0208s |
| 110W（33M日志文件） | aof | 0.0207s |
