个人博客

一、简介

redis支持RDB和AOF两种持久化机制，持久化能避免因进程退出而导致的数据丢失，当再次启动redis服务进程时，可以恢复之前的数据。

RDB：在指定的时间间隔对数据进行快照存储。

AOF：记录每次对reids服务器的写操作，当redis服务器重启时，会重新执行这些命令来恢复数据。

二、RDB持久化

1，手动持久化：

登录redis服务器之后，可以执行save和bgsave命令生成RDB文件。

save命令：会阻塞当前redis服务器进程，知道RDB文件创建完毕为止，在redis服务器阻塞期间，服务器不能处理任何命令请求。

bgsave命令：会创建一个子进程，由子进程来负责创建RDB文件，父进程（redis主进程）则继续处理请求。

bgsave命令执行过程中，只有fork子进程会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此线上要杜绝使用save命令。此外，在自动触发RDB持久化时，redis会选择bgsave而不是save来持久化。

2，自动持久化：

1，触发场景：

• 根据配置文件的save m n自动触发。
• 在主从配置的情况下，如果从节点执行全量复制操作，则主节点发送RDB文件给从节点完成复制，主节点会触发bgsave。
• 执行shutdown命令时，会自动执行RDB持久化。

2，配置文件：

# 时间策略
save 900 1
save 300 10
save 60 10000

# 持久化保存文件名
dbfilename dump.rdb

# 文件保存路径
dir ./

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否进行压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

3，参数说明：

save 900 1：表示900s内如果有1条命令写入redis服务器，就触发一次快照保存，即进行一次备份。
save 300 10：表示300s内如果有10条命令写入redis服务器，就进行一次备份。
save 60 10000：表示60s内如果有10000条命令写入redis服务器，就进行一次备份。

之所以同时配置多条备份规则，是因为redis每个时间段的读写请求是不均匀的，为了平衡redis的性能和数据的安全，定义多条规格能确保在比较频繁写的时候缩短备份时间，比较少写操作时延长备份时间。

stop-writes-on-bgsave-error yes：这个配置是在redis进行备份出错的时候，主进程是否还接受写操作，这是为了保证持久化数据一致性问题。

rdbcompression yes：对备份数据是否进行压缩，redis本身就是CPU密集型服务器，启动压缩会对服务器性能有所降低，建议不开启，减少点CPU消耗。

注：如果想禁用RDB持久化数据，可以在配置文件的save的最后一行配置上save “”。

4，RDB持久化流程：

1）redis父进程先判断当前是否在执行save，或者bgsave的子进程，如果存在就直接返回。
2）父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，redis不能执行任何操作命令。
3）父进程fork之后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，并可以响应其他命令。
4）子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原文件进行替换。

三、AOF持久化

1，手动持久化：

登录redis服务器之后，可以执行bgrewriteaof命令生成AOF文件。

bgrewriteaof命令：用于执行一个AOF文件冲重写，重写会创建一个当前AOF的优化版。即使执行失败，也不会有任何数的损失，因为旧的AOF文件在命令执行成功之前不会被修改。

2，自动持久化：

1，触发场景：

• 配置文件配置了appendonly yes时自动触发。
• 接收到客户端的bgrewriteaof命令时会触发。

2，配置文件：

# 是否开启AOF
appendonly yes

# 保存文件名
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

# AOF重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载AOF时如果有错如何处理
aof-load-trucated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

3，参数说明：

appendfsync everysec：同步方式，它有三种模式。
* always：把每个命令都立即同步到AOF，很慢，但是很安全。 * everysec：每秒同步一次，是折中方案。 * no：redis不处理，交给系统来处理，性能最好，但也是最不安全。
一般情况下都是采用everysec，这样可以兼顾速度和安全，最多损失1s的数据。

aof-load-truncated yes：设置为yes，如果发现AOF尾部不正确，会向客户端写入一个log，但还会继续执行；设置为no，当发现错误时，就会停止，必须修复后重新加载。

no-appendfsync-on-rewrite no：设置为no，这个时候redis主线程有写入操作，都会被阻塞掉，这方式最安全，由于没有新数据写入，就不会有数据丢失问题；设置为yes，这个时候redis主线程写数据不会被阻塞，但是这部分数据不会同步到硬盘上，这是redis宕机的话，就会有数据的丢失。

auto-aof-rewrite-percentage 100，auto-aof-rewrite-min-size 64mb：当AOF文件的大小超过上一次rewrite的1倍且文件大于64MB时，Redis将执行 bgrewriteaof 命令进行重写。

aof-rewrite-incremental-fsync yes：设置AOF rewrite过程中是否采取增量文件同步策略，设置为yes，rewrite过程中，每32M数据进行一次文件同步，这样可以减少AOF大文件写入磁盘的操作次数。

4，AOF持久化流程：

1）所有写命令会追加到aof_buf中。
2）AOF缓存区根据对应的策略向硬盘做同步操作。
3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩目的。
4）当redis服务器重启时，可以加载AOF文件进行数据恢复。

四、redis持久化恢复数据

启动时会先检查AOF文件是否存在，如果不存在就尝试加载RDB文件，都不存在的情况才会恢复数据失败。

五、RDB和AOF的优缺点及选择

1，RDB的优缺点：

优点：

• RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式适合做冷备。
• RDB对redis对外提供的读写服务影响非常小，因为redis主进程fork一个子进程出来，让子进程对磁盘IO进行RDB持久化。
• RDB在恢复大数据集时的速度比AOF的恢复速度快。

缺点：

• 如果redis故障时要尽可能少的丢失数据，RDB没有AOF好。
• RDB每次fork出来的子进程来执行RDB快照生成文件时，如果文件特别大，可能会导致客户端提供暂停数毫秒或几秒。

2，AOF的优缺点：

优点：

• AOF可以更好的保护数据不丢失，一般AOF会每秒通过后台创建一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。
• AOF以append-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
• AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合灾难性的误删除紧急恢复。

缺点：

• 对于同一份文件AOF文件比RDB数据快照大。
• AOF开启后支持写的QPS会比RDB支持写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的。
• 数据恢复比较慢，不适合做冷备。

3，RDB和AOF的选择：

• 不要仅仅选择RDB备份，这样会丢失很多数据。
• 也不要仅仅使用AOF备份，因为这样会有两个问题：1，通过AOF做冷备没有RDB做冷备的恢复速度快；2，RDB每次简单粗暴的生成数据快照，更加健壮。
• 综合AOF和RDB两种持久化方式，用AOF来保证数据不丢失，作为恢复的第一选择。用RDB来做冷备，在AOF文件丢失或者损坏时，可以使用RDB进行快速恢复。