1. redis持久化方法
- 保存当前数据的快照数据（RDB）
- 保存当前数据的修改记录（AOF）
2. RDB
2.1 RDB优缺点
优点：
- RDB是一个紧凑压缩的二进制文件，存储效率较高
- 非常适合用于数据备份，全量复制等场景，服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复
- RDB恢复数据的速度要比AOF快很多
缺点：
- 无法实时持久化，宕机带来的数据丢失风险
- 大数据量下的IO性能较低
- fork操作创建子进程，丢失性能
- RDB文件格式不统一
2.2 如何解决RDB单线程执行效率过低
- 手动启动后台保存操作，但不是立即执行：bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式（由同步改为异步）
3. AOF
定义：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程，解决了数据持久化的实时性 三种策略：always(每次）性能较低，everysec（每秒）丢失秒内数据，no（系统控制）
3.1 AOF VS RDB
- 对数据非常敏感，建议使用默认的AOF持久化方案，但由于AOF文件存储体积较大，且恢复速度较慢
- 数据呈现阶段有效性，建议使用RDB持久化方案
- 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF；如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB，灾难恢复选用RDB
3.2 如何解决AOF文件巨大的问题
解决方案：将AOF文件进行压缩存储，方式是将同一个数据的若干条命令执行结果转化为最终结果数据对应的指令进行记录，它可以降低IO，提高效率，降低数据恢复时间
- 进程内已超时的数据不再写入文件
- 只保留最终数据的写入命令
- 对同一数据的多条写命令合并为一条命令
备注：部分资料参考黑马程序员的PPT，仅供自己学习记录非商业用途，如有侵权联系删除
