Redis教程

Redis 源码简洁剖析 14 - Redis 持久化

本文主要是介绍Redis 源码简洁剖析 14 - Redis 持久化,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
  • Redis 持久化方式
  • RDB
    • 优势
    • 劣势
  • AOF
    • 优势
    • 劣势
      • Redis < 7.0
  • 参考链接
  • Redis 源码简洁剖析系列

Redis 持久化方式

主要参考 Redis 官方文档:Redis Persistence。共有 4 种持久化方式:

  • RDB (Redis Database):以指定的时间间隔执行数据在某个时间点的快照。
  • AOF (Append Only File):AOF 持久化记录服务器接收到的每个写操作。Redis server 在启动时会重放这些操作,进而重建数据。记录的命令与 Redis 协议的格式相同,并且是以追加的方式记录。当日志变得太大时,Redis 能够在后台 重写 日志。
  • No persistence:用户也可以完全禁用持久性,数据只在内存中使用。
  • RDB + AOF:可以在同一个实例中结合 AOF 和 RDB。在这种情况下,Redis 重启时会使用 AOF 文件重建原始数据,因为它是最完整的。

RDB

优势

  • RDB 是 Redis 数据在某个时间点的文件,格式非常紧凑,非常适合作为备份。比如我们可以在最近的 24 小时内,每小时归档一个 RDB 文件,并在 30 天内每天保存一次 RDB 快照。这样我们可以轻松恢复不同版本的数据。
  • RDB 非常适合灾难恢复,RDB 文件是可以传输的单个紧凑文件。
  • RDB 提升 Redis 的性能,因为 Redis 父进程为了持久化而做的唯一操作,就是派生一个将完成其余所有操作的子进程。
  • 与 AOF 相比,RDB 在大数据集恢复时更迅速。

劣势

  • RDB 在 Redis 宕机的情况下,更容易丢失数据。如果我们每 5 分钟创建一次 RDB 快照,如果 Redis 没有正常关闭,那最新几分钟的数据就会丢失。
  • RDB 需要经常 fork() 出在磁盘上持久化的子进程。在数据很大、CPU 性能不好时,会导致 Redis 在几毫秒甚至一秒内不对外服务。

AOF

以独立日志的方式,记录每次写命令,重启时再重新执行 AOF 文件中的命令,进而回复数据。相对于 RDB 的记录数据,AOF 是记录数据产生的过程

优势

  • 服务宕机时丢失数据更少,比如仅丢失最后 1s 的数据。
  • AOF 日志只是附加日志,不会出现寻道问题,也不会在断电时出现损坏。
  • AOF 日志易于理解和解析,包含所有操作。

劣势

  • AOF 文件比相同数据集的 RDB 文件大。
  • 取决于具体的 fsync 策略,AOF 可能比 RDB 慢。

Redis < 7.0

  • 在重新期间对数据库的写入,AOF 可能占用大量内存(缓冲在内存中,并在最后写入新的 AOF)。
  • 重写期间,所有写入的命令都会写入磁盘两次。

在 redis.conf 中,可以看到 appendfsync 有 3 个值:

  • no: don't fsync, just let the OS flush the data when it wants. Faster.
  • always: fsync after every write to the append only log. Slow, Safest.
  • everysec: fsync only one time every second. Compromise.
# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

参考链接

  • 19 | AOF 重写(上):触发时机与重写的影响
  • Redis Persistence

Redis 源码简洁剖析系列

最简洁的 Redis 源码剖析系列文章

Java 编程思想-最全思维导图-GitHub 下载链接,需要的小伙伴可以自取~

原创不易,希望大家转载时请先联系我,并标注原文链接。

这篇关于Redis 源码简洁剖析 14 - Redis 持久化的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!