阿里二面：Redis 中的 AOF 文件太大了怎么办？_appendonly.aof_老周聊架构的博客-CSDN博客
阿里二面：Redis 中的 AOF 文件太大了怎么办？
置顶
老周聊架构
于 2021-06-03 00:07:51 发布
4957
收藏
60
分类专栏：
面试系列
Redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/riemann_/article/details/117447615
版权
面试系列
同时被 2 个专栏收录
5 篇文章
6 订阅
订阅专栏
Redis
13 篇文章
3 订阅
订阅专栏
欢迎大家关注我的微信公众号【老周聊架构】，Java后端主流技术栈的原理、源码分析、架构以及各种互联网高并发、高性能、高可用的解决方案。
一、前言
写这篇文章的目的是来自我的一位粉丝的投稿，说面试阿里被问到了这个问题。不得不说阿里的面试问的都挺有质量，一般的我们只会关注 Redis 的两种持久化方式 RDB 和 AOF。但老周这里盲猜面试的过程肯定也是先从持久化方式问起，然后循循渐进的问到 AOF 文件太大了怎么办？本着知其然知其所以然的态度，老周这里会带你从 RDB 和 AOF 的实现原理、各自的触发方式以及各自的应用场景来彻头彻尾了解 Redis 的持久化方式。
进入正文之前，我们先来问下自己这么两个问题？什么是 Redis 持久化？为啥需要 Redis 持久化？
Q1：什么是 Redis 持久化？
持久化就是把内存中的数据保存到硬盘中，使数据可以持久化保存。Redis 持久化有两种实现方式：RDB 和 AOF。
Q2：为啥需要 Redis 持久化？
Redis 是内存数据库，宕机后数据会消失。 Redis 重启后快速恢复数据，要提供持久化机制。
好了，知道了这两个问题后，我们就来看看 Redis 是如何将数据存储到硬盘里面，使得数据在 Redis 重启之后仍然存在的。
二、RDB
将 Redis 某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为 dump.rdb，而在 Redis 服务器启动时，会重新加载 dump.rdb 文件的数据到内存中。
2.1 开启 RDB 持久化方式
2.1.1 save 命令
127.0.0.1:6379> save
OK
save 命令是一个同步操作。当客户端向服务器发送 save 命令请求进行持久化时，服务器会阻塞 save 命令之后的其他客户端的请求，直到数据同步完成。
如果数据量太大，同步数据会执行很久，这期间 Redis 服务器也无法接收其他请求，导致不可用。
线上的 Redis 环境不建议使用此命令
2.1.2 bgsave 命令
127.0.0.1:6379> bgsave
Background saving started
与 save 命令不同，bgsave 命令是一个异步操作。当客户端发出 bgsave 命令时，Redis 服务器主进程会 fork 一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求，子进程会在数据保存到 rdb 文件后退出。
这里我们来思考一个问题，既然 Redis 要处理客户端的请求又要同时持久化，那持久化的同时，内存数据结构还在改变，比如一个 hash 字典正在持久化，结果一个请求过来把它给删掉了，可是还没有持久化完呢，这会不会导致持久化的数据不一致啊？
Redis 使用的操作系统的多进程 COW（Copy On Write）机制来实现快照持久化，也就是我们这里的 RDB 持久化方式。
如上图，Redis 会使用操作系统的 COW 机制来进行数据段页面的分离，数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改，这时子进程相应的页面是没有变化的，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为啥 RDB 持久化为啥叫快照持久化的原因。
2.1.3 服务器配置定期自动触发
在 redis.conf 中配置: save 多少秒内数据变了多少
# save "" # 不使用RDB存储 不能主从
# save 900 1 # 表示15分钟(900秒钟)内至少1个键被更改则进行快照。
# save 300 10 # 表示5分钟(300秒)内至少10个键被更改则进行快照。
# save 60 10000 # 表示1分钟内至少10000个键被更改则进行快照。
通过配置文件触发持久化的方式与 bgsave 命令类似，达到触发条件时会 fork 一个子进程进行数据保存。
线上的 Redis 环境不建议使用此方式。因为设置触发的时间太短，则容易频繁写入 rdb 文件，影响服务器性能，时间设置太长则会造成数据丢失。
2.2 RDB 执行流程（原理）
Redis 父进程首先判断：当前是否在执行 save、bgsave 或 bgrewriteaof（aof 文件重写命令）的子进程，如果在执行则 bgsave 命令直接返回。（不能同时执行的原因是出于性能方面考虑，并发出两个子进程，并且这两个子进程都同时执行大量的磁盘写入操作，对性能会产生影响。）父进程执行 fork（调用 OS 函数复制主进程）操作创建子进程，这个过程中父进程是非阻塞的，Redis 能执行来自客户端的其它命令。子进程创建 RDB 文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换。 （RDB 始终完整）子进程发送信号给父进程表示完成，父进程更新统计信息。父进程 fork 子进程后，继续工作。
2.3 RDB 文件结构
2.3.1 REDIS
RDB 文件的开头部分是 REDIS 部分，这个部分长度为 5 个字节，保存着 “REDIS” 五个字符。通过这五个字符，程序在载入文件时，可以快速检查该文件是否是 RDB 文件。
2.3.2 db_version
db_version 长度为 4 个字节，值是一个字符串表示的整数，这个整数记录的是 RDB 文件的版本号（不是 Redis 版本号），比如 “0006” 就代表 RDB 文件的版本为第六版。
2.3.3 databases
一个 RDB 文件的 databases 部分可以保存任意多个非空数据库。
例如，如果服务器的 0 号数据库和 3 号数据库非空，那么服务器将创建如下图的 RDB 文件，图中的 database 0 代表 0 号数据库所有键值对数据，而 database 3 代表 3 号数据库所有键值对数据。
每个非空数据库在 RDB 文件中都可以保存为 SELECTDB、db_number、key_value_pairs 三个部分。如下图所示：
SELECTDB 常量的长度为 1 个字节，当读入程序遇到这个值的时候，它知道接下来要读入的是一个数据库号码。
db_number 保存着一个数据库号码，根据读入的数据库号码进行数据库切换，使得之后读入的键值对可以载入到正确的数据库中。
key_value_pairs 保存着数据库中所有键值对数据，如果键值对带有过期时间的话，那么键值对的过期时间也会保存在内。
2.3.4 EOF
结束标志
2.3.5 check_sum
校验和，就是看文件是否损坏，或者是否被修改。
最后再来看一下一个完整的 RDB 文件，如下图所示：
三、AOF
AOF（Append Only File）持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以 Redis 协议追加保存到以后缀为 aof 文件末尾，在 Redis 服务器重启时，会加载并运行 aof 文件的命令，以达到恢复数据的目的。
AOF 会记录过程，RDB 只管结果。
3.1 开启 AOF 持久化方式
Redis 默认不开启 AOF 持久化方式，我们可以在 redis.conf 配置文件中开启并进行更加详细的配置。
appendonly no # 默认不开启，需要开启的话要改成yes。
appendfilename "appendonly.aof" # aof文件名
dir ./ # AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。
# appendfsync always # 写入策略
appendfsync everysec # 写入策略
# appendfsync no # 写入策略
no-appendfsync-on-rewrite no # 默认不重写aof文件
3.2 AOF 执行原理
AOF 文件中存储的是 redis 的命令，同步命令到 AOF 文件的整个过程可以分为三个阶段：
命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。缓存追加：AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。文件写入和保存：AOF 缓存中的内容被写入到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话， fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。
3.2.1 命令传播
当一个 Redis 客户端需要执行命令时， 它通过网络连接， 将协议文本发送给 Redis 服务器。服务器在接到客户端的请求之后， 它会根据协议文本的内容， 选择适当的命令函数， 并将各个参数从字符串文本转换为 Redis 字符串对象（StringObject）。每当命令函数成功执行之后，命令参数都会被传播到 AOF 程序。
3.2.2 缓存追加
当命令被传播到 AOF 程序之后，程序会根据命令以及命令的参数，将命令从字符串对象转换回原来的协议文本。协议文本生成之后，它会被追加到 redis.h/redisServer 结构的 aof_buf 末尾。
redisServer 结构维持着 Redis 服务器的状态，aof_buf 域则保存着所有等待写入到 AOF 文件的协议文本(RESP)。
3.2.3 文件写入和保存
每当服务器常规任务函数被执行、或者事件处理器被执行时，aof.c/flushAppendOnlyFile 函数都会被调用，这个函数执行以下两个工作：
WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。
为了提高文件写入效率，在现代操作系统中，当用户调用 write 函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。
这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失。因此系统同时提供了 fsync、fdatasync 等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。
3.2.4 AOF 保存模式
AOF 缓存区的同步文件策略由参数 appendfsync 控制，各个值的含义如下：
AOF_FSYNC_NO：不保存。AOF_FSYNC_EVERYSEC：每一秒钟保存一次。(默认)AOF_FSYNC_ALWAYS：每执行一个命令保存一次。(不推荐)
3.2.4.1 AOF_FSYNC_NO
在这种模式下， 每次调用 flushAppendOnlyFile 函数， WRITE 都会被执行， 但 SAVE 会被略过。
在这种模式下， SAVE 只会在以下任意一种情况中被执行：
Redis 被关闭AOF 功能被关闭系统的写缓存被刷新(可能是缓存已经被写满，或者定期保存操作被执行)
这三种情况下的 SAVE 操作都会引起 Redis 主进程阻塞。
3.2.4.2 AOF_FSYNC_EVERYSEC
在这种模式中，SAVE 原则上每隔一秒钟就会执行一次，因为 SAVE 操作是由后台子进程（fork）调用的，所以它不会引起服务器主进程阻塞。
3.2.4.3 AOF_FSYNC_ALWAYS
在这种模式下，每次执行完一个命令之后， WRITE 和 SAVE 都会被执行。
另外，因为 SAVE 是由 Redis 主进程执行的，所以在 SAVE 执行期间，主进程会被阻塞，不能接受命令请求。
对于三种 AOF 保存模式， 它们对服务器主进程的阻塞情况如下：
四、AOF 重写
4.1 AOF 文件重写的原理
前面了解完 RDB 和 AOF 两种持久化方式的原理后，我们再来来看我那粉丝读者的阿里面试题：Redis 中的 AOF 文件太大了怎么办？
这就要用到 AOF 的重写机制了。因为 AOF 持久化是通过保存被执行的写命令来记录数据库状态的，随着 AOF 文件内容越来越多，文件的体积也越来越大。如果不对 AOF 文件加以管控的话，可能会对 Redis 服务器产生影响。
举个例子，如果客户端执行了以下命令：
rpush list 1 2 // [1,2]
rpush list 3 // [1,2,3]
rpush list 4 5 6 // [1,2,3,4,5,6]
lpop list 1 // [2,3,4,5,6]
lpop list 2 // [3,4,5,6]
rpush list 7 // [3,4,5,6,7]
那么光记录 list 这个状态，AOF 文件就需要保存六条命令。实际线上的应用，写命令肯定比这频繁而且体积更大，更何况线上要记录很多个 key 的状态。
为了解决 AOF 文件体积膨胀的问题，Redis 提供了文件重写（rewrite）功能。通过该功能，Redis 服务器可以创建一个新的 AOF 文件来代替旧的 AOF 文件，重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 所谓的“重写”其实是一个有歧义的词语，实际上，AOF 重写并不需要对原有旧的 AOF 文件进行任何写入和读取，新旧两个 AOF 文件所保存的数据库状态相同，但新的 AOF 文件不会包含任何浪费空间的冗余命令，所以新的 AOF 文件体积通常比旧的 AOF 文件体积小得多。
从上面可以看到，为了记录 list 这个状态，AOF 文件就需要保存六条命令。如果服务器想要用尽量少的命令来记录 list 键的状态，那么最简单高效的办法不是去读取和分析现有 AOF 文件的内容，而是直接从数据库中读取键 list 的值，然后用 rpush list 3 4 5 6 7 命令来代替保存在 AOF 文件中的六条命令，这样就可以将保存在 list 键所需的命令从六条减到一条了。
除了上面的集合键以外，其它所有类型的键都可以用同样的方法去减少 AOF 文件中的命令数量。首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是 AOF 重写功能的实现原理。
4.2 AOF 后台重写
上面的 AOF 重写功能是通过 aof_rewrite 函数来实现的，但这个函数会进行大量的写操作，所以调用这个线程将被长时间阻塞，因为 Redis 服务器使用单线程来处理命令请求，所以如果服务器直接调用 aof_rewrite 函数的话，那么重写 AOF 文件期间，服务器将无法处理客户端发来的命令请求。
Redis 不希望 AOF 重写造成服务器无法处理请求， 所以 Redis 决定将 AOF 重写程序放到后台子进程里执行， 这样处理的最大好处是：
子进程进行 AOF 重写期间，主进程可以继续处理命令请求。子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。
不过，使用子进程也有一个问题需要解决：因为子进程在进行 AOF 重写期间，主进程还需要继续处理 命令，而新的命令可能对现有的数据进行修改，这会让当前数据库的数据和重写后的 AOF 文件中的数 据不一致。
为了解决这个问题，Redis 增加了一个 AOF 重写缓存，这个缓存在 fork 出子进程之后开始启用，Redis 主进程在接到新的写命令之后，除了会将这个写命令的协议内容追加到现有的 AOF 文件之外，还会追加到这个缓存中。
4.3 重写过程分析
Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生 停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到 新 AOF 文件，并开始对新 AOF 文件进行追加操作。
当子进程在执行 AOF 重写时， 主进程需要执行以下三个工作：
处理命令请求将写命令追加到现有的 AOF 文件中将写命令追加到 AOF 重写缓存中
这样一来可以保证：
现有的 AOF 功能会继续执行，即使在 AOF 重写期间发生停机，也不会有任何数据丢失。所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。当子进程完成 AOF 重写之后，它会向父进程发送一个完成信号，父进程在接到完成信号之后，会调用 一个信号处理函数，并完成以下工作：
将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。
这个信号处理函数执行完毕之后，主进程就可以继续像往常一样接受命令请求了。在整个 AOF 后台重 写过程中，只有最后的写入缓存和改名操作会造成主进程阻塞，在其他时候，AOF 后台重写都不会对主进程造成阻塞，这将 AOF 重写对性能造成的影响降到了最低。
以上就是 AOF 后台重写，也即是 BGREWRITEAOF 命令的工作原理。
4.4 触发方式
4.4.1 配置触发
在 redis.conf 中配置
# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
auto-aof-rewrite-min-size 64mb
4.4.2 执行 bgrewriteaof 命令
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
五、Redis 4.0 混合持久化
重启 Redis 时，我们很少会使用 RDB 来恢复内存状态，因为会丢失大量数据（会丢失最后一次快照以后更改的所有数据）。我们通常使用 AOF 日志重放，但是重放 AOF 日志相对于使用 RDB 来说要慢很多，这样在 Redis 实例很大的时候，启动需要花费很长的时间。
Redis 4.0 为了解决这个问题，一个新的持久化方式——混合持久化出来了。如下图，将 RDB 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。
如果把混合持久化打开，aof rewrite 的时候就直接把 rdb 的内容写到 aof 文件开头。
开启混合持久化 aof-use-rdb-preamble yes
我们可以看到该 AOF 文件是 rdb 文件的头和 aof 格式的内容，在加载时，首先会识别 AOF 文件是否以 REDIS 字符串开头，如果是就按 RDB 格式加载，加载完 RDB 后继续按 AOF 格式加载剩余部分。这样的话就可以完全替代之前的 AOF 全量文件重放，重启效率因此得到大幅提升。
六、RDB 与 AOF 的对比
6.1 RDB
优点：
与 AOF 方式相比，通过 rdb 文件恢复数据比较快。RDB 是二进制压缩文件，占用空间小，便于传输（传给 slaver）、数据备份等。通过 RDB 进行数据备份，由于主进程 fork 子进程来进行持久化，所以对 Redis 服务器性能影响较小。
缺点：
如果服务器宕机的话，采用 RDB 的方式会造成某个时段内数据的丢失，比如我们设置 5 分钟达到 1000 次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。使用 save 命令会造成服务器阻塞，直到数据同步完成才能接收后续请求。使用 bgsave 命令在 fork 子进程时，如果数据量太大，fork 的过程也会发生阻塞，另外，fork 子进程会耗费内存。
6.2 AOF
优点：
AOF 设置为每秒保存一次，则最多丢 2 秒的数据。数据丢失相对 RDB 来说更少。AOF 写入文件时，对过期的 key 会追加一条 del 命令，当执行 AOF 重写时，会忽略过期 key 和 del 命令。
缺点：
生成的日志文件太大，即使通过 AOF 重写，文件体积仍然很大。恢复数据的速度比 RDB 慢。
阅读终点，创作起航，您可以撰写心得或摘录文章要点写篇博文。去创作
老周聊架构
关注
关注
17
点赞
60
收藏
觉得还不错?
一键收藏
打赏
知道了
17
评论
阿里二面：Redis 中的 AOF 文件太大了怎么办？
欢迎大家关注我的微信公众号【老周聊架构】，Java后端主流技术栈的原理、源码分析、架构以及各种互联网高并发、高性能、高可用的解决方案。一、前言写这篇文章的目的是来自我的一位粉丝的投稿，说面试阿里被问到了这个问题。不得不说阿里的面试问的都挺有质量，一般的我们只会关注 Redis 的两种持久化方式 RDB 和 AOF。但老周这里盲猜面试的过程肯定也是先从持久化方式问起，然后循循渐进的问到 AOF 文件太大了怎么办？本着知其然知其所以然的态度，老周这里会带你从 RDB 和 AOF 的实现原理、各自的触发方.
复制链接
扫一扫
专栏目录
面渣逆袭：Redis连环五十二问，图文详解，这下面试稳了！.doc
07-08
面渣逆袭：Redis连环五十二问，图文详解，这下面试稳了！.doc
redis配置文件aof持久化方式
12-18
redis配置文件aof持久化方式，修改了redis密码为123456
17 条评论
您还未登录，请先
登录
后发表或查看评论
redis的AOF文件越来越大该怎么解决？
9527
09-05
5088
使用rewirte机制，rewrite机制现在达到一定的条件redis会自动触发
其具体的流程就是：
1，redis主进程fork一个子进程
2，子进程根据当前内存的数据，构建一个新的日志，写入一个新的AOF文件中
3，这段时间内，redis接收到的client的修改操作，都会在内存中新起一个日志文件去进入，并同步到旧的AOF文件中
4，当子进程完成了任务，redis就会把新的日志文件追加到新的A...
redis解决aof文件占用过大
热门推荐
微鸽
06-24
1万+
一、背景
1. AOF
Redis的AOF机制有点类似于Mysql binlog，是Redis的提供的一种持久化方式（另一种是RDB），它会将所有的写命令按照一定频率(no, always, every seconds)写入到日志文件中，当Redis停机重启后恢复数据库。
2. AOF重写
(1) 随着AOF文件越来越大，里面会有大部分是重复命令或者可以合并的命令（100次incr = set...
关于Redis持久化缓存导致appendonly.aof文件过大，磁盘空间占满
AirIT的博客
03-17
637
中科方德系统关于Redis持久化缓存导致appendonly.aof文件过大，磁盘空间占满
Redis持久化中的AOF(Append Only File)持久化
xzy的博客
03-16
6514
文章目录Redis持久化中的AOF(Append Only File)持久化开启aof持久化aof持久化的时候appendonly.aof持久化文件是什么时候生成的？appendonly.aof文件中的数据是什么时候怎样恢复到redis数据库中的？怎样把appendonly.aof持久化文件里面的数据恢复到redis数据库中？使用redis-check-aof工具校验appendonly.aof持久化文件中的内容aof持久化的时候缓存中的内容同步到硬盘的三种方式在什么情况下redis数据库中写的命令可以追加
Redis持久化之AOF找不到appendonly.aof文件
S903784597的博客
06-10
2696
在redis中，AOF持久化会默认在/usr/local/bin/ 目录下生成名字为appendonly.aof的持久化文件，AOF模式是默认不开启的。需要手动修改redis.conf 配置文件 。将appendonly配置项的值修改为yes才能开启。开启之后必须重启reids-server服务器。如果使用的是redis7以及以上版本，在bin目录下我们找不到appendonly.aof文件。这是因为在redis7中关于AOF持久化有一个更新操作。AOF持久化不再是以单独的文件存在，而是生成一个append
Redis持久化之AOF
Blue_Pepsi_Cola的博客
12-22
964
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof官方推荐两个都启用。如果对数据不敏感，可以选单独用RDB。不建议单独用 AOF，因为可能会出现Bug。如果只是做纯内存缓存，可以都不用。
reids清理日志文件
qq_30920479的博客
06-10
3185
最近redis遇到一个问题appendonly.aof文件过大，appendonly.aof类似mysql的bin-log日志，一般2.5以后的版本是会自动快照合并清理的，但是我之前redis做主从后没有做自动清理，发现这个文件突然大的无法正常启动redis，清理方法其实也很简单执行命令，当然redis-cli目录要换成自己的目录ip和密码也要换成自己的，执行后提示Background append only file rewriting started说明后台在创建快照合并文件，最后会重新替换文件，此时进
Redis持久化之AOF（Append Only File）
一些学习笔记而已
12-16
403
1、AOF（Append Only File）是什么
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
2、AOF持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同.
redis-replicator:Redis复制工具。 支持同步，psync，psync2。 可以解析rdb，aof，混合的rdb和aof文件。 支持redis-6.2
05-02
目录（）
2.4。 选择一个版本
3.使用简单
3.1。 用法
3.2。 备份远程RDB快照
3.3。 备份远程命令
3.4。 将RDB转换为转储格式
3.5。 RDB检查
3.6。 其他例子
4.高级主题
4.1。 命令扩展
4.1.1。 编写命令
4.1.2。 编写命令解析器
4.1.3。 注册此解析器
4.1.4。 处理命令事件
4.1.5。 放在一起
4.2。 模块扩展
4.2.1。 编译redis测试模块
4.2.2。 在redis.conf中打开评论
4.2.3。 编写模块解析器
4.2.4。 编写命令解析器
4.2.5。 注册此模块解析器和命令解析器并处理事件
4.2.6。 放在一起
4.3。 溪流
4.4。 编写自己的rdb解析器
4.5。 Redis URI
5.其他主题
5.1。 内置命令解析器
5.2。 EOFException
5.3。 跟踪事件日志
5.4。
redis2.8配置文件中文翻译版
09-10
主要介绍了redis2.8配置文件中文翻译版,本文翻译了配置文件中的参数说明,非常详细,需要的朋友可以参考下
【Redis持久化原理之AOF(Append Only File)】
Coder_ljw的博客
10-16
281
【Redis持久化原理之AOF(Append Only File)、aof持久化原理、aof持久化配置文件的相关参数设置、aof持久化悲愤注意的事项、aof重写过程的手动触发以及自动触发、aof持久化的优缺点、持久化使用的建议】 所谓的持久化就是保持我们的数据不丢失，将数据通常保存在我们的硬盘中。由于 Redis 会不断地将被执行的命令记录到 AOF 文件里面，所以随着 Redis 不断运行，AOF 文件的体积会越来越大。另外，如果 AOF 文件的体积很大，那么还原操作所需要的时间也会非常地长。
[redis 源码走读] aof 持久化 (上)
wenfh2020的专栏
04-05
163
aof (Append Only File) 是 redis 持久化的其中一种方式。
服务器接收的每个写入操作命令，都会追加记录到 aof 文件末尾，当服务器重新启动时，记录的命令会重新载入到服务器内存还原数据。这一章我们走读一下源码，看看 aof 持久化的数据结构和应用场景是怎样的。
主要源码逻辑在 aof.c 文件中。
此博客将逐步迁移到作者新的博客，可以点击此处进入。
文章目录开启 a...
redis默认读取appendonly.aof文件
mhbsoft的博客
12-15
1414
dump.rdb 与 appendonly.aof 同时存在的情况下，默认优先读取appendonly.aof文件。如果appendonly.aof有错误，则启动会失败。
vim appendonly.aof
*2
$6
SELECT
$1
...
v3
dfsdfsdfsdfsdfsd;;;;;;;;sdfsdf;;;;;;;sd;f;;; // 乱加的
启动失败：
[mhbtest@root redis-5.0.4]$ src/redis-server redis_aof.conf
19838:
随笔 redis由于aof错误无法启动
全场梦游c的博客
06-17
566
闲来无事将一个aof文件复制到自己的redis服务器上，修改配置后，重启redis发现启动失败。
想必是aof的原因，就使用redis自带的检查工具进行清理了一下。
redis-check-aof --fix appendonly.aof
清理完毕，启动成功
...
Redis持久化--AOF
WhataNerd的博客
08-06
138
Redis的数据持久化方式有 RDB 和 AOF 两种，这篇文章将会讲解 AOF
AOF是什么
AOF（Append Only File）以日志形式记录服务器收到的每一个写操作
AOF怎么进行持久化
使用AOF默认会在当前目录下生成一个 appendonly.aof 日志文件
在恢复数据时，AOF会将appendonly.aof中记录下的所有写操作重新按顺序执行一遍
以下是appendonly.a...
redis AOF持久化
weixin_41002194的博客
01-06
237
用户执行的每个“写”指令都备份到文件中
精细持久化
开启AOF快照持久化(会清空redis内部的数据)
appendonly yes AOF持久化开启开关
aof追加持久化的备份频率
appendfsync always 每次修改就备份
appendfsync everysec 每秒钟就备份一次(推荐)
appendfsync no 根据当前服务器性能对比，性能空闲的话就去备份
aof备份...
你作为一个Java领域的专家，请完成以下任务：redis数据丢失怎么办？
最新发布
05-19
如果 Redis 数据发生丢失，我们可以考虑以下一些方法：
1. 通过 Redis 的 AOF（Append Only File）和 RDB（Redis Database Backup）两种持久化方式中的一种来恢复数据。AOF 持久化方式会将每次写操作都记录在一个文件中，可用于恢复数据；RDB 则是将 Redis 的数据按照一定的规则定期备份到一个 RDB 文件中，也可以用于恢复数据。
2. 如果 Redis 没有开启持久化，我们可以尝试从备份的 Redis 数据库中恢复数据。备份可以使用 Redis 自带的 bgsave 命令或者第三方工具如 Redis-dump 等来进行。
3. 可以尝试在 Redis 的配置文件 redis.conf 中开启 appendonly 参数，让 Redis 开启 AOF 持久化方式，从而避免数据丢失的情况。
4. 如果以上方法都无法恢复数据，我们需要考虑使用 Redis 的集群功能，将数据分散到多个节点上，从而避免单点故障导致数据丢失的情况。
总之，在 Redis 数据丢失的情况下，我们需要根据具体情况采取不同的措施，以尽可能地恢复数据。同时，我们也应该注意对 Redis 数据的持久化和备份，以避免数据丢失的情况的发生。
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
老周聊架构
CSDN认证博客专家
CSDN认证企业博客
码龄7年
Java领域优质创作者
555
原创
3356
周排名
2万+
总排名
172万+
访问
等级
1万+
积分
3万+
粉丝
2789
获赞
1352
评论
9484
收藏
私信
关注
试试用AI创作助手写篇关于阿里二面：Redis 中的 AOF 文件太大了怎么办？的文章吧
用AI写文章
热门文章
一文读懂 Spring Bean 的生命周期
80065
Java实现分页功能常见的几种方法
77123
java实现调用http请求的几种常见方式
68819
聚集索引和非聚集索引的区别
59810
Java深入理解深拷贝和浅拷贝区别
48512
分类专栏
我的架构梦
付费
98篇
ChatGPT
响应式编程
3篇
数学
1篇
Kafka
16篇
聊聊系列
19篇
K8S
1篇
云原生
1篇
面试系列
5篇
一文读懂系列
7篇
Pulsar
3篇
物联网
2篇
MQTT
2篇
深入浅出系列
1篇
源码分析系列
互联网解决方案
4篇
实践系列
2篇
Java
66篇
SpringBoot
23篇
SpringCloud
19篇
JVM
20篇
MySQL
35篇
数据结构与算法
33篇
Java设计模式
24篇
Java并发编程
25篇
Git
16篇
Scala
1篇
Nginx
1篇
HBase
1篇
Lombok
1篇
LeetCode
17篇
Nowcoder
17篇
Tools
3篇
年终总结
4篇
事务
2篇
Codeforces-Problemset
7篇
EasyExcel
2篇
Codeforces-Contests
4篇
Shiro
1篇
Spring全家桶
5篇
Python
2篇
深度学习
1篇
Linux
8篇
Java面经
33篇
Redis
13篇
Skill
5篇
HTTP
6篇
PowerDesigner
2篇
前端
7篇
Spring
9篇
Gradle
2篇
Druid
1篇
Java架构设计与分布式
5篇
源码解读
14篇
IntelliJ IDEA
5篇
Maven
3篇
程序人生
1篇
Exception
21篇
POI
1篇
MyBatis
4篇
RESTful
1篇
Webservice
1篇
FreeMarker
1篇
Quartz
1篇
Books
4篇
Go
2篇
Java新特性
3篇
MQ
4篇
最新评论
一文读懂 Spring Bean 的生命周期
留围冰:
点赞写的很好啊，指出一个问题博主确认下：3.2.1 的第四张图片的注释2有问题，应该是内部遍历调用 postProcessAfterInitialization 方法
亿级用户游戏排行榜设计方案
Mars Chen:
如果数据需要存储玩家的上榜数据呢?
一文读懂 Spring Bean 的生命周期
壹晴天:
真他么写的棒，哈哈哈。现在就缺各个方法的应用场景了
聊聊 Kafka：Kafka 消息丢失的场景以及最佳实践
Hermes333:
请问一下，您在前言中提到实际业务中造成的数据丢失，对丢失的数据是如何处理的，可以恢复这部分丢失的数据吗？
Java深入理解深拷贝和浅拷贝区别
陈壮实的搬砖生活:
不是针对所有属性吧，只是针对对象属性吧
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
新一代通信协议—— RSocket
响应式流的核心机制——背压机制
Spring 响应式编程，真香！！！
2023年3篇
2022年19篇
2021年66篇
2020年152篇
2019年312篇
2018年5篇
目录
目录
分类专栏
我的架构梦
付费
98篇
ChatGPT
响应式编程
3篇
数学
1篇
Kafka
16篇
聊聊系列
19篇
K8S
1篇
云原生
1篇
面试系列
5篇
一文读懂系列
7篇
Pulsar
3篇
物联网
2篇
MQTT
2篇
深入浅出系列
1篇
源码分析系列
互联网解决方案
4篇
实践系列
2篇
Java
66篇
SpringBoot
23篇
SpringCloud
19篇
JVM
20篇
MySQL
35篇
数据结构与算法
33篇
Java设计模式
24篇
Java并发编程
25篇
Git
16篇
Scala
1篇
Nginx
1篇
HBase
1篇
Lombok
1篇
LeetCode
17篇
Nowcoder
17篇
Tools
3篇
年终总结
4篇
事务
2篇
Codeforces-Problemset
7篇
EasyExcel
2篇
Codeforces-Contests
4篇
Shiro
1篇
Spring全家桶
5篇
Python
2篇
深度学习
1篇
Linux
8篇
Java面经
33篇
Redis
13篇
Skill
5篇
HTTP
6篇
PowerDesigner
2篇
前端
7篇
Spring
9篇
Gradle
2篇
Druid
1篇
Java架构设计与分布式
5篇
源码解读
14篇
IntelliJ IDEA
5篇
Maven
3篇
程序人生
1篇
Exception
21篇
POI
1篇
MyBatis
4篇
RESTful
1篇
Webservice
1篇
FreeMarker
1篇
Quartz
1篇
Books
4篇
Go
2篇
Java新特性
3篇
MQ
4篇
目录
评论 17
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
添加红包
祝福语
请填写红包祝福语或标题
红包数量
红包个数最小为10个
红包总金额
红包金额最低5元
余额支付
当前余额3.43元
前往充值 >
需支付：10.00元
取消
确定
下一步
知道了
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝
规则
hope_wisdom 发出的红包
打赏作者
老周聊架构
你的鼓励将是我创作的最大动力
¥1
¥2
¥4
¥6
¥10
¥20
扫码支付：¥1
获取中
扫码支付
您的余额不足，请更换扫码支付或充值
打赏作者
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。
余额充值