Redis有两种持久化的方式，分别为rdb持久化和aof持久化

一、rdb文件持久化

1、rdb文件的持久化文件名配置

该配置为配置文件里的默认配置，意思为生成的持久化文件为dump.rdb

2、rdb文件持久化触发机制

（1）满足save的条件，则会自动触发rdb机制，生成相应的备份文件

例如：

根据save的条件进行保存key的操作，即当满足如下图所示的条件时，触发rdb规则，生成dump.rdb文件

（2）执行flushall命令后也会自动触发rdb规则，生成dump.rdb文件

（3）退出redis时，也会触发rdb规则，生成dump.rdb文件

3、恢复rdb文件里的数据

把rdb文件放到redis的启动目录里，redis启动时会自动检查rdb文件并恢复里面的数据。

例：

Window的redis启动目录

Linux

同样放在reids的启动目录下

---

二、aof(Append Only File)文件持久化

 AOF(Append Only File)

将我们所有输入的命令都记录下来，在恢复的时候把这个aof文件里的所有命令都执行一遍。

1、appendonly yes（开启AOF）

2、appendfilename "appendonly.aof"(生成的文件名，一般不做修改，使用默认配置）

3、 持久化的策略

（1）appendfsync always（每一次修改都同步aof文件,但消耗性能）

（2）appendfsync everysec（每一秒都同步aof文件，但关机等情况会丢失这一秒的数据）

（3）appendfsync no（从不作同步操作，这时操作系统自己同步数据，速度最快）

4、aof文件重写

重写是为了将aof文件变得更小，降低文件占用空间，以便于更快的被redis加载，当开启文件重写，达到一定条件后，新建一个新的aof文件重写;重写的原理就是把能合并的命令合并，比如多次操作一个key，就可以合并成一个，无效的key的操作就可以全部删除，例如：incrby views 10 和   incrby views 10 合并成 incrby views 20。

例：

5、修复aof文件

redis-check-aof --fix appendonly.aof

6、aof文件缺点

（1）相比较rdb文件，aof文件占据的存储空间更大，修复的速度也比rdb文件慢。

（2）因为需要读写操作，aof文件的运行效率也比rdb文件慢，所以我们redis默认的配置就是进行rdb持久化。

---

扩展：

1、RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储 

2、AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。   

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化。  

4、同时开启两种持久化方式
（1）在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。工
（2）RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢?作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

（1）因为RDB文件只用作后备用途，建议只在Slave（从机）上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
（2）如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。

（3）·如果不Enable AOF，仅靠Master-Slave Repllcation（主从复制）实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave 中的RDB文件，载入较新的那个，微博就是这种架构。