Redis硬盘空间到底怎么就那么大了，数据啥时候开始占用这么多地方？

（引用来源：Redis官方文档关于内存优化的章节、阿里云开发者社区关于Redis内存占用的案例分析、某技术博客对Redis持久化文件大小的实际测试）

Redis的硬盘空间突然变得很大,或者你发现它占用的地方比你预想的要多得多，这确实是一个很让人头疼的问题，感觉就像是家里明明没多少东西，但衣柜却塞得满满当当，还关不上门，这通常不是因为你的数据本身有那么“胖”，而是Redis在背后为了让你用得更快更爽，偷偷做了不少“准备工作”，这些准备工作都是要占地方的，咱们就来掰扯掰扯，这些地方到底被谁占去了。

最容易被忽略的一点,就是Redis不仅仅是在内存里存了你的数据就完事了，为了保证数据不丢，它会把内存里的数据找个时间“拍个快照”，存到硬盘上，这个快照文件就是RDB文件，它还会像个记账先生一样，把所有的写操作命令一条一条地记在一个日志文件里，这个就是AOF文件，问题常常就出在这两个“备份”文件上。

先说RDB快照,这个快照是某个时间点你所有数据的一个完整拷贝，听起来很合理对吧？但Redis为了生成这个快照的效率，会用到一个叫“写时复制”的机制，简单说就是，当Redis要开始创建快照的时候，它并不会马上把内存里所有数据都复制一遍，而是先“fork”（分叉）出一个和它自己一模一样的子进程，让这个子进程去安心地写硬盘，这个子进程看到的内存数据和父进程是一模一样的，如果在子进程写硬盘的过程中，父进程（也就是主要干活的Redis）修改了某条数据，那么操作系统为了保证子进程看到的数据还是那个“快照时刻”的样子，就会把被修改的那块数据复制一份副本出来，让父进程去改那个副本，这样一来，在最不凑巧的情况下，比如你数据量很大，而且在做RDB持久化时写操作又特别频繁，那么内存占用量可能会瞬间翻倍，虽然这个额外的内存占用在RDB文件生成完后会释放，但如果你同时开启了AOF重写（下面会讲到），或者服务器内存本来就不够，这个瞬间的峰值就可能引发问题，甚至导致Redis因为内存不足而崩溃，而RDB文件本身，因为是数据的完整备份，它的大小基本上就和你数据集的大小成正比。

再说AOF日志文件,这才是硬盘空间增长的“大户”，你每执行一条能让数据发生变化的命令（比如set, hset, lpush等），Redis默认都会把这条命令追加到AOF文件的末尾，日积月累，这个文件会变得非常大，你有一个计数器，被修改了100万次，那么AOF文件里就会老老实实地记录100万次“set counter xxx”的命令，但实际上，这个计数器最终的值只有一个数字是有用的，前面那999,999条记录都是“过期”信息，这就像是你记日记，不是只记今天最终的结果，而是把一天里每一个想法、每一个动作都记下来，日记本当然会变得巨厚无比。

为了解决AOF文件不断膨胀的问题,Redis提供了“AOF重写”机制，这个机制很聪明，它会创建一个新的AOF文件，这个文件不是简单地复制旧的命令，而是会读取当前数据库的状态，然后只用最精简的命令序列来重建当前的数据集，还是那个计数器的例子，重写后，新的AOF文件里可能就只剩下一句“set counter 1000000”了，这个重写过程本身也是有代价的，和RDB快照类似，AOF重写也是通过fork子进程来完成的，所以同样会遇到前面说的“写时复制”可能导致内存占用翻倍的问题，在重写期间，新的写命令还会同时被记录到旧的AOF文件和一个重写缓冲区里，等重写完成后再追加到新的AOF文件中，这也会带来一些额外的开销。

除了持久化文件这个大头,Redis本身存储数据的方式也会让实际占用的空间比你想的要大，Redis为了追求速度，在存储数据时并不是能省则省的“小气鬼”，它会给每个键值对分配一些额外的空间（ overhead），比如记录这个键值对的类型、过期时间、编码方式等等元信息，如果你的业务场景是存在海量的小键值对（比如用很多个key来存储用户的状态标记），那么这些额外的管理开销累积起来就会非常可观，这就好比是你往一个很大的箱子里只放了很多个小弹珠，弹珠本身没多少，但用来填充和保护弹珠的泡沫塑料却占了大半箱。

数据是从什么时候开始占用这么多地方的呢？它不是一个突然的事件，而是一个渐进的过程。

1. 随着AOF文件的不断增长：只要你一直在写入数据，AOF文件就会像滚雪球一样越来越大，直到下一次AOF重写发生。
2. 在触发RDB持久化或AOF重写的时刻：尤其是当你的数据集很大时，fork子进程的瞬间可能会导致内存使用量出现一个高峰，如果系统内存紧张，这个时刻就会非常危险。
3. 随着键值对数量的积累：特别是当存在数百万甚至更多的小键值对时，那些看不见的元数据开销会慢慢显现出来。

当你发现Redis的硬盘空间很大的时候,不能只盯着你存进去的那点数据看，更要检查一下AOF文件的大小、最近有没有发生重写、以及你的数据键的规模是否导致了过多的管理开销，解决方案也围绕着这些点：合理配置持久化策略（比如降低RDB快照的频率，或者调整AOF重写的触发条件）、定期检查并清理不再需要的键、以及优化数据模型，避免使用过多的小键值对。