redis的持久化策略

redis的持久化策略

Scroll Down

直接从后端数据库恢复数据时,可能带来的两个问题

​ 1、频繁访问数据库会给数据库带来大的压力,

​ 2、数据访问效率变低

redis的备份策略主要有:1 AOF日志 2 RDB快照


mysql的日志是写前日志(WAL),也就是说,先把日志备份,再写到磁盘进行持久化。redolog记录修改后的数据

Redis 是先执行命令,把数据写入内存,然后才记录日志,如下图所示:


RDB

​ 在发生宕机时,用AOF方法进行故障恢复的话,速度较慢→采用RDB(Redis DataBase)方式(内存快照)

​ 但是也不能只考虑rdb,因为它的单线程模型就决定了,我们要尽量避免所有会阻塞主线程的操作。

Redis 提供了两个命令来生成 RDB 文件,分别是 save 和 bgsave。

​ 1️⃣save:在主线程中执行,会导致阻塞;

​ 2️⃣bgsave:创建一个子进程,专门用于写入 RDB 文件,避免了主线程的阻塞,这也是 Redis RDB 文件生成的默认配置。


​ 问:怎么解决快照时修改数据的问题:如果进行快照时数据发生了变化怎么办

​ 答:redis 生成rdb 时候会fork 子进程。此时的读写操作:

**读:主线程和bgsave子进程互不影响。 **

写:被修改的数据会被复制一份为副本,bgsave 把副本数据写入rdb 文件,主线程修改原数据。


RDB的备份间隔

​ 频繁进行全量快照的问题:

​ 1️⃣对磁盘的压力

​ 2️⃣fork子进程会阻塞主线程,主线程的内存越大,fork子线程时,阻塞的时间就会越长。

​ 所以采用增量快照解决问题:就是指,做了一次全量快照后,后续的快照只对修改的数据进行快照记录,这样可以避免每次全量快照的开销。

​ 跟 AOF 相比,快照的恢复速度快,但是,快照的频率不好把握,如果频率太低,两次快照间一旦宕机,就可能有比较多的数据丢失。如果频率太高,又会产生额外开销

1️⃣优点

  • RDB文件小,非常适合定时备份,用于灾难恢复
  • Redis加载RDB文件的速度比AOF快很多,因为RDB文件中直接存储的时内存数据,而AOF文件中存储的是一条条命令,需要重演命令。

3️⃣缺点

  • RDB无法做到实时持久化,不适用于实时性要求较高的场景

AOF

redis不像mysql那样有语法分析、词法分析那边可以检测出命令是否错误,而使用执行结果作为命令是否正确的依据,简化了redis结构,又加快了速度。 同时命令执行之后才记录日志不会阻塞当前的写操作

AOF是文件操作,AOF只是追加写日志文件,但可能造成磁盘IO的负荷加重。


AOF写回磁盘的策略

所以需要找到合适的执行AOF命令的时机:所以有了三种AOF写回策略

1️⃣Always(高可靠性),同步写回:每个写命令执行完,立马同步地将日志写回磁盘;(基本不丢数据,但频率过高可能影响主线程性能)

2️⃣Everysec(折中选项),每秒写回:每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,每隔一秒把缓冲区中的内容写入磁盘;

(折中选项,可能会丢失一秒的数据)

3️⃣No(高性能),操作系统控制的写回:每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。(操作系统控制,写盘的时机不掌握在redis中,丢失数据的风险比较大)


AOF重写机制

Aof日志文件过大的问题:(重写时的最小大小,为64MB)

1.操作系统对文件大小有限制,超过则无法继续写入;

2.文件太大,写入的效率也会变低;

3.文件太大,恢复数据也很耗时AOF的优缺点


1️⃣优点 :AOF只是追加写日志文件,对服务器性能影响较小,速度比RDB要快,消耗的内存较少

2️⃣缺点

  • AOF方式生成的日志文件太大,需要不断AOF重写,进行瘦身。
  • 可能丢失一部分日志,因为是先执行命令再备份
  • AOF重演命令式的恢复数据,速度显然比RDB要慢。因为AOF也在主线程中执行,如果日志写盘的时候磁盘压力大,可能会影响后续的操作。

混合持久化

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

​ 这样一来,快照不用很频繁地执行,这就避免了频繁 fork 对主线程的影响。而且,AOF 日志也只用记录两次快照间的操作,也就是说,不需要记录所有操作了,因此,就不会出现文件过大的情况了,也可以避免重写开销。