redis清理aof文件那些事儿，怎么通过删减节省空间不踩坑

说到Redis的AOF文件，它就像是一个特别尽职尽责的记账先生，你把数据变动的每一个命令，比如SET、HSET、LPUSH这些，它都一笔一划地给你记下来，写在一个本子上，这个本子就是AOF文件，这样做的好处是万一Redis突然宕机了，重启的时候把这个账本从头到尾翻一遍，重新执行一遍里面的命令，数据就能恢复如初,非常安全。

但时间一长，问题就来了，这个账本会变得特别厚，比如你只是反复修改同一个键的值，比如一个计数器的值从1加到10000，那么账本里就会密密麻麻地记上一万条INCR命令，但实际上，最终我们只关心这个计数器现在是10000，前面那9999条记录其实都是可以丢弃的“中间过程”，这个越来越厚的AOF文件不仅占用了大量磁盘空间，在Redis重启恢复数据时,逐条执行这些命令也会变得非常非常慢。

我们得想办法给这个账本“瘦身”，既节省空间，又不影响数据安全，Redis自己就提供了两种主要的瘦身方式，但用法和效果不一样,得搞清楚。

第一种方式，叫做“AOF重写”，这个不是我们手动去编辑AOF文件（绝对禁止直接手动修改AOF文件，很容易导致文件损坏，数据全丢），而是由Redis主动发起的一个后台过程，你可以通过执行命令BGREWRITEAOF来触发它，这个过程非常聪明，它不看现有的那个庞大的AOF文件，而是直接去检查当前数据库里所有数据的状态，然后为每一个存在的键值对，生成一条最新的、最简洁的命令,写入一个新的AOF临时文件。

还拿那个计数器举例，旧AOF文件里可能有一万条INCR记录，但重写后生成的新AOF文件里，只会有一条最直接的命令：SET counter 10000，这样一来，文件大小就急剧缩小了，等这个新的、精简的AOF文件生成完毕，Redis就会用它替换掉旧的、臃肿的AOF文件，这个方法是官方推荐的、最安全的清理方式。

第二种方式，是在Redis的配置文件redis.conf里设置自动触发重写的条件，你可以配置两个关键参数：auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，你可以设置当AOF文件体积比上一次重写后的大小增长了100%（也就是翻了一倍），并且这个增长后的文件大小至少达到64MB时，Redis就会自动在后台启动一个重写过程，这样就不用我们老是手动去敲命令了,实现了自动化管理。

除了重写，还有一个相关的配置项叫auto-aof-rewrite-min-size，它属于另一种持久化策略的混合使用，但这里我们主要谈AOF，有时候你可能还会听到“AOF重写”的过程中，新的命令会同时被记录到一块缓冲区（AOF重写缓冲区），这是为了保证在重写这段时间内，新的数据变动也不会丢失，最终会被追加到新的AOF文件中,确保数据的完整性。

有没有更“狠”一点的节省空间的方法呢？有，但风险也更大，那就是改变AOF的持久化策略，在redis.conf里，appendfsync这个配置项控制着记账先生写账本的勤快程度，默认是everysec，意思是每秒刷一次盘，在性能和安全性之间是个很好的平衡，你也可以设置为no，让操作系统来决定何时写盘，这样性能最高，但万一服务器宕机，可能会丢失比较多数据，或者设置为always，每个命令都立刻写盘，最安全，但性能开销最大，磁盘IO会很高。不建议为了省空间而轻易将appendfsync改为no，除非你的业务能容忍分钟级别的数据丢失。

给Redis的AOF文件清理瘦身，核心就是利用好Redis自身提供的AOF重写机制，无论是手动触发还是自动触发，这是唯一安全可靠的方法，切记不要打直接删除或修改AOF文件的主意，要根据业务对数据安全性的要求，谨慎调整持久化策略的同步频率，做好这几点，就能在节省磁盘空间和保证数据安全之间找到一个稳妥的平衡点,不会踩到坑。