【Redis】Redis持久化

矫情吗；* 2022-06-09 10:29 352阅读 0赞

Redis是内存数据库，数据存在内存中，虽然速度快，但同时数据安全性也产生了一些新问题，即在redis所在服务器宕机后，redis数据库里的所有数据将会丢失。

为解决这个问题，Redis提供了持久化功能——一种方法叫RDB（快照），另一种叫AOF（只追加文件）。下面我们来了解一下这两种方式。   
![这里写图片描述][70]

# RDB——全量写入 #

如果系统发生崩溃，用户将丢失最近一次生成快照后更改的所有数据。因此快照只适用于那些即使丢失一部分数据也不会造成问题的应用程序，而不能接受这种数据损失的可以使用AOF持久化。

![70 1][]

## redis.conf配置 ##

save 900 1
    save 300 10
    save 60 10000
    dbfilename "dump.rdb"          #持久化文件名称
    dir "/data/dbs/redis/6381"    #持久化数据文件存放的路径

save配置选项，如save 60 10000，表示从Redis最近一次创建快照开始算，60秒内有10000次写入。前三行任一条件满足时，Redis会自动触发BGSAVE命令持久化。dbfilename指定了写入本地文件的名称，通过该文件可以把数据库还原到生成该文件时数据库的状态。dir指定了RDB文件存放目录。修改配置文件后需要重启redis服务。

## RDB分类 ##

*  SAVE
    
     *  阻塞的RDB持久化，当执行这个命令时，redis的主进程会把内存的数据库状态写入配置中的RDB文件（dump.rdb），直到创建完毕，redis将不能处理任何命令请求。
 *  BGSAVE
    
     *  非阻塞式，它会创建一个子进程专门把内存的数据库状态写入RDB文件，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，相当于两个相同大小的redis进程在运行，造成内存使用率大幅增加。

## 场景 ##

### 个人开发 ###

主要考虑降低持久化带来的资源消耗。

如果打算在生产服务器使用快照持久化并存储大量数据，那么开发服务器最好能与生产服务器相同或相似，并设置相同的save选项，存储相似的数据集并处理相近的负载量。把开发环境与生产环境尽量贴近，可判断快照是否过于频繁或过于稀少（频繁了浪费，稀少了可能丢失数据）。

### 日志聚合计算 ###

主要考虑因为崩溃未能成功创建新的快照，我们能承受丢失多长时间内的数据。如果可以接受1个小时内，可以配置save 3600 1，但是另一个需要解决的问题就是如何恢复因故障被中断的日志处理操作。   
在数据恢复时，首先要弄清我们丢失了哪些数据。可以通过在处理日志的同时记录被处理日志的信息。   
       通过process\_logs()函数可以做到这点，该函数有三个参数，分别是Redis连接，存储日志的路径，待处理日志文件中各行的回调函数callback。这样通过将日志的处理进度记录到Redis，程序可以在系统崩溃后，根据进度记录继续执行之前未完成的处理工作。通过使用事务流水线，可以同时将日志的处理结果和进度同时记录到快照。

### 大数据 ###

当Redis存储的额数据量只有几个G的时候，使用快照存数据时没问题的，但是如果占用数十个G，并且剩余内存不多了。或者Redis运行在虚拟机，那么执行BGSAVE（创建子进程耗费时长较多）可能导致系统长时间停顿，性能降低甚至无法使用。   
       为防止Redis因创建子进程出现停顿，我们可以关闭自动保存，使用BGSAVE或SAVE手动保存，由于使用SAVE不需要创建子进程，因此不会有子进程争夺资源，这样创建快照的速度会更快些。

# AOF——增量写入 #

与RDB保存整个redis的数据库状态不同，AOF是通过保存我们对redis数据库的写操作。

![70 2][]

## AOF内容 ##

[redis@iZ]$ more appendonly.aof 
    *2
    $6
    SELECT
    $1
    0
    *3
    $3
    SET
    $47
    DEV_USER_LEGAL_F9683BE0E27F1A06C0CB869CEC7E3B22
    $11
    ¬
    *3
    $3
    SET
    $47

## 配置 ##

dir "/data/dbs/redis/6381"           #AOF文件存放目录
    appendonly yes                       #开启AOF持久化，默认关闭
    appendfilename "appendonly.aof"      #AOF文件名称（默认）
    appendfsync no                       #AOF持久化策略
    auto-aof-rewrite-percentage 100      #触发AOF文件重写的条件（默认）
    auto-aof-rewrite-min-size 64mb       #触发AOF文件重写的条件（默认）

AOF的持久化是通过命令追加、文件写入和文件同步三个步骤实现的。   
1、命令追加   
当redis开启AOF后，服务端每执行一次写，会把该条命令追加到一个单独的AOF缓冲区的末尾。   
2、文件写入   
将缓冲区的内容写入到AOF文件   
3、文件同步   
将内存缓冲区的数据写入硬盘

思考：第二步看似完成了持久化，为何还有第三步呢？   
       我们需要从写入机制说起：操作系统为了提高文件的写入效率，都会有一个写入策略，当往硬盘写入数据时，会先把数据暂存在一个内存缓冲区，当该缓冲区满，会真正将缓冲区的数据写入硬盘，也就是说第二步知识将数据写入到AOF了，但对系统而言只不过是将AOF缓冲区的内容放到了另一个内存缓冲区了，所以我们还需要进行文件同步，将内存缓冲区的数据写入硬盘才算完成一次持久化。

## 同步频率 ##

always——每个Redis写命令都会被写入硬盘，从而在系统崩溃时出现的数据丢失减到最少，但严重降低Redis的速度，使用固态硬盘处理较快，但是不断写入少量数据可能引发写入放大问题，缩短固态硬盘的使用寿命，所以慎用。

everysec——每秒执行一次同步，显式将多命令同步到硬盘。兼顾数据安全和写入性能。这样如果出现崩溃，用户至多丢失1秒的数据。当硬盘忙于执行写入时，Redis还会优雅放慢自己的速度以便使用硬盘的最大写入速度。

no——Redis不对AOF执行任何显式的同步，而是由操作系统决定。这一般不会对性能由影响，但系统崩溃导致一部分数据丢失。如果硬盘读写慢，缓冲区等待写入硬盘的数据填满时，Redis的写入被阻塞，导致Redis处理请求变慢，所以不推荐。

**两种方式的选用**

1、持久化方式

RDB——指定时间间隔内快照存储。

AOF——记录每次写的操作，可以后台重写，不至于AOF文件过大。

2、只做缓存

可以不做持久化。

3、同时开启

redis重启优先载入AOF，因此在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。RDB数据不实时，同时使用两者时服务器重启也只会找AOF文件。

4、性能建议

RDB：建议只在slave上持久化RDB，只要15min备份一次就够了，只保留save 900 1这条规则。

Enable AOF：最坏情况下也只会丢失不超过两秒的数据，启动脚本简单，只load自己的AOF文件就可以。

AOF代价：

1）持续IO；

2）rewrite产生的新数据写到新文件造成的阻塞不可避免。

如果不Enable AOF，仅靠Master-Slave实现高可用也可以，只不过，如果master和slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较master和slave中RDB文件，载入较新的。新浪微博就选用了这种架构。

**参考资料：**

*  《Redis实战》—— 黄健宏
 *  [https://www.cnblogs.com/dengtr/p/5085287.html][https_www.cnblogs.com_dengtr_p_5085287.html]

[70]: /images/20220609/5669d56e50214aa1af8d11ec48e1d266.png
[70 1]: /images/20220609/d124c31f10204d2484048a68fed7b124.png
[70 2]: /images/20220609/cfb27d0b64c94095a4c55a7f5e42a8bb.png
[https_www.cnblogs.com_dengtr_p_5085287.html]: https://www.cnblogs.com/dengtr/p/5085287.html