Redis教程

Redis持久化方式

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

1、RDB

  RDB全称Redis DataBase,在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时直接将快照文件直接读到内存里;在默认情况下,Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中,有手动触发和自动触发两种方式。

  手动触发:save 和 bgsave 两命令

  save命令:阻塞当前 Redis,直到 RDB 持久化过程完成为止,若内存实例比较大 会造成长时间阻塞,线上环境不建议用它

  bgsave命令:redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。redis 进程执行 fork 操作创建子线程,由子线程完成持久化,阻塞时间很短(微秒级),是 save 的优化,在执行 redis-cli shutdown 关闭 redis 服务时,如果没有开启 AOF 持久化,自动执行 bgsave;

    bgsave的写时复制(COW)机制

    Redis 借助操作系统提供的写时复制技术(Copy-On-Write, COW),在生成快照的同时,依然可以正常处理写命令。简单来说,bgsave 子进程是由主线程 fork 生成的,可以共享主线程的所有内存数据。bgsave 子进程运行后,开始读取主线程的内存数据,并把它们写入 RDB 文件。此时,如果主线程对这些数据也都是读操作,那么,主线程和 bgsave 子进程相互不影响。但是,如果主线程要修改一块数据,那么,这块数据就会被复制一份,生成该数据的副本。然后,bgsave 子进程会把这个副本数据写入 RDB 文件,而在这个过程中,主线程仍然可以直接修改原来的数据。

  自动触发:通过配置文件对 Redis 进行设置, 让它在“N 秒内数据集至少有 M 个改动”这一条件被满足时, 自动进行数据集保存操作。

  RDB相关配置:

# RDB自动持久化规则
# 当 900 秒内有至少有 1 个键被改动时,自动进行数据集保存操作
save 900 1
# 当 300 秒内有至少有 10 个键被改动时,自动进行数据集保存操作
save 300 10
# 当 60 秒内有至少有 10000 个键被改动时,自动进行数据集保存操作
save 60 10000

# RDB持久化文件名
dbfilename dump.rdb

# 数据持久化文件存储目录
dir /var/lib/redis

# bgsave发生错误时是否停止写入,通常为yes
stop-writes-on-bgsave-error yes

# 对于储存到磁盘的快照,是否启用LZF算法进行压缩存储,默认是yes,但会消耗一定CPU。
rdbcompression yes

# 在存储快照后,是否让redis使用CRC64算法来进行数据校验,通常为yes
rdbchecksum yes

 优点:

  1. 整个Redis数据库将只包含一个文件 dump.rdb,方便持久化

  2. 压缩后的二进制文,方便备份、全量复制,灾性好

  3. 性能最大化,fork子进程来完成写操作,让主进程继续处理命令,所以是IO最大化,使用单独的子进程来进行持久化,主进程不会进行任何IO操作,保证了Redis的高性能

  4. 相对于数据集大时,比AOF的启动效率更高

缺点:

  1. 数据安全性低。RDB 是间隔一段时间进行持久化,如果持久化时redis 发生故障,会发生数据丢失,所以这种更适用于数据要求不严谨的场景

  2. 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟

  3. 保存后的二进制文件,存在老版本不兼容新版本rdb文件的问题

2、AOF

  AOF全称Append Only File(文件追加方式),将修改的每一条指令记录进文件appendonly.aof中(先写入os cache,每隔一段时间fsync到磁盘)

  比如执行命令 set name james,aof文件里会记录如下数据

  这是一种resp协议格式数据,星号后面的数字代表命令有多少个参数,$号后面的数字代表这个参数有几个字符注意,如果执行带过期时间的set命令,aof文件里记录的是并不是执行的原始命令,而是记录key过期的时间戳

  比如执行 set age 20 ex 1000,对应aof文件里记录如下

AOF相关配置 

appendonly yes         // 启用aof持久化方式

# appendfsync always   // 每收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用

appendfsync everysec   // 每秒强制写入磁盘一次,性能和持久化方面做了折中,只会丢失一秒钟的数据,推荐
    
# appendfsync no       // 从不进行写入,更不安全的选择

AOF重写

AOF文件里可能有太多没用指令,所以AOF会定期根据内存的最新数据生成aof文件,例如执行如下几条命令:

  此时,AOF文件里的内容为: 

 重写AOF后:

 如下两个配置可以控制AOF自动重写频率

auto-aof-rewrite-percentage 100  // aof文件大小比起上次重写时的大小,增长率100%时,重写

auto-aof-rewrite-min-size 64mb   // aof文件,至少超过64M时,重写

当然AOF还可以手动重写,进入redis客户端执行命令bgrewriteaof重写AOF

注意,AOF重写redis会fork出一个子进程去做(与bgsave命令类似),不会对redis正常命令处理有太多影响

AOF重写原理:

  AOF重写并不是对原有AOF文件进行任何写入和读取,它针对的是数据库中键的当前值。将当前数据库中的数据转换成一系列的redis的操作指令,存储到一个新的aof日志文件中,完毕后再将操作期间发生的增量aof日志追加到这个新的aof日志文件中,追加完毕后就立即替换旧的aof。在重写的过程中,由于redis还会有新的写入,为了避免数据丢失,会开辟一块内存用于存放重写期间产生的写入操作,等到重写完毕后会将这块内存中的操作再追加到aof文件中。如果在重写过程中redis的写入很频繁或写入量很大,就会导致占用大量额外的内存来缓存写操作,导致内存爆涨

优点:

  1. 数据安全,Redis中提供了3种同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失,而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中

  2. 通过append模式写文件,即使中途服务器宕机也不会破坏已经存在的内容,可以通过redis-check-aof工具解决数据一致性问题

  3. AOF机制的rewrite模式。定期对AOF文件进行重写,以达到压缩的目的

缺点:

  1. AOF 文件比 RDB 文件大,且恢复速度慢

  2. 数据集大的时候,比rdb 启动效率低

  3. 运行效率没有RDB高

AOF文件比RDB更新频率高,优先使用AOF还原数据。

3、混合持久化

  重启 Redis 时,我们很少使用 RDB来恢复内存状态,因为会丢失大量数据。我们通常使用 AOF 日志重放,但是重放 AOF 日志性能相对 RDB来说要慢很多,这样在 Redis 实例很大的情况下,启动需要花费很长的时间。 Redis 4.0 为了解决这个问题,带来了一个新的持久化选项——混合持久化。集成了 RDB 和 AOF 的优点

  通过如下配置可以开启混合持久化(必须先开启aof):

aof‐use‐rdb‐preamble yes  // 开启混合持久化,必须先开启AOF

  如果开启了混合持久化,AOF在重写时,不再是单纯将内存数据转换为RESP命令写入AOF文件,而是将重写这一刻之前的内存做RDB快照处理,并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起,都写入新的AOF文件,新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,覆盖原有的AOF文件,完成新旧两个AOF文件的替换。于是在 Redis 重启的时候,可以先加载 RDB 的内容,然后再重放增量 AOF 日志就可以完全替代之前的AOF 全量文件重放,因此重启效率大幅得到提升。

  混合持久化AOF文件结构如下:

 

 

 Redis数据备份策略:

  1. 写crontab定时调度脚本,每小时都copy一份rdb或aof的备份到一个目录中去,仅仅保留最近48小时的备份
  2. 每天都保留一份当日的数据备份到一个目录中去,可以保留最近1个月的备份
  3. 每次copy备份的时候,都把太旧的备份给删了
  4. 每天晚上将当前机器上的备份复制一份到其他机器上,以防机器损坏

 

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