首页 > 数据库学习 > NOSQL > Redis的持久化
2019
09-03

Redis的持久化

Redis提供了两种不同级别的持久化方式:

RDB持久化可以在指定的时间间隔内生成数据集的时间点快照。

AOF持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。AOF文件中的命令全部以Redis协议的格式来保存,新命令会被追加到文件的末尾。

可以同时使用AOF持久化和RDB持久化,当Redis重启时,会优先使用AOF文件来还原数据集,因为AOF文件所保存的数据通常是最完整的。

RDB的优点

RDB是一个非常紧凑的文件,它保存了Redis在某个时间点上的数据集,非常适合用于进行备份。

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

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

RDB的缺点

在数据集比较庞大时,fork()可能会非常耗时,造成服务器在某段时间内停止处理客户端;

每隔一段时间才保存一次RDB文件,在这种情况下,一旦发生故障停机,你就可能会丢失好这段时间的数据。

AOF的优点

使用AOF持久化会让Redis变得非常耐久:可以设置不同的fsync策略,默认为每秒钟fsync一次,在这种配置下,Redis仍然可以保持良好的性能,并且就算发生故障停机,也最多只会丢失一秒钟的数据(fsync会在后台线程执行,所以主线程可以继续努力地处理命令请求)

AOF文件是一个只进行追加操作的日志文件,因此对AOF文件的写入不需要进行seek,即使因为某些原因而包含了未写入完整的命令,redis-check-aof工具也可以轻易地修复这种问题。

AOF文件有序地以Redis协议的格式保存了对数据库执行的所有写入操作, 因此AOF文件的内容非常容易被人读懂, 对文件进行分析也很轻松。如果不小心执行了flushall命令, 但只要AOF文件未被重写,那么只要停止服务器, 移除AOF文件末尾的FLUSHALL命令并重启Redis,就可以将数据集恢复到flushall执行之前的状态。

AOF的缺点

对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积。

根据所使用的fsync策略,AOF的速度可能会慢于RDB。 在一般情况下,每秒fsync的性能依然非常高,即使在高负荷之下也是如此。不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间(latency)。

AOF文件重写

Redis可以在后台对AOF文件进行重写,重写后新AOF文件包含了恢复当前数据集所需的最小命令集合。
以下是 AOF 重写的执行步骤:

    Redis执行fork() ,现在同时拥有父进程和子进程。 
    子进程开始将新AOF文件的内容写入到临时文件。 
    对于所有新执行的写入命令,父进程一边将它们累积到一个内存缓存中,一边将这些改动追加到现有的旧AOF文件的末尾。 
    当子进程完成重写工作时,它给父进程发送一个信号,父进程在接收到信号之后,将内存缓存中的所有数据追加到新AOF文件的末尾。 
    最后Redis原子地用新文件替换旧文件,之后所有命令都会直接追加到新 AOF 文件的末尾。

服务器在AOF功能开启的情况下,会维持以下三个变量:

    记录当前AOF文件大小的变量aof_current_size
    记录最后一次AOF重写之后,AOF文件大小的变量aof_rewrite_base_size
    自最后一次重写之后AOF文件增长的百分比变量aof_rewrite_perc

配置文件中指定自动重写的AOF文件最小体积和自最后一次重写之后AOF文件增长的百分比,当两个条件都满足时会自动进行AOF文件重写

    auto-aof-rewrite-min-size:自动运行AOF重写时AOF文件最小体积,默认为67108864(64MB)
    auto-aof-rewrite-percentage:自最后一次重写之后AOF文件增长的百分比大于指定值才进行自动AOF重写,默认值100(不包含百分号)

RDB和AOF之间的相互作用

在版本号大于等于2.4的Redi中,bgsave和bgrewriteaof不可以同时执行。防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

如果其中一个正在执行, 并且用户显示地调用另一个命令, 那么服务器将向用户回复一个OK状态, 并告知用户,另一个已经被预定执行

持久化命令:

bgrewriteaof:AOF文件重写命令(创建一个当前AOF文件的体积优化版本),如果已经有别的AOF文件重写在执行,那么返回一个错误

save

    执行一个同步保存操作,将当前Redis实例的所有数据快照以rob文件的形式保存到硬盘
    一般来说,在生产环境很少执行save操作,因为它会阻塞所有客户端,保存数据库的任务通常由bgsave命令异步地执行。
    如果负责保存数据的后台子进程不幸出现问题时,save可以作为保存数据的最后手段来使用。
    保存成功时返回OK

bgsave

    在后台异步(Asynchronously)保存当前数据库的数据到磁盘
    命令执行之后立即返回OK,然后fork出一个新子进程,负责将数据保存到磁盘,然后退出
    客户端可以通过lastsave命令查看相关信息,判断BGSAVE命令是否执行成功

lastsave:返回最近一次成功将数据保存到磁盘上的时间,以UNIX时间戳格式表示

最后编辑:
作者:qingheluo
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。