Redis教程

Redis实战:保证数据不丢失,RDB&AOF持久化原理解析

本文主要是介绍Redis实战:保证数据不丢失,RDB&AOF持久化原理解析,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

Redis 中数据的持久化

前言

我们知道 Redis 是内存数据库,所有操作都在内存上完成。内存的话,服务器断电,内存上面的数据就会丢失了。这个问题显然是需要解决的。

Redis 中引入了持久化来避免数据的丢失,主要有两种持久化的方式 RDB 持久化和 AOF 持久化。

AOF 持久化

什么是 AOF 持久化

AOF(Append Only File):通过保存数据库执行的命令来记录数据库的状态。

Redis实战:保证数据不丢失,RDB&AOF持久化原理解析

AOF日志对数据库命令的保存顺序是,Redis 先执行命令,把数据写入内存,然后才记录日志。

为什么要后记录日志呢

1、后写,能够避免记录到错误的命令。因为是先执行命令,后写入日志,只有命令执行成功了,命令才能被写入到日志中。对于新手小白想更轻松的学好Java提升,Java架构,web开发、大数据,数据分析,人工智能等技术,这里给大家分享系统教学资源,扩列下我尉(同英):1253431195【教程/工具/方法/解疑】

2、避免阻塞当前的写操作,是在命令执行后才记录日志,所以不会阻塞当前的写操作。

AOF 的潜在风险

  • 1、如果命令执行成功,写入日志的时候宕机了,命令没有写入到日志中,这时候就有丢失数据的风险了,因为这时候没有写入日志,服务断电之后,这部分数据就丢失了。

这种场景在别的地方也很常见,比如基于 MQ 实现分布式事务,也会出现业务处理成功 + 事务消息发送失败这种场景,RabbitMQ,RocketMQ,Kafka 事务性,消息丢失和消息重复发送的处理策略

  • 2、AOF 日志写入也是在主线程进行的,如果磁盘的压力很大,写入速度变慢了,会影响后续的操作。

这两种情况可以通过调整 AOF 文件的写入磁盘的时机来避免

AOF 文件的写入和同步

AOF 文件持久化的功能分成三个步骤,文件追加(append),文件写入,文件同步(sync)。

AOF 文件在写入磁盘之前是先写入到 aof_buf 缓冲区中,然后通过调用 flushAppendOnlyFile 将缓冲区中的内容保存到 AOF 文件中。

写入的策略通过 appendfsync 来进行配置

  • Always:同步写回 每次操作命令执行完后,同步将 AOF 日志数据写回硬盘;
  • Everysec:每秒写回 每次操作命令执行完后,先将命令写入到 AOF 文件的内核缓冲区,然后每隔一秒将缓冲区里的内容写回到硬盘;
  • No:操作系统控制的写回 Redis 不在控制命令的写会时机,交由系统控制。每次操作命令执行完成之后,命令会被放入到 AOF 文件的内核缓冲区,之后什么时候写入到磁盘,交由系统控制。

AOF 文件重写机制

因为每次执行的命令都会被写入到 AOF 文件中,随着系统的运行,越来越多的文件会被写入到 AOF 文件中,这样 AOF 文件势必会变得很大,这种情况该如何去处理呢?

为了解决这种情况,Redis 中引入了重写的机制

什么是重写呢?

因为 AOF 文件中记录的是每个命令的操作记录,举个,比如当一个键值对被多条写命令反复修改时,AOF文件会记录相应的多条命令,那么重写机制,就是根据这个键值对当前的最新状态,为它生成对应的写入命令,保存成一行操作命令。这样就精简了 AOF 文件的大小。

192.168.56.118:6379> set name "xiaoming"OK192.168.56.118:6379> get name"xiaoming"192.168.56.118:6379> set name "xiaozhang"OK192.168.56.118:6379> set name "xiaoli"OK# 重写后就是192.168.56.118:6379> set name "xiaoli"

简单来讲就是多变一,就是把 AOF 中日志根据当前键值的状态,合并成一条操作命令。

重写之后的文件会保存到新的 AOF 文件中,这是旧的 AOF 文件和新的 AOF 文件中键值对应的状态是一样的。然后新的 AOF 文件会替换掉旧的 AOF 文件,这样 重写操作一直在进行,AOF 文件就不至于变得过大。对于新手小白想更轻松的学好Java提升,Java架构,web开发、大数据,数据分析,人工智能等技术,这里给大家分享系统教学资源,扩列下我尉(同英):1253431195【教程/工具/方法/解疑】

重写是后台进行的, AOF 重写会放到子进程中进行的,使用子进程的优点:

1、子进程处理 AOF 期间,不会影响 Redis 主线程对数据的处理;

2、子进程拥有所在线程的数据副本,子进程能够避免锁的使用,保证数据的安全。

这里来看下,AOF 的处理流程

AOF 重写也有一个缓冲区,当服务节接收到新的命令的时候,如果在正在进行 AOF 重写,命令同样也会被发送到 AOF 缓冲区

Redis实战:保证数据不丢失,RDB&AOF持久化原理解析

的进程执行 AOF 重写的过程,服务端进程主要处理以下内容

1、接收并处理客户端发送的命令;

2、将执行后的命令写入到 AOF 缓冲区;

3、将执行后的命令也写入到 AOF 重写缓冲区;

AOF 缓冲区和 AOF 重写缓冲区中的内容会被定期的同步到 AOF 文件和 AOF 重写文件中

当子进程完成重写的时候,会给父进程发送一个信号,这时候父进程主要主要进行下面的两步操作:

1、将 AOF 重写缓冲区中的内容全部写入到 AOF 重写文件中,这时候重写 AOF 文件保存的数据状态是和服务端数据库的状态一致的;

2、将 AOF 重写文件替换旧的 AOF 文件;

通过 AOF 的重写操作,新的 AOF 文件不断的替换旧的 AOF 文件,这样就能控制 AOF 文件的大小

AOF 的数据还原

AOF 文件包了重建数据库索引锁需要的全部命令,所以只需要读入并重新执行一遍 AOF 文件中保存的命令,即可还原服务关闭之前数据库的状态。

RDB 持久化

什么是 RDB 持久化

RDB(Redis database):实现方式是将存在 Redis 内存中的数据写入到 RDB 文件中保存到磁盘上从而实现持久化的。

和 AOF 不同的是 RDB 保存的是数据而不是操作,在进行数据恢复的时候,直接把 RDB 的文件读入到内存,即可完成数据恢复。对于新手小白想更轻松的学好Java提升,Java架构,web开发、大数据,数据分析,人工智能等技术,这里给大家分享系统教学资源,扩列下我尉(同英):1253431195【教程/工具/方法/解疑】

Redis实战:保证数据不丢失,RDB&AOF持久化原理解析

RDB 如何做内存快照

Redis 中对于如何备份数据到 RDB 文件中,提供了两种方式

  • 1、save: 在主线程中执行,不过这种会阻塞 Redis 服务进程;
  • 2、bgsave: 主线程会 fork 出一个子进程来负责处理 RDB 文件的创建,不会阻塞主线程的命令操作,这也是 Redis 中 RDB 文件生成的默认配置;

对于 save 和 bgsave 这两种快照方式,服务端是禁止这两种方式同时执行的,防止产生竞争条件。

Redis 中可以使用 save 选项,来配置服务端执行 BGSAVE 命令的间隔时间

## Save the DB on disk:##   save <seconds> <changes>##   Will save the DB if both the given number of seconds and the given#   number of write operations against the DB occurred.##   In the example below the behaviour will be to save:#   after 900 sec (15 min) if at least 1 key changed#   after 300 sec (5 min) if at least 10 keys changed#   after 60 sec if at least 10000 keys changed##   Note: you can disable saving completely by commenting out all "save" lines.##   It is also possible to remove all the previously configured save#   points by adding a save directive with a single empty string argument#   like in the following example:##   save ""save 900 1save 300 10save 60 10000

save 900 1 就是服务端在900秒,读数据进行了至少1次修改,就会触发一次 BGSAVE 命令

save 300 10 就是服务端在300秒,读数据进行了至少10次修改,就会触发一次 BGSAVE 命令

快照时发生数据修改

举个栗子:我们在t时刻开始对内存数据内进行快照,假定目前有 2GB 的数据需要同步,磁盘写入的速度是 0.1GB/s 那么,快照的时间就是 20s,那就是在 t+20s 完成快照。

如果在 t+6s 的时候修改一个还没有写入磁盘的内存数据 test 为 test-hello。那么就会破坏快照的完整性了,因为 t 时刻备份的数据已经被修改了。当然是希望在备份期间数据不能被修改。

如果不能被修改,就意味这在快照期间不能对数据进行修改操作,就如上面的栗子,快照需要进行20s,期间不允许处理数据更新操作,这显然也是不合理的。

这里需要聊一下 bgsave 是可以避免阻塞,不过需要注意的是避免阻塞和正常读写操作是有区别的。避免阻塞主线程确实没有阻塞可以处理读操作,但是为了保护快照的完整性,是不能修改快照期间的数据的。

这里就需要引入一种新的处理方案,写时复制技术(Copy-On-Write, COW),在执行快照的同时,正常处理写操作。

bgsave 子进程是由主线程 fork 生成的,所以是可以共享主线程的内存的,bgsave子进程运行后会读取主线程中的内存数据,并且写入到 RDB 文件中。

写复制技术就是,如果主线程在内存快照期间修改了一块内存,那么这块内存会被复制一份,生成该数据的副本,然后 bgsave 子进程在把这段内存写入到 RDB 文件中。这样就可以在快照期间进行数据的修改了。

图片.png

多久做一次快照

对于快照,如果做的太频繁,可能会出现前一次快照还没有处理完成,后面的快照数据马上就进来了,同时过于频繁的快照也会增加磁盘的压力。

如果间隔时间过久,服务器在两次快照期间宕机,丢失的数据大小会随着快照间隔时间的增长而增加。

是否可以选择增量式快照呢?选择增量式快照,我们就需要记住每个键值对的状态,如果键值对很多,同样也会引入很多内存空间,这对于内存资源宝贵的Redis来说,有些得不偿失。

相较于 AOF 来对比,RDB 是会在数据恢复时,速度更快。但是 RDB 的内存快照同步频率不太好控制,过多过少都有问题。

Redis 4.0中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说,内存快照以一定的频率执行,在两次快照之间,使用AOF日志记录这期间的所有命令操作。

通过混合使用AOF日志和内存快照的方法,RDB 快照的频率不需要过于频繁,在两次 RDB 快照期间,使用 AOF 日志来记录,这样也不用考虑 AOF 的文件过大问题,在下一次 RDB 快照开始的时候就可以删除 AOF 文件了。

图片.png

过期的键如何持久化

在生成 RDB 文件的过程中,如果一个键已经过期,那么其不会被保存到 RDB 文件中。在载入 RDB 的时候,要分两种情况:

  • 1、如果 Redis 以主服务器的模式运行,那么会对 RDB 中的键进行时间检查,过期的键不会被恢复到 Redis 中。
  • 2、如果 Redis 以从服务器的模式运行,那么 RDB 中所有的键都会被载入,忽略时间检查。在从服务器与主服务器进行数据同步的时候,从服务器的数据会先被清空,所以载入过期键不会有问题。

对于 AOF 来说,如果一个键过期了,那么不会立刻对 AOF 文件造成影响。因为 Redis 使用的是惰性删除和定期删除,只有这个键被删除了,才会往 AOF 文件中追加一条 DEL 命令。在重写 AOF 的过程中,程序会检查数据库中的键,已经过期的键不会被保存到 AOF 文件中。

在运行过程中,对于主从复制的 Redis,主服务器和从服务器对于过期键的处理也不相同:

  • 1、对于主服务器,一个过期的键被删除了后,会向从服务器发送 DEL 命令,通知从服务器删除对应的键;
  • 2、从服务器接收到读取一个键的命令时,即使这个键已经过期,也不会删除,而是照常处理这个命令;
  • 3、从服务器接收到主服务器的 DEL 命令后,才会删除对应的过期键。

这样保证了数据的一致性,一个键值对存在于主服务器,也必然存在于从服务器。

总结

AOF

优点:AOF 中有三种策略可以进行选择,AOF 的默认策略为每秒钟 fsync 一次,在这种配置下,Redis 仍然可以保持良好的性能,并且就算发生故障停机,也最多只会丢失一秒钟的数据。

缺点:AOF 文件体积一般情况下比 RDB 文件体积大,并且数据还原速度也慢于 RDB。

RDB

优点:可以快速恢复数据,相比于 AOF 的顺序,逐一执行操作命令,效率更高;

缺点:因为是内存快照,频率过快,过慢,都会有响应的问题。过快,浪费磁盘资源,会给磁盘造成压力,过慢会存在较多数据丢失的问题。

Redis 4.0中提出了一个混合使用 AOF 日志和内存快照的方法,如果想要保证数据不丢失,这是一个比较好的选择;

如果允许分钟级别的数据丢失,可以只使用RDB;

如果只用AOF,优先使用 everysec 的配置选项,因为它在可靠性和性能之间取了一个平衡。

这篇关于Redis实战:保证数据不丢失,RDB&AOF持久化原理解析的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!