专栏首页阿Q说代码面试官:你说你精通Redis,你看过持久化的配置吗?

面试官:你说你精通Redis,你看过持久化的配置吗?

前边我们已经介绍了Redis五种数据类型的命令配置文件的基本配置,今天让我们从理论和配置两个层面来揭开Redis持久化的神秘面纱。

所谓持久化可以简单理解为将内存中的数据保存到硬盘上存储的过程。持久化之后的数据在系统重启或者宕机之后依然可以进行访问,保证了数据的安全性。

Redis有两种持久化方案,一种是快照方式(SNAPSHOTTING),简称RDB;一种是只追加模式(APPEND ONLY MODE),称为AOF。接下来让我们分别了解一下它们的使用与注意事项。

RDB

RDBRedis DataBase的缩写,是 Redis 默认的持久化方案。它能够在指定的时间间隔内将内存数据集快照(snapshot)写入磁盘,恢复时将快照文件( dump.rdb )读回内存。

我们先来扒一下配置文件中的SNAPSHOTTING:

配置文件

save <seconds> <changes>

在给定的秒数内,如果对数据库执行的写入操作数达到设定的值,则将数据同步到数据文件。支持多个条件配合,Redis默认配置文件中提供了三个条件:

save 900 1 //900s内有1个更改
save 300 10 //300s内有10个更改
save 60 10000 //60s内有10000次更改

注意:若不想用RDB方案,可以把 save ""的注释打开,上边三个注释掉。

stop-writes-on-bgsave-error yes

bgsave出现错误时,Redis是否停止执行写命令;

  • 如果为yes,则当硬盘出现问题时,Redis将停止接受写入操作,这样我们可以及时发现,避免数据的大量丢失;
  • 如果为no,则Redis无视bgsave的错误继续执行写命令。

如果已经设置了对Redis服务器的正确监视和持久性,即采用了其他手段发现和控制数据完整性,可能希望禁用此功能,以便即使在磁盘、权限等方面出现问题时,Redis仍能正常工作。

注意:如果后台保存过程将再次开始工作,Redis将自动允许再次写入。

rdbcompression yes

指定存储到本地数据库时是否压缩Redis采用LZF压缩)数据,默认为yes。如果为了节省CPU时间,可以关闭该选项,但会导致数据库文件变得巨大。

rdbchecksum yes

RDB版本5开始,在存储快照后,还可以使用CRC64算法来进行数据校验,CRC64校验放在文件的末尾。开启之后,保存和加载RDB文件时会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能。

禁用校验和创建的RDB文件的校验和为零,这将告诉加载代码跳过检查。

dbfilename dump.rdb

指定本地数据库文件名,重启之后自动加载进内存,手动执行save 命令的话即刻生效。

大坑请注意flushallshutdown命令都会清空并提交至dump.rdb

dir ./

指定本地数据库存放目录。

理论

工作方式

  • Redis 需要保存dump.rdb文件时,它会调用系统函数fork(),创建一个子进程(与主进程完全一致);
  • 子进程将数据集写入临时文件RDB中;
  • 当子进程完成对新 RDB 文件的写入时,Redis 用新 RDB 文件替换原来的 RDB 文件,并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制(copy-on-write)机制中获益。

如何触发RDB快照

  1. 配置文件中默认的快照配置;
  2. 命令save(阻塞, 只管保存快照,其他的等待)或者是bgsave(异步)命令,快照同时还可以响应客户端命令;
  3. 执行flushall 命令,清空数据库所有数据,意义不大;
  4. 执行shutdown 命令,保证服务器正常关闭且不丢失任何数据,意义也不大。

通过RDB文件恢复数据

在实际开发中,一般会考虑到物理机硬盘损坏的情况,所以我们会选择备份dump.rdb文件。将备份的dump.rdb 文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。

优点

  • RDB是一个非常紧凑的文件,非常适用于数据集的备份;
  • RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3(可能加密),非常适用于灾难恢复;
  • Redis的主进程不进行I/O操作,确保了极高的性能;
  • 适合大规模数据的恢复,对于数据的完整性和一致性要求不高的话,RDBAOF方式更加高效。

缺点

  • Redis意外宕机时,你可能会丢失几分钟的数据;
  • RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒;AOF也需要fork,但是可以调节重写日志文件的频率来提高数据集的耐久度。

AOF

为了解决RDB方式在宕机时丢失数据过多的问题,从1.1 版本开始,Redis增加了一种durable的持久化方式:AOF

AOFAppend Only File的缩写,默认不开启。AOF以日志的形式来记录每个写操作,只允许追加文件但不可以改写文件,当服务器重启的时候会重新执行这些命令来恢复原始的数据。

我们再来看一下配置文件中的APPEND ONLY MODE:

配置文件

appendonly no

默认为关闭状态,改为yes打开持久化。AOFRDB可以同时启用而不会出现问题。

appendfilename "appendonly.aof"

文件默认名称,启动即创建。加载先于dump.rdb文件

appendfsync

同步策略:系统函数fsync() 告诉操作系统在磁盘上实际写入数据。Redis支持三种不同的模式

appendfsync always //每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好
appendfsync everysec //默认推荐,异步操作,每秒记录,如果宕机,有1秒内数据丢失
appendfsync no //不同步,只有在操作系统需要时在刷新数据

要想了解接下来的配置内容,先得说一下“日志重写”的原理:

重写

由于AOF采用的是将命令追加到文件末尾的方式,所以随着写入命令的不断增加,AOF文件的体积会变得越来越大。为避免出现此种情况,新增了重写机制:可以在不打断服务客户端的情况下,对AOF文件进行重建(rebuild)。

重写触发: 通过执行bgrewriteaof命令,可以生成一个新的AOF文件,该文件包含重建当前数据集所需的最少命令。Redis 2.2需手动执行该命令,Redis 2.4则可以通过修改配置文件的方式自动触发(配置在下边涉及)。

重写原理:

  • Redis 执行系统函数fork() ,创建一个子进程(与主进程完全一致);
  • 子进程开始将新 AOF 文件的内容写入到临时文件;
  • 对于所有新执行的写入命令,父进程一边将它们累积到一个内存缓存中,一边将这些改动追加到现有 AOF 文件的末尾,这样即使在重写的中途发生停机,现有的 AOF 文件也是安全的;
  • 当子进程完成重写工作时,它给父进程发送一个信号,父进程在接收到信号之后,将内存缓存中的所有数据追加到新 AOF 文件的末尾。
  • Redis 原子地用新文件替换旧文件,之后所有命令都会直接追加到新 AOF文件的末尾。

no-appendfsync-on-rewrite no

当我们同时执行主进程的写操作和子进程的重写操作时,两者都会操作磁盘,而重写往往会涉及到大量的磁盘操作,这样就会造成主进程在写aof文件的时候出现阻塞的情形。

为了解决这个问题,no-appendfsync-on-rewrite参数出场了。

  • 如果该参数设置为no,是最安全的方式,不会丢失数据,但是要忍受阻塞的问题;
  • 如果设置为yes,这就相当于将appendfsync设置为no,这说明并没有执行磁盘操作,只是写入了缓冲区。因此这样并不会造成阻塞(因为没有竞争磁盘),但是如果这个时候redis挂掉,就会丢失数据。丢失多少数据呢?在linux的操作系统的默认设置下,最多会丢失30s的数据。

因此,如果应用系统无法忍受延迟,而可以容忍少量的数据丢失,则设置为yes;如果应用系统无法忍受数据丢失,则设置为no

auto-aof-rewrite-percentage 100

重写百分比,默认为上次重写后aof文件大小的一倍。

auto-aof-rewrite-min-size 64mb

重写触发的最小值:64mb。

根据auto-aof-rewrite-min-sizeauto-aof-rewrite-percentage参数确定自动触发时机。Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

大型互联网公司一般都是3G起步

aof-load-truncated yes

AOF文件被截断时,即AOF文件的最后命令不完整,如果此时启动Redis,会将AOF数据加载回内存,此时便会出现问题。

  • yes:加载一个截断的AOFRedis服务器开始发出日志,通知用户该事件;
  • no:服务器将中止并出现错误,拒绝启动。

当我们得知AOF文件报错时,可以用以下方法来修复出错的 AOF 文件:

  • 为现有的 AOF文件创建一个备份;
  • 使用 Redis 附带的 redis-check-aof 命令,对原来的AOF文件进行修复;
    • redis-check-aof –fix
    • redis-check-aof --fix appendonly.aof 修复命令,杀光不符合规范的语法
  • 可选)使用 diff -u 对比修复后的 AOF文件和原始 AOF 文件的备份,查看两个文件之间的不同之处;
  • 重启 Redis服务器,等待服务器载入修复后的 AOF文件,并进行数据恢复。

aof-use-rdb-preamble yes

在重写AOF文件时,Redis能够在AOF文件中使用RDB前导,以加快重写和恢复速度。启用此选项后,重写的AOF文件由两个不同的节组成:RDB fileAOF tail

加载Redis时,会识别AOF文件以Redis字符串开头,并加载带前缀的RDB文件,然后继续加载AOF尾部。

理论

优点

  • 数据的完整性和一致性更高,AOF的持久化通过使用不同的策略,最多丢失1秒的数据;
  • AOF文件是一个只进行追加的日志文件,不需要写入seek
  • Redis可以在 AOF文件体积变得过大时,自动地在后台对 AOF 进行重写,重写操作是绝对安全的;
  • AOF文件记录的写入操作以Redis协议的格式保存,容易读懂,容易对文件进行分析;

缺点

  • 对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积;
  • 根据所使用的 fsync 策略,AOF的速度可能会慢于RDB

在一般情况下,每秒 fsync 的性能依然非常高,而关闭 fsync 可以让 AOF 的速度和 RDB 一样快, 即使在高负荷之下也是如此。不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间(latency)。

对比与总结

如何选择使用哪种持久化方式?

一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性,应该同时使用两种持久化功能。

如果非常关心数据,但仍然可以承受数分钟以内的数据丢失,那么可以只使用 RDB 持久化。

由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式。

有很多用户都只使用AOF持久化,但我们并不推荐这种方式:因为定时生成 RDB 快照(snapshot)非常便于进行数据库备份,并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

AOF和RDB之间的相互作用

在版本号大于等于 2.4Redis 中,BGSAVE 执行的过程中,不可以执行 BGREWRITEAOF 。反过来说,在 BGREWRITEAOF 执行的过程中,也不可以执行 BGSAVE。这可以防止两个 Redis 后台进程同时对磁盘进行大量的I/O 操作。

如果 BGSAVE 正在执行,并且用户显示地调用 BGREWRITEAOF 命令,那么服务器将向用户回复一个 OK 状态, 并告知用户BGREWRITEAOF 已经被预定执行:一旦 BGSAVE 执行完毕,BGREWRITEAOF就会正式开始。

Redis 启动时,如果 RDB持久化和 AOF 持久化都被打开了, 那么程序会优先使用 AOF 文件来恢复数据集,因为 AOF文件所保存的数据通常是最完整的。

备份redis数据

  • 创建一个定期任务(cron job),每小时将一个 RDB 文件备份到一个文件夹,并且每天将一个 RDB 文件备份到另一个文件夹;
  • 确保快照的备份都带有相应的日期和时间信息,每次执行定期任务脚本时,使用 find 命令来删除过期的快照;
  • 至少每天一次,将 RDB 备份到你的数据中心之外,或者至少是备份到你运行 Redis 服务器的物理机器之外。

性能建议

在实际应用时,因为RDB文件只用作后备用途,建议只在slave上持久化RDB文件,而且只需要15分钟备份一次就够了,只保留save 900 1这条规则。

如果开启AOF,好处是在最恶劣情况下也只会丢失不超过2秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设置到5G以上。默认超过原大小的100%时重写可以改到适当的数值。

如果不开启AOF,仅靠Master-Slave Replication实现高可用性也可以。能省掉一大笔IO,也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。

以上就是今天的全部内容了,如果你有不同的意见或者更好的idea,欢迎联系阿Q,添加阿Q可以加入技术交流群参与讨论呦!

觉得还不错?记得一键四连呦👇

本文分享自微信公众号 - 阿Q说代码(AQ_Shuo),作者:阿Q

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-09-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 搞清楚这 10 几个后端面试问题,工作稳了!

    面试过程是一个由浅入深的过程,面试官先给求职者抛出一个相对简单的问题,然后通过一环套一环的追问深入考察求职者对知识点的理解掌握程度。

    JAVA日知录
  • Redis 到底是单线程还是多线程?我要吊打面试官!

    这个问题你要从多个方面回答,如果你仅仅只回答 "单线程" 肯定是说不过去的,为什么呢?

    Java技术栈
  • 金山wps服务端二面面经

    前言:阿婆主很久很久没写过面经了,之所以写这篇面经是真的感觉wps相关的面经太少啦,既然有机会面试那就写一篇吧 直接上啦---> 协程和线程,比如协程底层的实现...

    牛客网
  • 史上最全Redis面试题及答案。

    花了大量时间 整理了这套Redis面试题 首发50题,绝无仅有 从入门到精通 从基础,高级知识点 再到集群,运维,方案… 弄明白了这些题 可以说可以成为面霸了 ...

    Java技术栈
  • 《【面试突击】— Redis篇》-- Redis哨兵原理及持久化机制

    《【面试突击】— Redis篇》--Redis的线程模型了解吗?为啥单线程效率还这么高?

    编程大道
  • 分布式id生成策略,我和面试官扯了一个半小时

    我心想:我去,怎么会不记得,我又不是青年痴呆,上次害我画了那么多图,还使劲敲了一个多钟的电脑,满脑子都是你的阴影。

    用户1564362
  • 其实吧,LRU也就那么回事。

    这个算法的思想就是:如果一个数据在最近一段时间没有被访问到,那么在将来它被访问的可能性也很小。所以,当指定的空间已存满数据时,应当把最久没有被访问到的数据淘汰。

    why技术
  • Redis 用的很溜,了解过它用的什么协议吗?

    他说,事情是这样的,刚开始,问了一些基础的问题,比如 Redis 的几种基本数据类型和使用场景,以及主从复制和集群的一些问题,这些都还好。

    古时的风筝
  • 非常值得一看的35个Redis面试题总结(二)

    在Redis当中,有生存期的key被称为volatile。在创建缓存时,要为给定的key设置生存期,当key过期的时候(生存期为0),它可能会被删除。

    互扯程序
  • Java工程师:非科班自学Java是如何获得校招offer的

    背景介绍 楼主某末流985渣硕一枚,磕盐不会,偶然接触了下编程,然后又稍微学了学Java,后面就走上了程序猿的道路,今年四月侥幸去菊厂实习了一波(虽然没学到东...

    牛客网
  • 【Java面经】非科班渣硕面经

    楼主某末流985渣硕一枚,磕盐不会,偶然接触了下编程,然后又稍微学了学Java,后面就走上了程序猿的道路,今年四月侥幸去菊厂实习了一波(虽然没学到东西)。

    牛客网
  • Redis专题(1):构建知识图谱

    思考:很明显,小明同学在面试过程中关于Redis的表现和回答肯定是比较失败的。Redis是我们工作中每天都会使用到的东西,为什么一到面试却变成了丢分项呢?

    宜信技术学院
  • Redis面试题(2021最新版)

    作为一个后端开发人员,不只是要求开发人员需要掌握 Redis,也要求运维人员也要懂 Redis。由于 Redis 的运用广泛,我们也知道它的重要性,至此面试中经...

    Java程序猿
  • 30道Redis面试题,面试官能问的都被我找到了

    Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到...

    lyb-geek
  • 2020预备春招BAT面试题汇总:MyBatis +微服务+多线程+Spring+分布式

    本文收集整理了各大厂常见面试题N道,你想要的这里都有内容涵盖:Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcac...

    架构师修行之路
  • 一文详细揭秘 Redis 持久化,了解一下?

    Redis 是一个开源( BSD 许可)的,内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件。它支持的数据类型很丰富,如字符串、链表、集 合、以及散...

    崔庆才
  • 2021年突破年薪百万难关!吃透这套Java真题合集

    我相信大多 Java 开发的程序员或多或少经历过BAT一些大厂的面试,也清楚一线互联网大厂 Java 面试是有一定难度的,小编经历过多次面试,有满意的也有备受打...

    Java程序猿
  • 分享30道Redis面试题,面试官能问到的我都找到了

    Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到...

    技术zhai
  • 虚度大一一年又如何,双非本科大三学弟连斩腾讯字节

    有通过自己的努力艰难爬坑社招去长沙多益做游戏开发的,也有校招实习去腾讯 WXG 部门的,还有去字节抖音的,真的太牛逼了。

    拓跋阿秀

扫码关注云+社区

领取腾讯云代金券