压缩文件太大了怎么办？

Posted 2023-04-23

很多时候我们压缩文件后压缩包还是太大，我们可以通过重新压缩的方式选择适当的格式和设置实现让压缩包变得更小，下面就告诉大家，压缩包太大怎么变小
首先可以将压缩包解压后，将文件全部选中，右键点击，去重新压缩文件。
然后弹出来的选项，点击【添加到压缩文件】选项。
然后在打开界面，点击【常规】选项。
然后在里面压缩文件格式中，勾选RAR格式，这个格式相对ZIP等其它格式可以压缩的更小一些。另外勾选【创建固实压缩文件】也可以让压缩包更小一些。
然后点击【确定】按钮，开始重新压缩文件。
压缩完成需要等待一会，压缩完成压缩包就会有所变小。 参考技术A

不知道你使用什么压缩软件，好压和winrar都有自定义压缩文件大小的功能。

可以选现成的大小分卷，也可以自定义大小。

另外，压缩格式不同最后生成的压缩文件大小也不同。据说7z格式压缩文件最小，没试过。

阿里二面：Redis 中的 AOF 文件太大了怎么办？

欢迎大家关注我的微信公众号【老周聊架构】，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 慢。