本文共 877 字，大约阅读时间需要 2 分钟。

1、快照RDB

默认使用，性能高

备份某个时间点上内存中数据的副本，不仅可以本地持久化，还可以传给其他服务器用来创建相同数据的服务器副本，完成Redis集群的搭建。每经过规定时间检查是否有指定数量的key发生改变，如果达到则进行快照持久化

除了满足save规则会触发RDB持久化外，执行flushall命令或客户端退出redis时，也会持久化。把dump.rdb放在config get dir的指定目录下，启动就会恢复其中的数据 Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能

2、只追加文件AOF

实时性好

开启后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，比快照的方式实时性更好

修复appendonly.aof文件：redis-check-aof --fix appendonly.aof

建议使用appendsync everysec，让Redis每经过1秒钟同步一次AOF文件，性能几乎不会受到影响，并且最多丢失1秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度

AOF持久化缺陷：AOF文件默认无限追加，导致文件体积太大

解决方案：重写/压缩AOF，用户可以向Redis发送 BGREWRITEAOF命令 ，这个命令会通过fork一个子进程来移除AOF文件中的冗余命令来重写（rewrite）AOF文件来减小AOF文件的体积

扩展：Redis4.0开始支持RDB和AOF的混合持久化(默认关闭，可以通过配置aof-use-rdb-preamble开启)。AOF重写的时候就直接把RDB的内容写到AOF文件开头，这样做的好处是可以结合RDB和AOF的优点，快速加载同时避免丢失过多的数据。当然缺点也是有的，AOF里面的 RDB部分就是压缩格式不再是AOF格式，可读性较差