Redis持久化之AOF

在上篇文章中介绍了快照持久化,对于它的优缺点大家也有所有了解了。本文主要介绍redis持久化中的另一种方式AOP(Append only file)持久化

AOF持久化

与快照持久化通过直接保存 Redis 的键值对数据不同,AOF 持久化是通过保存 Redis 执行的写命令来记录 Redis 的内存数据。理论上说,只要我们保存了所有可能修改 Redis 内存数据的命令(也就是写命令),那么根据这些保存的写命令,我们可以重新恢复 Redis 的内存状态。AOF 持久化正是利用这个原理来实现数据的持久化与数据的恢复的

开启AOF

在redis中AOF默认是关闭的,我们需要修改配置文件来开启AOF

AOF相关的配置

appendonly yes
appendfilename "appendonly.aof"
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

参数

说明

appendonly

yes

是否开启AOF持久化

appendfilename

“appendonly.aof”

存储的文件的名称

appendfsync

everysec

同步频率everysec 每隔一秒钟持久化一次always 每执行一条命令持久化一次no 持久化的时机交给操作系统处理

no-appendfsync-on-rewrite

no

执行压缩时是否执行同步操作

auto-aof-rewrite-percentage

100

当前AOF文件超过上次AOF文件的百分比后才进行持久化操作

auto-aof-rewrite-min-size

64mb

自定执行AOF操作文件最小的大小要达到的大小

关闭快照(RDB)持久化

修改如下配置即可

save ""
#save 900 1
#save 300 10
#save 60 10000

验证

重启服务

执行简单的命令操作

我们可以看到append.aof文件中存储的内容就是我们执行的命令

AOF持久化备份的注意点

1.appendfsync的取值有三个,分别是everysec,always和no,在这里我们推荐使用everysec,不推荐使用always。因为always会严重影响服务器的性能 2.everysec最坏的情况也就只会丢失1秒的数据,影响在可控范围之内。

AOF的重写与压缩

由于 Redis 会不断地将被执行的命令记录到 AOF 文件里面,所以随着 Redis 不断运行,AOF 文件的体积会越来越大。另外,如果 AOF 文件的体积很大,那么还原操作所需要的时间也会非常地长。 为了解决 AOF 文件越来越大的问题,用户可以向 Redis 发送 BGREWRITEAOF 命令,这个命令会移除 AOF 文件中冗余的命令来重写 AOF 文件,使 AOF 文件的体积变得尽可能地小。 BGREWRITEAOF 的工作原理和快照持久化命令 BGSAVE 的工作原理类似,Redis 会创建一个子进程来负责对 AOF 文件进行重写。 值得注意的是,进行 AOF 文件重写时,如果原来的 AOF 文件体积已经非常大,那么重写 AOF 并删除旧 AOF 文件的过程将会对 Redis 的性能造成较大的影响。

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

为此,Redis 提供auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个配置选项来对 AOF 重写进行配置。auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个配置选项的含义可以参考 redis.conf 配置中的详细说明,具体来说,auto-aof-rewrite-percentage配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写,而auto-aof-rewrite-min-size则配置当 AOF 文件需要达到多大体积时才进行 AOF 重写。只有这两个配置的条件都达到时,才会进行 AOF 重写

AOF优缺点

AOF 的优点

AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis 最多也就丢失 1 秒的数据而已。 AOF 文件使用 Redis 命令追加的形式来构造,因此,即使 Redis 只能向 AOF 文件写入命令的片断,使用 redis-check-aof 工具也很容易修正 AOF 文件。 AOF 文件的格式可读性较强,这也为使用者提供了更灵活的处理方式。例如,如果我们不小心错用了 FLUSHALL 命令,在重写还没进行时,我们可以手工将最后的 FLUSHALL 命令去掉,然后再使用 AOF 来恢复数据。

AOF 的缺点

对于具有相同数据的的 Redis,AOF 文件通常会比 RDF 文件体积更大。 虽然 AOF 提供了多种同步的频率,默认情况下,每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时,RDB 比 AOF 具好更好的性能保证。 RDB 使用快照的形式来持久化整个 Redis 数据,而 AOF 只是将每次执行的命令追加到 AOF 文件中,因此从理论上说,RDB 比 AOF 方式更健壮。官方文档也指出,AOF 的确也存在一些 BUG,这些 BUG 在 RDB 没有存在。

持久化的一些使用建议

1.如果redis仅仅是用来做为缓存服务器的话,我们可以不使用任何的持久化。 2.一般情况下我们会将两种持久化的方式都开启。redis优先加载AOF文件来回复数据。RDB的好处是快速。 3.在主从节点中,RDB作为我们的备份数据,只在salve(从节点)上启动,同步时间可以设置的长一点,只留(save 900 1)这条规则就可以了。 4.开启AOF的情况下,主从同步是时候必然会带来IO的性能影响,此时我们可以调大auto-aof-rewrite-min-size的值,比如5GB。来减少IO的频率 5.不开启AOF的情况下,可以节省IO的性能影响,这是主从建通过RDB持久化同步,但如果主从都挂掉,影响较大~

~好了本文到此为止, 更多资料欢迎参考官网手册

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Linyb极客之路

springcloud用redis做session共享出现类反序列化失败问题

前段时间项目组打算把公司的一个老项目当做现有系统的子模块,现有系统的技术框架主要是采用springcloud,用redis来做session共享。老项目的用户鉴...

1.3K20
来自专栏chenssy

Redis 分布式锁进化史解读+缺陷分析

近两年来微服务变得越来越热门,越来越多的应用部署在分布式环境中,在分布式环境中,数据一致性是一直以来需要关注并且去解决的问题,分布式锁也就成为了一种广泛使用的技...

26430
来自专栏IT云清

分布式锁系列--04关于分布式锁的选型分析02

2.按顺序依次向N个Redis节点执行获取锁的操作。这个获取操作跟前面基于单Redis节点的获取锁的过程相同,包含随机字符串my_random_value,也包...

7830
来自专栏Linyb极客之路

数据服务开发经验

有状态服务或者说数据服务,上线遇到问题很棘手,回滚无济于事;而且数据加载通常都很慢,部署时间长;最终导致不敢修改代码,谨小慎微;服务质量也是能忍就忍,不愿意深度...

18040
来自专栏Zchannel

RediSQL 0.8.0 发布 将查询结果写入流中

RediSQL 0.8.0 发布了,RediSQL 是一个 Redis 模块,为 Redis 提供完整的 SQL 功能。RediSQL 支持所有 Redis 数...

10420
来自专栏微信公众号:Java团长

做了5年Java开发,你必须重视这一点

做了3~5年左右Java开发,你已经积累了不少项目经验,扩宽了技术广度,也许已发力成为团队管理者。到了这个阶段,大家却常有这种感受:感觉自己卡在瓶颈进步缓慢,技...

15260
来自专栏大数据成神之路

16-Flink-Redis-Sink

流式计算中,我们经常有一些场景是消费Kafka数据,进行处理,然后存储到其他的数据库或者缓存或者重新发送回其他的消息队列中。

71030
来自专栏性能与架构

架构设计原则 - 高并发

实际常用:应用无状态,配置文件有状态,例如,不同的机房读取不同的配置文件,通过配置中心指定。

13350
来自专栏我是攻城师

为什么单线程Redis性能也很出色

高性能的服务器,不一定是多线程实现的,也就是说多线程不一定比单线程效率高,这得分具体的情况。以redis为例,核心处理请求的线程只有一个,所以我们常常理解其仅仅...

24730
来自专栏Java架构

2019金三银四你准备好了没,这些Java后端面试知识点掌握了吗?

3、HashMap,HashTable,ConcurrentHashMap的区别。

16830

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励