Redis如何持久化数据？

持久化的一般有两个思路，一个思路就是直接保存数据，比如 MySQL 的 dump；另一个思路就是保存日志文件，比如说 MySQL 的 binlog，根据日志执行 SQL 语句也能恢复数据。

Redis 工作的时候使用的是内存，宕机之后内存中的数据肯定就没有了，redis 线程退出的时候数据也会丢失，所以我们应该要做好 redis 的持久化工作。

Redis 有两种持久化的方式。一种是使用 RDB 持久化，是对数据的全量备份；一种是使用 AOF 做增量备份。

RDB 持久化

RDB 持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发。

手动触发有save和bgsave两命令，由于save会阻塞线程，线上环境不建议使用：

• save: 阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞
• bgsave: redis 进程执行 fork 操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;

命令：config set dir /usr/local  //设置rdb文件保存路径
备份：bgsave  //将dump.rdb保存到usr/local下
恢复：将 dump.rdb 放到 redis 安装目录与 redis.conf 同级目录，重启redis即可
优点：
1. 压缩后的二进制文，适用于备份、全量复制，用于灾难恢复
2. 加载RDB恢复数据远快于AOF方式

缺点：
1. 无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
2. 保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题

AOF 持久化

针对RDB不适合实时持久化，redis提供了 AOF 持久化方式来解决。

开启：redis.conf 设置：appendonly yes  (默认不开启，为no)
默认文件名：appendfilename "appendonly.aof"  

命令写入(append), 文件同步(sync), 文件重写(rewrite), 重启加载(load)：

1. 所有的写入命令(set hset)会append追加到aof_buf缓冲区中
2. AOF缓冲区向硬盘做sync同步
3. 随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩
4. 当redis服务重启，可load加载AOF文件进行恢复

AOF配置详解：

appendonly yes           //启用aof持久化方式
# appendfsync always //每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec //每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐
# appendfsync no         //完全依赖os，性能最好,持久化没保证（操作系统自身的同步）
no-appendfsync-on-rewrite  yes  //正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100  //aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb   //aof文件,至少超过64M时,重写

AOF 如何恢复？

1. 设置appendonly yes；
2. 将appendonly.aof放到dir参数指定的目录；
3. 启动Redis，Redis会自动加载appendonly.aof文件。

redis 重启时加载 AOF 与 RDB 的顺序？

1. 当AOF和RDB文件同时存在时，优先加载
2. 若关闭了AOF，加载RDB文件
3. 加载AOF/RDB成功，redis重启成功
4. AOF/RDB存在错误，启动失败打印错误信息