【赵渝强老师】Redis的AOF数据持久化

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
简介: Redis 是内存数据库,提供数据持久化功能,支持 RDB 和 AOF 两种方式。AOF 以日志形式记录每个写操作,支持定期重写以压缩文件。默认情况下,AOF 功能关闭,需在 `redis.conf` 中启用。通过 `info` 命令可监控 AOF 状态。AOF 重写功能可有效控制文件大小,避免性能下降。

b151.png

Redis 是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出会造成服务器中的数据库状态也会消失。所以 Redis 提供了数据持久化功能。Redis支持两种方式的持久化,一种是RDB方式;另一种是AOF(append-only-file)方式。两种持久化方式可以单独使用,也可以将这两种方式结合使用。


视频讲解如下:


AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。Redis还可以同时使用AOF持久化和RDB持久化。在这种情况下当重新启动时,Redis会优先使用AOF文件来还原数据集。因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。


视频讲解如下:


一、AOF持久化机制的工作流程


Redis提供的AOF持久化机制的工作流程如下:

  1. 所有的命令都会追加到AOF缓冲区中。
  2. AOF缓冲区根据对应的策略向磁盘同步操作。
  3. 随着AOF文件越来越大,需要定期对AOF重写,达到压缩目的。
  4. 当Redis服务器重启时,可以加载AOF文件进行数据恢复。


但在默认情况下,Redis关闭了AOF持久化的功能。这是由redis.conf中下面的参数决定的:

###### APPEND ONLY MODE ######
......
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of
# writes in a dramatic event like a server power outage, or a single
# write if something wrong with the Redis process itself happens,
# but the operating system is still running correctly.
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is
# the file with the better durability guarantees.
# Please check https://redis.io/topics/persistence for more information.
#**appendonly yes 默认值为no,改为yes启用AOF。**
# The name of the append only file (default: "appendonly.aof")
# **appendfilename "appendonly.aof" AOF默认生成的日志文件名称**
......


重启Redis服务器端,将在Redis的安装目录下自动生成文件appendonly.aof。如下所示:

[root@nosql11 redis]# pwd
/root/training/redis
[root@nosql11 redis]# ll
total 16
**-rw-r--r--. 1 root root 0 Apr 16 16:01 appendonly.aof**
drwxr-xr-x. 2 root root 134 Apr 16 09:38 bin
drwxr-xr-x. 2 root root 24 Apr 16 16:01 conf
-rw-r--r--. 1 root root 10405 Apr 16 16:01 dump.rdb
-rw-r--r--. 1 root root 3955 Apr 16 16:01 redis.log

提示:AOF持久化机制在默认情况下将每隔一秒将Redis操作写入日志,这是由下面的参数决定的:

# appendfsync always
appendfsync everysec
# appendfsync no


Redis监控AOF最直接的方法当然就是使用系统提供的info命令来做了。只需要执行下面一条命令,就能获得Redis关于AOF的状态报告。

bin/redis-cli info | grep aof_

# 输出的信-息如下:
aof_enabled:1         AOF
aof_rewrite_in_progress:0   AOF
aof_rewrite_scheduled:0     AOF
aof_last_rewrite_time_sec:-1  AOF
aof_current_rewrite_time_sec:-1 AOF
aof_last_bgrewrite_status:ok  AOF
aof_last_write_status:ok    AOF
aof_last_cow_size:0       AOF
aof_current_size:0        AOF
aof_base_size:0         AOF
aof_pending_rewrite:0     AOF
aof_buffer_length:0       AOF
aof_rewrite_buffer_length:0   AOF
aof_pending_bio_fsync:0     fsync
aof_delayed_fsync:0       fsync


二、【实战】AOF日志的重写


因为AOF持久化是通过保存被执行的写命令来记录数据库状态的,所以随着服务器运行时间的流逝,AOF文件中的内容会越来越多,文件的体积也会越来越大,如果不加以控制的话,体积过大的AOF文件很可能对Redis服务器、甚至整个宿主计算机造成影响,并且AOF文件的体积越大,使用AOF文件来进行数据还原所需的时间就越多。


为了解决AOF文件体积膨胀的问题,Redis提供了AOF文件重写功能。通过该功能,Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件,新旧两个AOF文件所保存的数据库状态相同,但新AOF文件不会包含任何浪费空间的冗余命令,所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。


下面通过一个简单的示例来测试AOF日志的重写。

(1)使用Redis的提供的基准测试工具模拟产生20万个操作。

bin/redis-benchmark -n 200000


(2)观察aof日志文件的大小。

ll appendonly.aof 
-rw-r--r--. 1 root root 659 Apr 24 10:47 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 1663409 Apr 24 11:24 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 25115259 Apr 24 11:24 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 51573511 Apr 24 11:24 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 61600852 Apr 24 11:24 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 74649125 Apr 24 11:25 appendonly.aof
ll appendonly.aof 
-rw-r--r--. 1 root root 41135984 Apr 24 11:25 appendonly.aof

提示:在输出信息的最后可以看出生成的appendonly.aof文件由74649125变成了41135984,这说明发生了AOF日志的重写。而AOF日志的重写由以下参数决定:

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb


三、剖析AOF持久化机制


在aof.c文件中可以找到创建RDB文件的函数flushAppendOnlyFile(),函数定义如下:

void flushAppendOnlyFile(int force) {
    //每秒刷入的时候,判断一下aof的fsync是否在bio线程里执行了
    if (server.aof_fsync == AOF_FSYNC_EVERYSEC)
    sync_in_progress = aofFsyncInProgress();
    
    //每秒并且非强制刷入
    if (server.aof_fsync == AOF_FSYNC_EVERYSEC && !force) {
        if (sync_in_progress) {
            //刷入延期开始时间为0,表示没有任何的执行
            if (server.aof_flush_postponed_start == 0) {
                    //先将刷入延期开始时间置为当前时间
                    server.aof_flush_postponed_start = server.unixtime;
                    return;
                }else if(server.unixtime -server.aof_flush_postponed_start<2){
                    return;
                }
                server.aof_delayed_fsync++;
        }
    }
    //写入到aof文件里
    nwritten = aofWrite(server.aof_fd,server.aof_buf,sdslen(server.aof_buf));
    //写完aof后,将刷入延期开始时间置为0
    server.aof_flush_postponed_start = 0;
    //省略异常的处理
    //记录aof当前的大小
    server.aof_current_size += nwritten;
    /**
    * aof的可用buf比较小了,就清空buf
    */
    if ((sdslen(server.aof_buf)+sdsavail(server.aof_buf)) < 4000) {
        sdsclear(server.aof_buf);
    } else {
        sdsfree(server.aof_buf);
        server.aof_buf = sdsempty();
    }
}



相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
打赏
0
5
6
0
192
分享
相关文章
告别数据僵尸!Redis实现自动清理过期键值对
在数据激增的时代,Redis如同内存管理的智能管家,支持键值对的自动过期功能,实现“数据保鲜”。通过`EXPIRE`设定生命倒计时、`TTL`查询剩余时间,结合惰性删除与定期清理策略,Redis高效维护内存秩序。本文以Python实战演示其过期机制,并提供最佳实践指南,助你掌握数据生命周期管理的艺术,让数据优雅退场。
105 0
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
215 67
Redis和Mysql如何保证数据⼀致?
1. 先更新Mysql,再更新Redis,如果更新Redis失败,可能仍然不⼀致 2. 先删除Redis缓存数据,再更新Mysql,再次查询的时候在将数据添加到缓存中 这种⽅案能解决1 ⽅案的问题,但是在⾼并发下性能较低,⽽且仍然会出现数据不⼀致的问题,⽐如线程1删除了 Redis缓存数据,正在更新Mysql,此时另外⼀个查询再查询,那么就会把Mysql中⽼数据⼜查到 Redis中 1. 使用MQ异步同步, 保证数据的最终一致性 我们项目中会根据业务情况 , 使用不同的方案来解决Redis和Mysql的一致性问题 : 1. 对于一些一致性要求不高的场景 , 不做处理例如 : 用户行为数据 ,
Redis分片集群中数据是怎么存储和读取的 ?
Redis集群采用的算法是哈希槽分区算法。Redis集群中有16384个哈希槽(槽的范围是 0 -16383,哈希槽),将不同的哈希槽分布在不同的Redis节点上面进行管理,也就是说每个Redis节点只负责一部分的哈希槽。在对数据进行操作的时候,集群会对使用CRC16算法对key进行计算并对16384取模(slot = CRC16(key)%16383),得到的结果就是 Key-Value 所放入的槽,通过这个值,去找到对应的槽所对应的Redis节点,然后直接到这个对应的节点上进行存取操作
Redis的数据淘汰策略有哪些 ?
Redis 提供 8 种数据淘汰策略: 淘汰易失数据(具有过期时间的数据) 1. volatile-lru(least recently used):从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰 2. volatile-lfu(least frequently used):从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰 3. volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰 4. volatile-random:从已设置过期
Redis的数据过期策略有哪些 ?
1. 惰性删除 :只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好,但是可能会造成太多过期 key 没有被删除。数据到达过期时间,不做处理。等下次访问该数据时,我们需要判断 a. 如果未过期,返回数据 b. 发现已过期,删除,返回nil 2. 定期删除 : 每隔一段时间抽取一批 key 执行删除过期 key 操作。并且,Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。默认情况下 Redis 定期检查的频率是每秒扫描 10 次,用于定期清除过期键。当然此值还可以通过配置文件进行设置,在 redis.conf 中修改配置“hz”
Redis的数据持久化策略有哪些 ?
Redis 提供了两种方式,实现数据的持久化到硬盘。 1. RDB 持久化(全量),是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 2. AOF持久化(增量),以日志的形式记录服务器所处理的每一个写、删除操作 RDB和AOF一起使用, 在Redis4.0版本支持混合持久化方式 ( 设置 aof-use-rdb-preamble yes )
【赵渝强老师】监控Redis
Redis 实例的监控是运维管理中的关键内容,主要包括内存、吞吐量、运行时信息和延时的监控。 1. **监控内存**:使用 `info memory` 可查看 Redis 内存使用情况,包括已用内存、峰值内存等。 2. **监控吞吐量**:通过 `info stats` 获取每秒处理命令数(OPS)、网络输入输出流量等。 3. **监控运行时信息**:利用 `info` 命令结合 `grep` 过滤出客户端连接数、拒绝连接数等重要信息。 4. **监控延时**:可以通过客户端手动监控或服务器内部延迟监控来检测延时问题。
137 3
Redis应用—2.在列表数据里的应用
本文介绍了基于数据库和缓存双写的分享贴功能设计,包括:基于数据库 + 缓存双写的分享贴功能、查询分享贴列表缓存时的延迟构建、分页列表惰性缓存方案、用户分享贴列表数据按页缓存实现精准过期控制、用户分享贴列表的分页缓存异步更新、数据库与缓存的分页数据一致性方案、热门用户分享贴列表的分页缓存失效时消除并发线程串行等待锁的影响。总结:该设计通过合理的缓存策略和异步处理机制,有效提升了系统性能,降低了内存占用,并确保了数据的一致性和高可用性。
Redis应用—2.在列表数据里的应用

相关产品

  • 云数据库 Tair(兼容 Redis)
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等

    登录插画

    登录以查看您的控制台资源

    管理云资源
    状态一览
    快捷访问