版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/lwl2014100338/article/details/82808131
持久化
可以避免因进程退出而导致的数据丢失问题，下次重启时利用之前的持久化文件即可实现数据恢复
RDB
手动触发
（一）save ：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间的阻塞，现实环境不建议使用
（二）bgsave：Redis进程执行fork操作进程创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
自动触发
（一）使用save相关配置
save m n 表示m秒内数据集存在n次修改时，自动触发bgsave
（二）执行 dubug reload 命令重新加载Redis时，自动触发save操作
（三）默认情况下执行shutdown，如果没有开启AOF持久化则自动执行bgsave
RDB优缺点
优点：（一）RDB是紧凑的二进制文件，非常适合用于备份、全量复制等场景
（二）Redis加载RDB恢复数据远远快于AOF的方式
缺点：（一）RDB方式数据没法做到实时持久化
（二）存在老版本Redis服务无法兼容新版RDB格式的问题
AOF
AOF持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到数据恢复的目的。AOF主要解决了数据持久化的实时性，目前是Redis的主流持久化方式
持久化流程
（一）所有的写入命令追加到aof_buf（缓存区）中
（二）AOF根据对于的策略向硬盘做同步操作
（三）AOF文件越来越大，定期对AOF文件重写，达到压缩的目的
（四）Redis服务器重启时，加载AOF文件进行数据恢复
重写机制
AOF文件变小原因
（一）进程内已经超时的数据不再写入文件
（二）新的AOF文件只保留最终数据的写入命令
（三）多条写命令可以合并为一个
AOF重写降低了文件占用空间，更小的AOF文件可以更快速地被Redis加载