SLK的个人博客

  • 首页

  • 搜索
LRU Stack ThreadLocal Nacos RejectedExecutionHandler Executor RocketMQ ConcurrentHashMap CyclicBarrier Semaphore CountDownLatch canal Unsafe Atomic BlockingQueue AQS ReentrantLock Synchronized MESI Volatile JMM BufferPool Explain MySQL 常量池 Arthas JVM调优 三色标记 CMS ParNew 垃圾收集器 G1 Java Redis Android HTTPDNS DNS ioc 爬虫 seleniumhq 推荐引擎 Mahout IM Netty Vert.x HashMap 梯子 翻墙 V2ray Docker 搜索引擎 SpringBoot elasticsearch

Redis 持久化,RDB、AOF、混合持久化

发表于 2020-06-10 | 分类于 Redis | 0 | 阅读次数 172

RDB快照(snapshot)

常用操作

在默认情况下,Redis会将快照数据放到 “dump.rdb” 的文件中。并且该文件是一个被压缩过的二进制文件。

而且可以对Redis设置多个生成RDB快照的策略。让Redis在某一个时间段内,修改次数达到设定的阈值,则触发持久化。

打开redis.conf 配置文件,配置几条规则,这里设置阈值较小,方便测试。

# 存储RDB文件的文件名
dbfilename dump.rdb

# 存储数据目录,RDB 、 AOF 等文件都会存储在这个目录下
dir /root/redis/data/6379/dir

# 设置30秒内 有20个更新操作即生成一个RDB快照
save 30 20

# 设置60秒内 有10个更新操作即生成一个RDB快照
save 60 10

尝试手动在30秒内执行20个更新操作,观察dir目录下确实生成了一个 “dump.rdb” 文件,不过因为这是二进制的压缩文件,所以查看时,会是乱码状态。 QQ20200610-210658@2x

除了这种方式以外,还有手动生成快照的命令,可以通过redis的客户端,发送命令到redis,让redis生成数据快照保存下来。

先把 dump.rdb 文件删除,接着我们直接使用 “src/redis-cli -p 6379 ” 进入redis客户端,执行save命令。

QQ20200610-211224@2x

这时候再次进入dir 目录下,可以看到新的dump.rdb 文件生成了。

可以尝试手动将redis的进程kill掉,然后重启,会发现数据被恢复回来了。

不过需要注意的是,save是一个同步命令,它会在生成快照的这个时间段,阻塞其他的命令。

bgsave,是redis提供的异步生成快照的命令(bg是background的简写),当redis的单线程解析到 “bg” 这个指令的时候,就会fork一个子进程去执行命令。

比如bgsave,就会fork出来一个子进程去生成RDB文件快照。

而且,通过配置文件的策略自动生成RDB快照,是以bgsave的命令生成的。不会阻塞客户端的其他命令。

如果要关闭RDB持久化方案,将redis.conf 配置文件中的所有save 配置注释掉即可。

缺点

RDB快照方案的持久化,存在较大的可能,数据丢失问题。

倘若设置的60秒以内1000个更新操作则生成RDB快照,如果在这60秒以内没有达到1000个更新操作的阈值,而Redis宕机了的话,则会丢失这60秒的数据。

AOF 持久化方案

常用操作

从Redis的1.1版本开始,增加了一种AOF持久化( append-only file ),它会将每一条更新命令以RESP协议的方式,追加在文件 “appendonly.aof” 中。

当Redis重启时,会从aof文件里读取命令,重新执行一遍,以此来恢复数据。

修改配置文件:

# 是否启用 AOF,  no、yes 
appendonly yes

# AOF保存的文件名,默认 appendonly.aof
appendfilename "appendonly.aof"

# 同步策略  每秒同步一次
appendfsync everysec

同步策略有三种

  • appendfsync always 每次有新的命令都会执行一次fsync,追加命令到文件,安全性高,性能低下。
  • appendfsync everysec 每秒会执行一次fsync,把新的命令追加到文件里。倘若故障,会丢失一秒的数据。(Redis默认配置)
  • appendfsync no 从不fsync到文件 ,将数据交给操作系统来处理。更快,也更不安全的选择。

测试一下执行多次incr命令后,是否会追加到aof文件里。

QQ20200610-221432@2x

查看aof文件, 可以看到有6个incr指令都被追加到了appendonly.aof的文件里。QQ20200610-221914@2x

这时候aof的弊端也显现出来了,就是aof的文件必然会非常的大,假设这个zhangsan字段,被incr了一万次,那么就会在aof文件里生成一万条incr指令,

AOF 重写

aof里面可能会存在大量没用的指令,造成文件过大,数据恢复较慢。

那么在这种场景下,aof定期重写,可以做到一定的优化,它会定期将当前最新的数据,生成aof文件。

通过修改redis.conf配置,让redis自动执行aof重写。

# aof 文件至少要达到64mb 以后才会执行aof重写
auto-aof-rewrite-min-size 64mb

# aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-percentage 100

可以通过 “bgrewriteaof” 指令,手动进行aof重写,而且该指令会fork一个新的子进程到后台去处理。

我们进入redis客户端,手动执行一次“bgrewriteaof”后,查看一下aof文件内容。可以明确的看到多条incr指令变成了一个set zhangsan 6 的指令。

QQ20200610-224605@2x

redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据,因为aof一般来说数据更全一点。

混合持久化

Redis重启时,我们很少用RDB来恢复数据,因为RDB可能会丢失过多的数据,通常使用AOF来恢复数据,对命令重新执行。

但是重新执行AOF,效率对于RDB来说会低很多,有可能导致恢复数据时间过长。

Redis 为了解决这个问题,引入了混合持久化。

通过配置redis.conf 可以开启混合持久化。

aof-use-rdb-preamble yes

开启了混合持久化后,AOF在进行重写的时候,不再是简单的最新的数据存储在apf文件中。

而是将重写这一刻之前的内存做RDB快照处理,并且将RDB快照内容和增量的AOF修改命令存在一起,并一起存入到新的文件中。

新的文件一开始不叫“appendonly.aof”,等到重写完新的AOF文件才会进行改名,原子的覆盖原有的AOF文件,完成新旧两个AOF文件的替换。

在混合持久化开启下,Redis重启会先加载“appendonly.aof” 文件中的RDB数据,其次再加载“appendonly.aof” RDB后面的 AOF增量命令。

接下来测试拥有RDB和AOF增量数据的 “appendonly.aof” 文件会是什么样的。

在打开持久化后,手动执行一次AOF重写,也就是“bgrewriteaof”命令,当我们再次查看aof文件的时候,应该是下面这样的乱码,这些是RDB格式的二进制数据,因为在生成RDB之后,重写AOF之前,没有新的修改命令,所以这里看不到AOF的命令。

REDIS0009�      redis-ver6.0.5�
�edis-bits�@�ctime�T��^used-mem�3
 aof-preamble��zhangsan����dD�C�A

打开redis客户端,再次执行几次incr命令之后,再次查看aof文件,如下。可以看到,上面的是RDB数据,下面的是AOF增量数据。

QQ20200610-230841@2x

# LRU # Stack # ThreadLocal # Nacos # RejectedExecutionHandler # Executor # RocketMQ # ConcurrentHashMap # CyclicBarrier # Semaphore # CountDownLatch # canal # Unsafe # Atomic # BlockingQueue # AQS # ReentrantLock # Synchronized # MESI # Volatile # JMM # BufferPool # Explain # MySQL # 常量池 # Arthas # JVM调优 # 三色标记 # CMS # ParNew # 垃圾收集器 # G1 # Java # Redis # Android # HTTPDNS # DNS # ioc # 爬虫 # seleniumhq # 推荐引擎 # Mahout # IM # Netty # Vert.x # HashMap # 梯子 # 翻墙 # V2ray # Docker # 搜索引擎 # SpringBoot # elasticsearch
Redis 渐进式遍历键
Redis 主从架构、哨兵架构
  • 文章目录
  • 站点概览
宋龙宽

宋龙宽

87 日志
13 分类
53 标签
RSS
Github E-mail
Creative Commons
Links
  • 黑客派
  • Relyn
  • 张小妞的博客
  • ElasticSearch教程
© 2021 宋龙宽
由 Halo 强力驱动
|
主题 - NexT.Gemini v5.1.4