Redis持久化

持久化

        我们都知道，redis是基于内存实现的nosql的菲关系型数据库，相比mysql等数据库的速度是很快的，但有一个问题，假设redis重启或故障之后会导致内存数据丢失，所以就有了Redis持久化机制。

Redis支持三种持久化方式：

• 快照（snapshotting，RDB）
• 只追加文件（append-only file, AOF）
• RDB 和 AOF 的混合持久化(Redis 4.0 新增)

RDB

什么是RDB持久化？

通过创建快照的方式将某一时刻的数据保存到dump.rdb文件中，在redis重启或redis主从结构时读取或同步rdb文件，实现数据的持久化。

配置

redis默认开启的配置，save   m  n ，表示m秒内数据集至少有n个改动就会自动保存一次数据集。

# rdb文件名称

dbfilename  dump.rdb   

# rdb文件保存路径

 dir "/usr/local/redis-5.0.14/data/6379"

 

创建快照命令

save：同步保存操作，会阻塞redis主线程。

bgsave：fork一个子进程，子进程执行保存操作，不影响主线程，默认选项。

save方式比较好理解，保存数据时，会阻塞主线程，redis的读取操作都会被阻塞。

bgsave方式是fork出一个子进程，子进程将内存数据保存到rdb文件中。如果在保存数据过程中，主线程只进行读操作，那么主线程和子线程互不影响，如果主线程进行修改操作，那么这块数据就会被复制一份，生成这块数据的副本，当子线程将redis内存数据保存到rdb完成后，会继续将副本数据也保存到rdb中，而在这个过程中，主线程仍然可以直接修改原来的数据。

测试

思路：设置几个key-value值，然后执行save操作，先关闭redis服务，在开启，发现数据还在，然后在设置一个key，不执行save操作，直接关闭redis，在开启，然后发现设置的key丢失了。

（1）第一步

设置key值，执行save

（2）第二步

 重启redis

 （3）测试

（4）设置key不执行save操作可以自己测下。

 缺点

（1）在对redis执行操作后，如果没自动触发save操作，而redis正好故障了，会导致这部分数据丢失。

（2）redis的内存不能设置过大，一次save是将内存全部数据保存到dump.rdb文件中，一次执行时间太长，会影响性能。

AOF

什么是 AOF 持久化？

是将每一条修改命令都保存到文件appendonly.aof中，当重启时，在读取aof文件数据，将文件中的命令一条条执行，从而恢复redis内存数据。

aof默认是关闭的，在redis.conf 中开启。

appendonly  yes

保存路径和rdb文件一样，都通过dir参数设置，文件名通过appendfilename设置。

appendfilename "appendonly.aof"

AOF的工作流程

1、命令追加

将每一条写命令都追加到aof缓冲区中。

2，文件写入（write）

将aof缓冲区中的数据写入到aof文件中，这一步会调用write函数（现在还没保存到磁盘）。

3，文件同步（fsync）

根据aof持久化策略，将aof文件同步到磁盘，这一步会调用fsync函数。

4，文件重写

当aof文件越来越大是，会定期对aof文件进行重写。

5，重启加载

当redis重启时，redis会读取aof文件对数据进行恢复。

aof的持久化方式

# 主线程调用write后，后台线程会立即调用fsync同步文件

appendfsync always

# 主线程调用write后，后台线程1秒后会调用fsync同步文件

appendfsync everysec

#  主线程调用write后立即返回，文件同步由操作系统自己确定

appendfsync no

aof重写

重写配置

如果 AOF 文件大小小于该值，则不会触发 AOF 重写。默认值为 64 MB;

auto-aof-rewrite-min-size

执行 AOF 重写时，当前 AOF 大小（aof_current_size）和上一次重写时 AOF 大小（aof_base_size）的比值。如果当前 AOF 文件大小增加了这个百分比值，将触发 AOF 重写。将此值设置为 0 将禁用自动 AOF 重写。默认值为 100。

auto-aof-rewrite-percentage

重写示例

重写前

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

重写后

SET  readcount  5

注：aof重写时会创建一个缓冲区，用来保存重写期间写入aof文件的命令，当aof重写完成后，会将缓冲区的命令追加到重写后的aof文件中，并替换掉重写之前的aof文件。

缺点

（1）一般aof的持久化策略都是1秒保存一次，这样会丢失这1秒内的数据。

（2）因为appendonly.aof文件中保存的都是命令，所以在使用aof恢复命令的时候，会追条读取进行恢复，恢复的过程使比较慢的。

混合持久化

什么是混合持久化？

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

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

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