【Redis实战】Redis的两种持久化机制RDB和AOF

川长思鸟来 2022-12-01 14:28 123阅读 0赞

### 文章目录 ###

*   *  一、为什么做持久化？
     *  二、持久化流程
     *  三、持久化的方式
     *   *  1、RDB机制
         *  2、AOF机制
     *  四、RDB和AOF到底该如何选择？

## 一、为什么做持久化？ ##

Redis是基于内存的数据库，本身运行时数据保存在内存中，那么在关闭redis的进程或者关闭计算机后数据肯定被会操作系统从内存中清掉。所以持久化的意义在于故障恢复、数据备份。

## 二、持久化流程 ##

持久化，简单来说是指将Redis保存在内存中的所有数据保存到磁盘上。  
  具体的过程如下：  
（1）客户端向服务端发送写操作(数据在客户端的内存中)。  
（2）数据库服务端接收到写请求的数据(数据在服务端的内存中)。  
（3）服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。  
（4）操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。  
（5）磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。

## 三、持久化的方式 ##

Redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。

### 1、RDB机制 ###

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。

**RDB的优点**

*  RDB是一个非常紧凑的文件，它保存了某个时间点得数据集，非常适用于数据集的备份，比如你可以在每个小时报保存一下过去24小时内的数据，同时每天保存过去30天的数据，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
 *  RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复。
 *  RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
 *  与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。

**RDB的缺点**

*  如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你。虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作)，是Redis要完整的保存整个数据集是一个比较繁重的工作，你通常会每隔5分钟或者更久做一次完整的保存，万一在Redis意外宕机，你可能会丢失几分钟的数据。
 *  RDB 需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且CPU性能不是很好的情况下，这种情况会持续1秒，AOF也需要fork，但是你可以调节重写日志文件的频率来提高数据集的耐久度。

### 2、AOF机制 ###

**AOF 优点**

*  使用AOF 会让你的Redis更加耐久，你可以使用不同的fsync策略：无fsync、每秒fsync、每次写的时候fsync。使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求)，一旦出现故障，你最多丢失1秒的数据。
 *  AOF文件是一个只进行追加的日志文件，所以不需要写入seek，即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令，你也也可使用redis-check-aof工具修复这些问题。
 *  Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
 *  AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

**AOF 缺点**

*  对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
 *  根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

## 四、RDB和AOF到底该如何选择？ ##

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。  
   如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI3OTMzMzAx_size_16_color_FFFFFF_t_70_pic_center]  
**Redis官方**：有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。  
因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 （这是一个长期计划。）

**参考文献：**

*  Redis官网文档-Redis 持久化

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI3OTMzMzAx_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/8aea135d62bf417ba094bd20ef7df4b2.png