Redis 持久化

博文目录

---

RDB 快照

在默认情况下，Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。

可以对 Redis 进行设置，让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。

save 60 1000 # 关闭RDB只需要将所有的save保存策略注释掉即可

还可以手动执行命令生成RDB快照，进入redis客户端执行命令 save 或 bgsave 可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件，配置自动生成RDB文件后，后台使用的是bgsave方式。

save 与 bgsave

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis其他命令	是	否（在生成子进程执行调用fork函数时会有短暂阻塞）
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，额外消耗内存（用于cow）

bgsave 的写时复制机制（COW）

维基百科：写入时复制（英语：Copy-on-write，简称COW）是一种计算机程序设计领域的优化策略。其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的（transparently）。此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被建立，因此多个调用者只是读取操作时可以共享同一份资源。

Redis借助操作系统提供的写时复制技术（Copy-on-write，COW），在生成快照的同时，依然可以正常处理命令。简单来说，bgsave子进程是由主线程fork生成的，可以共享主线程的所有内存数据。bgsave子进程运行后，开始读取主线程的内存数据，并把它们写入RDB文件。与此同时，如果主线程对这些数据也都是读操作，那么主线程和bgsave子进程都是读取同一份内存数据。当主进程对其中一个内存页面的数据进行修改时，会将被对应页面复制一份分离出来，然后对这个复制的页面进行修改。而这时bgsave子进程相应的页面是没有变化的，还是子进程产生时那一瞬间的数据。注意，RDB方式生成的快照就是那一瞬间的数据状态，在生成过程中，主线程处理的其他写操作并不会被复制，可能是aof或者下次rdb才会涉及到这些操作。

AOF（append-only file）

快照功能并不是非常耐久（durable），如果 Redis 因为某些原因而造成故障停机， 那么将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件 appendonly.aof 中(先写入os cache，每隔一段时间fsync到磁盘)

执行 set key value 将在aof文件最后拼接如下内容

*3
$3
set
$3
key
$4
value

这是一种 resp 协议格式数据，* 号后面的数字代表命令有多少个参数，$ 号后面的数字代表这个参数有几个字符
注意，如果执行带过期时间的set命令，aof文件里记录的是并不是执行的原始命令，而是记录key过期的时间戳
比如执行 set key value ex 1000，对应aof文件里记录如下

*3
$3
set
$3
key
$4
value
*3
$9
PEXPIREAT
$3
key
$13
1604249786301

可以修改如下配置类打开 aof 功能，之后的每一条改变数据集的命令都会被记录到 aof 文件中，Redis 重新启动时， 就可以通过重新执行 aof 文件中的命令来达到重建数据集的目的，注意，AOF 与 RDB 同时生效，互不冲突，暂时没有互补关系

appendonly yes

可以配置 Redis 才将数据 fsync 到磁盘的频率

appendfsync always # 每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
appendfsync everysec # 每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。通常都是配置这个，兼顾速度和安全性
appendfsync no # 从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

AOF 重写

AOF 文件里可能有很多没用的指令，redis会定期根据内存的最新数据生成aof文件（注意不是优化已有的aof文件，而是根据内存状态重新覆盖生成新的aof文件）

例如执行了如下命令

127.0.0.1:6379> incr key
(integer) 1
127.0.0.1:6379> incr key
(integer) 2
127.0.0.1:6379> incr key
(integer) 3
127.0.0.1:6379> incr key
(integer) 4
127.0.0.1:6379> incr key
(integer) 5

重写后AOF文件里变成

*3
$3
SET
$3
key
$1
5

可以配置 AOF 自动重写的频率

# auto-aof-rewrite-min-size 64mb # aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
# auto-aof-rewrite-percentage 100 # aof文件自上一次重写后文件大小增长了100%（这里是64M即128M）则再次触发重写

AOF重写同样可以手动触发执行，bgrewriteaof，redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响

AOF的流程大致如下

1. Redis Server启动，如果AOF机制打开那么初始化AOF状态，并且如果存在AOF文件，读取AOF文件。
2. 随着Redis不断接受命令，每个写命令都被添加到AOF文件，AOF文件膨胀到需要rewrite时又或者接收到客户端的bgrewriteaof命令。
3. fork出一个子进程进行rewrite，而父进程继续接受命令，现在的写操作命令都会被额外添加到一个aof_rewrite_buf_blocks缓冲中。当子进程rewrite结束后，父进程收到子进程退出信号，把aof_rewrite_buf_blocks的缓冲添加到rewrite后的文件中，然后切换AOF的文件fd。
4. rewrite任务完成，继续第二个步骤。

RDB 和 AOF 对比

类型	RDB	AOF
恢复优先级	低	搞
文件体积	小	大
恢复速度	快	慢
数据安全性	容易丢数据	根据同步策略而定

生产环境可以都启用，redis启动时如果即有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一点。

Redis 4.0 混合持久化

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。混合持久化，必须先开启aof。

aof-use-rdb-preamble yes

AOF文件前半部分用RDB格式来存储快照，后半部分用原AOF格式来存储增量修改，该模式下无需开启RDB（去掉所有save）

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

于是在 Redis 重启的时候，可以先加载 RDB（aof文件前半部分）的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。

Redis 备份策略

1. 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
2. 每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份
3. 每次copy备份的时候，都把太旧的备份给删了
4. 每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏