ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

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

2022-02-21 08:34:38  阅读:192  来源: 互联网

标签:AOF everysec 14 fsync Redis 源码 RDB data


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

参考链接

Redis 源码简洁剖析系列

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

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

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

标签:AOF,everysec,14,fsync,Redis,源码,RDB,data
来源: https://www.cnblogs.com/510602159-Yano/p/15917341.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有