数据持久化

Redis面临的数据安全问题

    Redis是一个缓存中间件,它的最大特点是使用内存从而使其性能强悍。但是使用内存的方式有一个致命的特点就是数据没办法持久化保存。然而Redis持久化存储有两种持久化方案,RDB(Redis DataBase)和 AOF(Append-Only File)。其中RDB是将内存中的数据进行快照存储到磁盘,AOF则为可回放的命令日志记录redis内的所有操作。它们各有特点也相互独立。Redis4之后支持RDB-AOF混合持久化的方式,结合了两者的优点,可以通过 aof-use-rdb-preamble 配置项可以打开混合开关。

RDB:快照持久化

一、原理

    RDB(Redis DataBase)是将Redis内存中的数据进行Snaptshot快照存储在磁盘内,是Redis的默认持久化方案。使用RDB持久化默认有三种策略,该持久化策略在redis.conf中可配置,会以一段时间内有指定次数据修改的规则触发快照动作,快照文件名为dump.rdb,该文件默认使用LZF压缩算法 。每当Redis服务重启的时候会从该文件中加载数据进内存。

二、save和bgsave

    RDB持久化除了可以根据配置中的策略触发,也可以手动触发,使用save和bgsave命令即可。这两个命令的区别的save会阻塞服务器进程,在进行save的过程中,服务器不能处理任何请求,而bgsave会通过一个子进程在后台处理rdb持久化。事实上save和bgsave调用的都是rdbSave函数,因此Redis不允许save和bgsave同时运行,这也是为了避免出现竞争导致rdb文件数据不准确。
    bgsave操作使用CopyOnWrite机制进行写时复制,是由一个子进程将内存中的最新数据遍历写入临时文件,此时父进程仍旧处理客户端的操作,当子进程操作完毕后再将该临时文件重命名为dump.rdb替换掉原来的dump.rdb文件,因此无论bgsave是否成功,dump.rdb都不会受到影响。
    另外在主从全量同步、debug reload以及shutdown的情况下也会触发RDB数据持久化。

1、save原理图

2、bgsave原理图

3、save与bgsave对比

命令 save bgsave
IO类型 同步 异步
是否阻塞 否(阻塞发生在fork)
有点 不会消耗额外内存 不阻塞客户端命令
缺点 阻塞客户端命令 创建fork,消耗内存

三、RDB优点

1、及时点紧凑文件,适用于备份

    RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。例如,你可能想要每小时归档最近24小时的RDB文件,每天保存近30天的RDB快照。这允许你很容易的恢复不同版本的数据集以容灾。

2、适合灾备恢复,可远程传输

    RDB非常适合于灾难恢复,作为一个紧凑的单一文件,可以被传输到远程的数据中心。

3、子进程进行复制任务,不影响父进程

    RDB最大化了Redis的性能,因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程,由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。

4、数据保存读写快

    RDB在重启保存了大数据集的实例时比AOF要快。

四、RDB缺点

1、容易数据丢失

    当你需要在Redis停止工作(例如停电)时最小化数据丢失,RDB可能不太好。你可以配置不同的保存点(save point)来保存RDB文件(例如,至少5分钟和对数据集100次写之后,但是你可以有多个保存点)。然而,你通常每隔5分钟或更久创建一个RDB快照,所以一旦Redis因为任何原因没有正确关闭而停止工作,你就得做好最近几分钟数据丢失的准备了。

2、大数据量RDB导致服务停止几秒

    RDB需要经常调用fork()子进程来持久化到磁盘。如果数据集很大的话,fork()比较耗时,结果就是,当数据集非常大并且CPU性能不够强大的话,Redis会停止服务客户端几毫秒甚至一秒。AOF也需要fork(),但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。

总结

优点:速度快,适合于用作备份,主从复制也是基于RDB持久化功能实现的。
缺点:会有数据丢失、导致服务停止几秒

五、RDB相关配置

1、RDB触发机制

# 格式:save <seconds> <changes>

#   save ""               #关闭该规则
save 900 1              #900秒内至少有1个key被改变则做一次快照
save 300 10             #300秒内至少有300个key被改变则做一次快照
save 60 10000           #300秒内至少有300个key被改变则做一次快照

2、设置持久化文件名

dbfilename  dump.rdb
#rdb持久化存储数据库文件名,默认为dump.rdb

3、bgsave出错时动作

stop-write-on-bgsave-error yes 
#yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件。

4、RDB文件检查

rdbchecksum yes
#在写入文件和读取文件时是否开启rdb文件检查,检查是否有无损坏,如果在启动是检查发现损坏,则停止启动。

5、RDB文件存放目录

dir "/etc/redis"
#数据文件存放目录,rdb快照文件和aof文件都会存放至该目录,请确保有写权限

6、RDB压缩

rdbcompression yes
#是否开启RDB文件压缩,该功能可以节约磁盘空间

六、RDB相关操作

1、停止备份

在配置文件中就设置save ""或在命令行中 config set save ""。

2、手动开始备份

save:会立即生成dump.rdb,但是会阻塞往redis内存中写入数据。
bgsave:后台异步备份。

如果是使用flushdb命令,会把之前的快照更新成当前的空状态,所以执行了flushdb后更新的快照是没有数据的。

AOF (append-only log file)

一、原理(可以理解为数据库binlog)

    AOF(Append-Only File)记录Redis中每次的写命令,类似mysql中的binlog,服务重启时会重新执行AOF中的命令将数据恢复到内存中,RDB(按策略持久化)持久化方式记录的粒度不如AOF(记录每条写命令),因此很多生产环境都是开启AOF持久化。AOF中记录了操作和数据,在日志文件中追加完成后才会将内存中的数据进行变更。

二、过程

1. 客户端的请求写命令会被append追加到AOF缓冲区内;
2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中;
3. AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
4. Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的;

三、AOF相关配置

开启了AOF之后,RDB就默认不使用了。使用下面的配置开启AOF以及策略。(如果使用AOF,推荐选择always方式持久化,否则在高并发场景下,每秒钟会有几万甚至百万条请求,如果使用everysec的方式的话,万一服务器挂了那几万条数据就丢失了)。

1、开启AOF

联系管理员微信tutu19192010,注册账号

上一篇
下一篇
Copyright © 2022 Egon的技术星球 egonlin.com 版权所有 帮助IT小伙伴学到真正的技术