Redis教程

redis - 数据持久化

本文主要是介绍redis - 数据持久化,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

Redis 的数据持久化机制

Redis 的持久化主要有两大机制:AOF(Append Only File) 日志和 RDB 快照。

AOF

AOF 记录 Redis 的操作日志,它是在主线程中执行的。AOF 和数据库的写前日志(Write Ahead Log, WAL)不同,WAL 是在执行命令前先把修改的数据写到日志文件中,而 AOF 是在命令执行成功之后再记录日志,这样有两个好处:

  1. 可以减少额外的检查命令是否正确的开销。
  2. 因为是在命令执行后记录,所以不会阻塞当前的写操作。

AOF 日志的格式

AOF 中的命令是以文本形式记录的,以 “set testkey testvalue” 为例:Redis 会先以 *3 来表示当前命令有三个部分,每部分会先以 $+数字 来表示长度,然后跟上具体的命令、键或值。例如:

潜在风险

  1. 可能在命令执行之后,写入 AOF 之前机器宕机,那么相应数据就有丢失的风险。
  2. 上面说到 AOF 是在主线程执行的,如果磁盘写入很慢,那么就有可能阻塞下一个命令的执行。

写回策略

根据上述的潜在风险,Redis 提供了三种写回策略供用户评估选择,可以在 AOF 配置项 appendfsync 配置:

配置项 写回时间 优点 缺点
Always 同步写回 可靠性高,数据基本不丢失 每个写命令都要落盘,性能影响较大
Everysec 每秒写回 性能适中 宕机时丢失1秒内的数据
No 操作系统控制的写回 性能好 宕机时丢失数据较多

AOF 重写机制

背景

当 Redis 接收的命令越来越多,那么 AOF 文件就会越来越大,AOF 文件过大带来性能问题:

  1. 文件系统本身对文件大小有限制,无法保存过大的文件;
  2. 文件过大时,追加命令记录效率会变低;
  3. 如果发生宕机,AOF 中的记录要一个个回放恢复数据,文件过大时会导致这个过程非常缓慢,影响 Redis 的正常使用。

重写机制

重写机制是指 Redis 会根据当前的数据状态创建一个新的 AOF 文件,即读取当前 Redis 中的所有的记录,将其一一写入新的 AOF 文件中。

为什么重写机制可以缩小 AOF 文件的大小呢?正常使用过程中,使用者可能会对一个 key 进行多次操作,而这些操作都会被记录到 AOF 中,而重写机制会忽略这些过程,只将最后的结果记录到 AOF 中,多条记录合并成了一条。

重写过程和 AOF 日志不同,它是由后台子进程 bgrewriteaof 来完成的,这样可以避免阻塞主线程导致的性能下降。

重写过程的主要流程如下:

  1. 每次执行重写时,主线程会 fork 一个 bgrewiteaof 子进程,因为 fork 的特性,同时会把主进程的内存拷贝一份给子进程。
  2. 因为此时主线程没有被阻塞,AOF 日志还会正常执行。
  3. 主线程的操作还会被记录到重写缓冲区中,等拷贝数据重写完成后,重写缓冲区的日志也会被写入新的 AOF 文件,都完成后,新的 AOF 文件会替代就文件。

这篇关于redis - 数据持久化的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!