一篇文章彻底理解Redis的持久化：RDB、AOF

一、为什么要持久化？

因为Redis是内存数据库，它将自己的数据存储在内存里面，一旦Redis服务器进程退出或者运行Redis服务器的计算机停机，Redis服务器中的数据就会丢失。

为了避免数据丢失，所以Redis提供了持久化机制，将存储在内存中的数据保存到磁盘中，用于在Redis服务器进程退出或者运行Redis服务器的计算机停机导致数据丢失时，快速的恢复之前Redis存储在内存中的数据。

Redis提供了2种持久化方式，分别为：

RDB持久化
AOF持久化

二、快照持久化（snapshotting，RDB）

RDB:Redis DataBase将某一个时刻的内存快照（Snapshot）,以二进制的方式写入磁盘

手动触发

• sava命令，使Redis处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的命令，所以在生产环境一定要慎用
• bgsave命令，fork出一个子进程执行持久化，主进程只在fork过程中有短暂的阻塞，子进程创建之后，主进程就可以响应客户端请求了

bgsave命令的具体流程：
执行bgsave命令，Redis进程先判断当前是否存在正在执行的RDB或AOF子线程，如果存在就是直接结束。
Redis进程执行fork操作创建子线程，在fork操作的过程中Redis进程会被阻塞。
Redis进程fork完成后，bgsave命令就结束了，自此Redis进程不会被阻塞，可以响应其他命令。
子进程根据Redis进程的内存生成快照文件，并替换原有的RDB文件。
子进程通过信号量通知Redis进程已完成。

自动触发

除了执行以上命令手动触发以外，Redis内部可以自动触发RDB持久化。自动触发的RDB持久化都是采用bgsave的方式，减少Redis进程的阻塞。那么，在什么场景下会自动触发呢？

• 在配置文件中设置了save的相关配置，如sava m n，它表示在m秒内数据被修改过n次时，自动触发bgsave操作，如果设置多个，只要满足其一就会触发，配置文件有默认配置（可以注释掉）
• 当从节点做全量复制时，主节点会自动执行bgsave操作，并且把生成的RDB文件发送给从节点。
• 执行debug reload命令时，也会自动触发bgsave操作。
• 执行shutdown命令时，如果没有开启AOF持久化也会自动触发bgsave操作。

优点

1、整个Redis数据库将只包含一个文件dump.rdb，方便持久化。
2、容灾性好，方便备份。
3、性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化。使用单独子进程来进行持久化，主进程不会进行任何I0操作，保证了redis 的高性能
4.相对于数据集大时，比AOF的启动效率更高。
缺点：
1、数据安全性低。RDB是间隔一段时间进行持久化,如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)
2、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。会占用cpu

三、 只追加文件持久化（append-only file, AOF）

原理

AOF持久化是把每次写命令追加写入日志中，当需要恢复数据时重新执行AOF文件中的命令就可以了。AOF解决了数据持久化的实时性，也是目前主流的Redis持久化方式。

持久化流程

命令追加（append）：所有写命令都会被追加到AOF缓存区（aof_buf）中。
文件同步（sync）：根据不同策略将AOF缓存区同步到AOF文件中。
文件重写（rewrite）：定期对AOF文件进行重写，以达到压缩的目的。
数据加载（load）：当需要恢复数据时，重新执行AOF文件中的命令。

文件同步策略

AOF持久化流程中的文件同步有以下几个策略：
always：每次写入缓存区都要同步到AOF文件中，硬盘的操作比较慢，限制了Redis高并发，不建议配置。
no：每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件的周期不可控，而且增大了每次同步的硬盘的数据量。
eversec：每次写入缓存区后，由专门的线程每秒钟同步一次，做到了兼顾性能和数据安全。是建议的同步策略，也是默认的策略。

触发文件重写

AOF持久化流程中的文件重写可以手动触发，也可以自动触发。

手动触发：使用bgrewriteaof命令。
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置确定自动触发的时机。auto-aof-rewrite-min-size表示运行AOF重写时文件大小的最小值，默认为64MB；auto-aof-rewrite-percentage表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认为100。只用前两者同时超过时才会自动触发文件重写。

AOF持久化配置

对AOF持久化的具体流程有了了解后，我们来看一下如何配置AOF。AOF持久化默认是不开启的，需要修改配置文件，如：

# appendonly改为yes，开启AOF
appendonly yes
# AOF文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 运行AOF重写时AOF文件大小的增长率的最小值
auto-aof-rewrite-percentage 100
# 运行AOF重写时文件大小的最小值
auto-aof-rewrite-min-size 64mb

四、RDB持久化、AOF持久化的区别

实现方式

RDB持久化是通过将某个时间点Redis服务器存储的数据保存到RDB文件中来实现持久化的。

AOF持久化是通过将Redis服务器执行的所有写命令保存到AOF文件中来实现持久化的。

文件体积

由上述实现方式可知，RDB持久化记录的是结果，AOF持久化记录的是过程，所以AOF持久化生成的AOF文件会有体积越来越大的问题，Redis提供了AOF重写功能来减小AOF文件体积。

安全性

AOF持久化的安全性要比RDB持久化的安全性高，即如果发生机器故障，AOF持久化要比RDB持久化丢失的数据要少。

因为RDB持久化会丢失上次RDB持久化后写入的数据，而AOF持久化最多丢失1s之内写入的数据（使用默认everysec配置的话）。

优先级

由于上述的安全性问题，如果Redis服务器开启了AOF持久化功能，Redis服务器在启动时会使用AOF文件来还原数据，如果Redis服务器没有开启AOF持久化功能，Redis服务器在启动时会使用RDB文件来还原数据，所以AOF文件的优先级比RDB文件的优先级高。

五、Redis持久化数据和缓存怎么做扩容？

1、如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。

2、如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

六、Redis 4.0 对于持久化机制的优化

Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。

如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。

文章参考：

Redis面试题
一篇文章彻底理解Redis持久化：RDB和AOF
Redis高频面试题