redis持久化机制

目录

1、什么是持久化

2、Redis为什么要持久化？

3、Redis持久化方式

3.1 RDB持久化

3.2 AOF持久化

---

1、什么是持久化

---

持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。

---

2、Redis为什么要持久化？

---

        redis是一个内存数据库，所谓内存数据库是指redis的所有内容都存放在内存中。这一点与传统的关系型数据库如mysql、oracle等形成了鲜明的对比，后者将数据存放在硬盘中。我们知道，内存的读取速度要比硬盘快的多，内存数据库能大大提高读写效率。但随之而来的问题是，如果我们将数据保存在内存中，那么一旦断电或者宕机，内存中所有的数据都会丢失。为了解决这个问题，redis提供了持久化机制。

        持久化能够保证服务器因故障崩溃或重启后，数据不会丢失，因为在下次重启时可以利用之前持久化文件实现数据恢复。

---

3、Redis持久化方式

        Redis支持RDB和AOF两种持久化机制。

3.1 RDB持久化

---

• 什么是RDB持久化

RDB原理是将当前内存中的数据库快照保存到磁盘文件中， 在 Redis 重启动时， RDB 程序可以通过载入 RDB 文件来还原数据库的状态，是一种全量的持久化方式

RDB 持久化主要由 rdbSave 和 rdbLoad 两个函数来实现。其中，前者用于生成 RDB 文件到磁盘， 后者则将 RDB 文件中的数据重新载入到内存中。

                                                     

                                                                         rdbSave和rdbLoad

rdbSave 函数负责将内存中的数据库数据以 RDB 格式保存到磁盘中， 如果 RDB 文件已存在， 那么新的 RDB 文件将替换已有的 RDB 文件。当 Redis 服务器启动时， rdbLoad 函数就会被执行， 它读取 RDB 文件， 并将文件中的数据库数据载入到内存中。在载入期间， 服务器每载入 1000 个键就处理一次所有已到达的请求。 等到载入完成之后， 服务器才会开始正常处理所有命令。

---

• RDB持久化触发方式

触发RDB持久化过程分为手动触发和自动触发。

---

1. 手动触发

有两种方式可以出发redis的RDB持久化：

1）save

save命令直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。当save正在执行时， 新的save、bgsave或bgrewriteaof调用都不会产生任何作用。只有在save执行完毕或中断的情况下， redis才会重新开始接受请求。对于占用内存比较大的实例，该命令会导致较长时间的阻塞，这在生产环境中可能会导致致命的问题，所以redis提供了第二种手动触发方式。

2）bgsave

bgsave会异步的进行快照保存。其原理在于，当执行bgsave时，主进程会fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。主进程负责在bgsave执行期间客户端的请求。这样做可以避免save和bgsave调用的两个 rdbSave 交叉执行， 造成竞争条件。

---

       2.自动触发

自动触发主要是通过配置文件来实现的，只要满足了我们设置的触发条件，即可实现自动触发。redis.conf有关自动触发的配置文件截图如下：

设置触发条件：

简单说明一下该配置的含义吧，当然注释里面也说了，我这里再唠叨一遍。

save 900 1      //在900秒内如果有1一个key发生了变化，自动触发bgsave

save 300 10     //在300秒内如果有10个key发生了变化，自动触发bgsave

save 60 10000   //在60秒内如果有10000个key发生了变化，自动触发bgsave

注：以上save m n 之间是或的关系，即只要有一个条件满足就会自动触发bgsave。

如果不想使用redis的持久化功能的话，可以通过配置 save ""来屏蔽掉RDB持久化方式。

设置RDB文件的保存路径和文件名

设置文件是否压缩​​​​​​​

压缩。优点：减少磁盘存储空间；缺点：消耗CPU资源

不压缩。优点：不消耗CPU资源；缺点：占用磁盘空间

应根据具体使用场景决定是否使用压缩。

---

• bgSave执行流程

a. 执行bgsave命令，redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在，bgsave命令直接返回。

b. 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork以操作的耗时，单位为微秒。

c. 父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，父进程可以继续响应其他命令。

d. 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成尺RDB的时间，对应info统计的rdb_last_save_time选项。

e. 进程发送信号给父进程衣示完成，父进程更新统计信息，具体见info Persistence下的rdb_*相关选项。

---

• save和bgSave优缺点分析

save的优点在于节约系统资源，不需要fork子进程。缺点是其在执行时会阻塞redis进程，阻塞期间，服务器无法响应其他的处理，直到执行完成为止。如果数据量小，用此命令可能感觉不出有什么区别，但是当数据量很大的时候，就需要谨慎使用这个命令了，可能会导致数据丢失。

bgsave的优点是执行此命令的时候，redis会fork出一个子进程去完成备份持久化，而不会影响redis处理其他的请求。但由于会fork一个进程，因此更消耗内存。

---

---

3.2 AOF持久化

3.1节中我们介绍了RDB持久化，了解了RDB持久化的两种触发方式及其优缺点。RDB持久化方式存在的一个比较大的问题就是，该方式只是记录数据库某一时刻的数据快照，如果发生宕机等意外情况时，会丢失最后一个RDB持久化之后的所有数据。对于数据完整祥要求很严格的场景，这显然是不能满足实际需要的。

---

---

• 什么是AOF持久化

AOF（Append Only File）即追加文件持久化：服务器通过读取配置，在指定的时间里，追加 Redis 所执行的写命令来记录数据库状态，恢复时通过伪客户端发送执行命令到服务端，是一种增量的持久化方式

---

• 触发方式

AOF通过修改配置文件开启自动持久化，持久化过程可分为：

命令追加(append)：服务器以协议格式将被执行的写命令追加到aof_buf缓冲区末尾

文件写入(write)：调用 write 函数，将数据保存在内存缓冲区

文件同步(fsync)：根据 appendfsync 参数将缓冲区中的内容冲洗到磁盘上

                               

注：redis默认开启RDB持久化，aof需要手动开启。当开RDB和AOF同时开启时，redis启动时优先加载AOF文件。

---

• AOF重写

1. 为什么要进行AOF重写

AOF 文件会随时间变得越来越大。为了更简洁的记录被频繁操作后的键值状态， Redis 需要对 AOF 文件进行重写。​​​​​​​

     2. 重写相关参数配置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage：默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size：64mb。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

     3. 重写过程

                                                      

a. 子进程根据键的类型，使用适当的写入命令重现键的当前值，主进程追加到现有的 AOF 文件及AOF重写缓存中，避免重写过程中新数据丢失

b. 父进程接收到子进程完成通知后，将AOF重写缓存中的内容写入到新 AOF 文件中

c. 父进程使用替换旧的 AOF 文件

---

AOF和RDB优缺点对比

对比项	RDB	AOF
触发机制	手动：save、bgsave、save m n 自动：slave、debug reload、shutdown	自动：根据配置条件自动触发
文件格式	文件小，使用RDB格式的二进制	文件大，使用网络通讯协议的文本文件
同步方式	定时同步，完整拷贝某个时间点内存	实时同步，根据不同策略追加操作日志
恢复方式	恢复速度快	恢复速度较慢
文件校验	文件损坏无法加载，不兼容旧版本文件	文件损坏可修复加载
使用场景	数据冷备，加密传输	实时持久化