关于redis:我所理解的-Redis-AOF-持久化

42次阅读

共计 889 个字符,预计需要花费 3 分钟才能阅读完成。

介绍

Redis 是内存型数据库,一旦主过程退出就会造成数据失落。它的长久化次要有两大机制,即 AOF 日志和 RDB 快照,本文次要关怀 AOF 日志。

过程

Redis 执行完一个写命令后,将写命令以协定文本的模式追加到 AOF 缓冲区开端,再通过 同步策略 来决定是否将 AOF 缓冲区中的内容写入 & 同步到 AOF 日志。

同步策略

AOF 机制提供了三个抉择,也就是配置项 appendfsync 的三个可选值:

  • always:将 AOF 缓冲区中的所有内容 写入 同步 AOF 日志。
  • everysec:将 AOF 缓冲区中的所有内容 写入 AOF 日志,如果上次同步 AOF 日志的工夫间隔当初超过 1 秒钟,那么对 AOF 日志进行 同步
  • no:将 AOF 缓冲区中的所有内容 写入 到 AOF 日志,但并不对 AOF 日志进行 同步,何时同步由操作系统来决定。

三种策略的优缺点也不言而喻了,always 可靠性高性能低、no 可靠性低性能高,everysec 取两者折中。

重写机制

AOF 日志是以文件的模式记录接管到的所有写命令。随着接管的写命令越来越多,文件体积会越来越大。这也就意味着会带来一些问题。

  • 操作系统对文件体积有限度,不能保留过大的文件。
  • 对体积比拟大的文件进行追加写入,效率会升高。
  • AOF 日志体积过大,故障复原过程迟缓。

为了解决下面的问题,Redis 提供了重写性能。通过该性能,Redis 能够创立一份新的 AOF 日志来代替现有的 AOF 日志。

  • 两份 AOF 日志所保留的数据库状态雷同。
  • AOF 日志不会蕴含节约空间的冗余命令。
  • AOF 日志体积小于等于原 AOF 日志。

重写过程

为什么要放在子过程里执行?

不会造成主线程阻塞,子过程进行 AOF 重写期间,主线程能够持续解决命令申请。

重写过程中有写命令,会造成数据不统一吗?

不会,Redis 保护了 AOF 重写缓冲区,在主线程创立重写子过程后开始应用。如果重写期间有写命令申请,Redis 会追加写入 AOF 缓冲区和 AOF重写缓冲区。当子过程实现创立新 AOF 日志后,主线程会将 AOF 重写缓冲区中的所有内容追加写入新 AOF 日志,此时新旧两份 AOF日志所保留的数据库状态完全一致。最初,用新 AOF 日志笼罩旧 AOF 日志,实现 AOF 日志重写操作。

正文完
 0