大数据必学:深入了解 Redis 的持久化机制

因为 redis是一个内存数据库,所有数据都存储在内存中,而且内存中的数据非常容易丢失,所以 redis的数据持久化就变得非常重要, redis提供了两种数据持久化方法,分别用于 RDB和 AOF,而 redis默认用于 RDB的数据持久化方法。

一、RDB持久性方案简介

RDB方案简介:

Redis将定期将数据快照保存到 rdb文件中,并在启动时自动装入 rdb文件,以恢复之前保存的数据。可将 Redis配置为在配置文件中保存快照。

save [seconds] [changes]

意思是[seconds]秒内如果发生了[changes]次数据修改,则进行一次RDB快照保存,例如:

save 60 100

每隔60秒 Redis就会检查一次数据更改,如果发生了100次或更多的数据更改,将保存 RDB快照。多个 save指令可以进行配置, Redis可以执行多层快照保存策略。默认打开 RDB快照。RDB快照保存还可以通过 SAVE或 BGSAVE命令手动触发。

在 SAVE和 BGSAVE命令中, rdbSave函数都被调用,但是它们以不同的方式调用:

1、在保存完成之前, SAVE直接调用 rdbSave来阻塞 Redis主进程。服务器无法在主进程阻塞期间处理客户机的任何请求。

2、而 BGSAVE则把子进程 fork出来,该进程负责调用 rdbSave,并在保存完成后向主进程发出通知,告知保存完成。在 BGSAVE执行过程中, Redis服务器仍可继续处理客户机请求。

RDB方案好处:

1、最低限度的性能影响。如前所述,当保存 RDB快照时, Redis将对 fork出子进程执行,这几乎不会影响 Redis处理客户机请求的效率。

2、每一张快照都会产生一个完整的数据快照文件,因此可以用其他方法来同时保存多个时间点的快照(例如将每天0点的快照备份到其他存储介质),作为非常可靠的灾难恢复方法。

3、与 AOF相比,使用 RDB文件的数据恢复更快

RDB模式缺陷:

1、快照是定期生成的,因此当使用 Redis crash时,数据的一部分或多或少会丢失。

2、当数据集非常大, CPU不够强时(例如单核 CPU), Redis可能会花费相对较长的 fork子进程时间,从而影响 Redis外部服务的提供。

RDB方案配置:

修改redis的配置文件:

重启 redis Service

每生成一个新的 dump. rdb,就覆盖以前的旧快照

二、AOF持久化方案简介

1、AOF方案简介:

AOF (append only file)持久化:将每个写入命令以独立日志的方式记录下来,重启后再重新执行 AOF文件中的命令,以实现数据恢复。AOF的主要功能是处理数据持久的实时性,目前, AOF已成为 Redis持久性的主流方式。了解掌握 AOF的持久性机制对于我们处理数据安全和性能方面非常有帮助。

2、运用AOF:

打开 AOF功能要求进行设置配置: appendonlyyes,默认不启用。通过 appendfilename配置设置 AOF文件名,默认的文件名是appendonly.ao f。通过 dir配置指定,保存路径与 RDB持久化方式一致。AOF工作流程操作 :命令写入(append),文件同步(sync),文件重写(rewrite),重新启动装载(load),如图所示。

执行流程:

1、所有的写入命令会追加到aof_buf(缓冲区)中。

2、根据相应的策略, AOF缓冲区对硬盘进行同步操作。

3、当 AOF文件变得更大时,需要定期重写 AOF文件,以实现压缩。

4、重启 Redis服务器后,可以加载用于数据恢复的 AOF文件。

3、文件同步:

Redis提供了多种 AOF缓冲同步文件策略,这些策略由 appendfsync参数控制,图中显示了不同值的含义。

3.1、当配置为 always时,每次写入都会同步 AOF文件,而在普通 SATA硬盘上, Redis只支持大约数百 TPS写入,这显然与 Redis的高性能特性背道而驰,因此不推荐使用。

3.2、配置为 no,因为操作系统对 AOF文件的每一次同步都是不可控制的周期,并且会增加每一次同步硬盘的数据量,虽然提高了性能,但是数据安全没有保障。

3.3、配置为 everysec,建议采用同步策略和默认策略,以兼顾性能和数据安全。

4、重写机制:

AOF会随着命令的执行而变大,为了解决这个问题, Redis引入了 AOF覆盖机制来压缩文件。AOF文件覆盖是将 Redis进程中的数据转换成写入命令,使其与新 AOF文件同步的过程。

为什么覆盖了 AOF的文件可以变小?原因如下:

1、已在进程中超时的数据不再写入文件。

2、以前的 AOF文件中包含诸如 delkey1, hdelkey2, srem keys,seta111, seta222等等无效命令。覆盖直接使用进程中的数据生成,因此新的 AOF文件只保存最终数据的写入命令。

3、可以将多个写命令合并成一个,例如: lpush list a,、lpush list b、lpush list c可转换为: lpush list a b c 。为避免单个命令太大导致客户端缓冲区溢出,对于 list, set, hash, zset之类的类型操作,将多个元素分割成64个界限。

AOF重写减少了文件占用空间,除此之外,还有另外一个目的: Redis可以更快地加载更小的 AOF文件。

可手动或自动触发 AOF重写过程:

手动触发:直接调用命令 bgrewriteaof。

自动触发:Auto-aof-rewrite-min-size和Auto-aof-rewrite-percentage参数决定了自动触发的时间点。

解释:

1、auto-aof-rewrite-min-size:表示在运行 AOF覆盖时,文件的最小体积,默认值为64 MB。

2、auto-aof-rewrite-percentage:表示 AOF文件空间(aof_current_size)与上次重写后的 AOF文件空间之间的比值。

3、自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&(aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage

AOF场景配置:

1、在 redis中, aof的持久化机制默认关闭

2、AOF持久化默认为关闭的 ,RDB持久化默认为打开

3、appendonly yes,能够打开 AOF持久机制,在生产环境中,通常 AOF都会被打开,除非你不介意数据被随意丢失几分钟

4、在打开 AOF持久化机制后, redis每次收到写命令时,都会将其写入日志文件,当然是先写入 os cache,然后每隔一段时间再进行 fsync

5、当 AOF和 RDB都打开并且 redis重新启动时,优先使用 AOF恢复数据,因为 aof数据比较完整

AOF的 fsync策略可以进行配置,有三种策略可供选择:

1、一种是每次写入数据时都执行一次 fsync。

2、另一种是每隔一秒执行一次 fsync。

3、另一种是不主动执行 fsync。

always:每写一次,就把相应于该数据的写日志 fsync放到磁盘上,性能非常糟糕,吞吐量也很低;要确保说 redis中的一个数据不会丢失,只能这样。

redis中的默认 AOF持久性机制全部关闭

Redis的AOF持久化机制配置:

重新启动 redis实例,并在执行简单操作后关闭该实例,重新启动 redis实例。

三、重启加载流程:

如果觉得对你有所帮助。记得收藏和关注呦!(每日更新各种大数据框架)

如需转载请注明出处(创作不易请见谅)

和巨婴程序猿一起成长。让自己变得更优秀

想了解更多精彩内容,快来关注跟着巨婴去逆袭

我最近一直在思考(大数据通俗讲解)的问题,你的看法是什么呢?关注我快说出来一起交流一下吧~

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20200711A08SC900?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券