2. 对比redis的RDB、AOF模式的优缺点

2022/9/3 2:24:47

本文主要是介绍2. 对比redis的RDB、AOF模式的优缺点,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

2. 对比redis的RDB、AOF模式的优缺点

 

2.1  redis的RDB模式

2.1.1 RDB 模式工作原理

 

 

RDB(Redis DataBase):基于时间的快照,其默认只保留当前最新的一次快照,特点是执行速度比较快,缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据。

RDB bgsave 实现快照的具体过程:

 

Redis从master主进程先fork出一个子进程,使用写时复制机制,子进程将内存的数据保存为一个临时文件,比如:tmp-.rdb,当数据保存完成之后再将上一次保存的RDB文件替换掉,然后关闭子进程,这样可以保证每一次做RDB快照保存的数据都是完整的。

 

因为直接替换RDB文件的时候,可能会出现突然断电等问题,而导致RDB文件还没有保存完整就因为突然关机停止保存,而导致数据丢失的情况.后续可以手动将每次生成的RDB文件进行备份,这样可以最大化保存历史数据。

 

2.1.2 RDB 相关配置

save 900 1         #900s内修改了1个key即触发保存RDB

save 300 10        #300s内修改了10个key即触发保存RDB

save 60 10000      #60s内修改了10000个key即触发保存RDB

dbfilename dump.rdb

dir ./  #编泽编译安装,默认RDB文件存放在启动redis的工作目录,建议明确指定存入目录。

stop-writes-on-bgsave-error yes

rdbcompression yes

rdbchecksum yes

 

 

2.1.3 实现RDB方式

 

save: 同步,会阻赛其它命令,不推荐使用。

bgsave: 异步后台执行,不影响其它命令的执行。

自动: 制定规则,自动执行。

 

 

2.1.4 RDB 模式优点

RDB快照保存了某个时间点的数据,可以通过脚本执行redis指令bgsave(非阻塞,后台执行)或者save(会阻塞写操作,不推荐)命令自定义时间点备份,可以保留多个备份,当出现问题可以恢复到不同时间点的版本,很适合备份,并且此文件格式也支持有不少第三方工具可以进行后续的数据分析。

比如: 可以在最近的24小时内,每小时备份一次RDB文件,并且在每个月的每一天,也备份一个RDB文件。这样的话,即使遇上问题,也可以随时将数据集还原到不同的版本。

RDB可以最大化Redis的性能,父进程在保存 RDB文件时唯一要做的就是fork出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。

RDB在大量数据,比如几个G的数据,恢复的速度比AOF的快。

 

2.1.5  RDB 模式缺点

不能实时保存数据,可能会丢失自上一次执行RDB备份到当前的内存数据。

 

如果你需要尽量避免在服务器故障时丢失数据,那么RDB并不适合。虽然Redis允许设置不同的保存点(save point)来控制保存RDB文件的频率,但是,因为RDB文件需要保存整个数据集的状态,所以它并不是一个轻松快速的操作。因此一般会超过5分钟以上才保存一次RDB文件。在这种情况下,一旦发生故障停机,你就可能会丢失好几分钟的数据。

 

当数据量非常大的时候,从父进程fork子进程进行保存至RDB文件时需要一点时间,可能是毫秒或者秒,取决于磁盘IO性能。在数据集比较庞大时,fork()可能会非常耗时,造成服务器在一定时间内停止处理客户端﹔如果数据集非常巨大,并且CPU时间非常紧张的话,那么这种停止时间甚至可能会长达整整一秒或更久。

 

虽然 AOF重写也需要进行fork(),但无论AOF重写的执行间隔有多长,数据的持久性都不会有任何损失。

 

 

2.2  redis的AOF模式

2.2.1  AOF模式工作原理

 

 

AOF:AppendOnylFile,按照操作顺序依次将操作追加到指定的日志文件末尾。

 

AOF 和 RDB 一样使用了写时复制机制,AOF默认为每秒钟 fsync一次,即将执行的命令保存到AOF文件当中,这样即使redis服务器发生故障最多只丢失1秒钟之内的数据,也可以设置不同的fsync策略。

 

fsync策略:

Always:即设置每次执行命令的时候执行fsync,fsync会在后台执行线程,所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的I/O影响,同时启用RDB和AOF,进行恢复时,默认AOF文件优先级高于RDB文件,即会使用AOF文件进行恢复。

 

注意: AOF 模式默认是关闭的,第一次开启AOF后,并重启服务生效后,会因为AOF的优先级高于RDB,而AOF默认没有数据文件存在,就会覆盖RDB文件,从而导致所有数据丢失。

 

 

 

2.2.2  AOF模式优点

 

数据安全性相对较高,根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存储设备),默认是appendfsync everysec,即每秒执行一次 fsync,在这种配置下,Redis 仍然可以保持良好的性能,并且就算发生故障停机,也最多只会丢失一秒钟的数据( fsync会在后台线程执行,所以主线程可以继续努力地处理命令请求)

 

由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中不需要seek, 即使出现宕机现象,也不会破坏日志文件中已经存在的内容。如果本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,可以通过 redis-check-aof 工具来解决数据一致性的问题。

 

Redis可以在 AOF文件体积变得过大时,自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的,因为Redis在创建新 AOF文件的过程中,append模式不断的将修改数据追加到现有的 AOF文件里面,即使重写过程中发生停机,现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕,Redis就会从旧AOF文件切换到新AOF文件,并开始对新AOF文件进行追加操作。

 

AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,也可以通过该文件完成数据的重建。

 

 

2.2.3  AOF模式缺点

 

即使有些操作是重复的也会全部记录且AOF 的文件大小要大于 RDB 格式的文件。

 

AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢。

 

根据fsync策略不同,AOF速度可能会慢于RDB。

 

bug 出现的可能性更多。

 

 

2.2.4  RDB和AOF 的选择

 

如果主要充当缓存功能,或者可以承受数分钟数据的丢失, 通常生产环境一般只需启用RDB即可,此也是默认值。

 

如果数据需要持久保存,一点不能丢失,可以选择同时开启RDB和AOF,一般不建议只开启AOF。

 



这篇关于2. 对比redis的RDB、AOF模式的优缺点的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程