Redis离开了记忆去哪儿了，数据到底藏哪儿还真让人琢磨不透

（根据微信公众号“差评”的文章《Redis离开了记忆去哪儿了，数据到底藏哪儿还真让人琢磨不透》整理）

咱们平时用手机APP，比如刷个短视频、买个东西，感觉都挺流畅的，这背后其实有个大功臣在默默干活，它就是Redis，你可以把它想象成一个超级快的“临时记事本”，服务器经常把一些需要快速读写的数据，比如用户的登录状态、购物车里的商品、热门文章的列表，都先放在这个“记事本”里，这样，下次你需要的时候，它就能“唰”地一下给你，不用再去翻箱倒柜地查那个速度慢很多的大数据库（比如MySQL）。

但问题来了，这个“记事本”有个特点，它主要是放在服务器的内存（RAM）里的，内存这东西，速度快是快，但有个致命伤：一旦服务器断电或者重启，里面记着的东西就全没了，这就好比你在电脑上打了一长段文字，没保存，突然停电了，字就全白打了，Redis难道不怕“停电”吗？它记下的那些重要数据，比如我刚加到购物车里的宝贝，会不会下一秒就消失不见呢？这数据到底藏哪儿了,还真让人有点琢磨不透。

Redis的设计者也想到了这个问题，他们给这个“健忘”的超级记事本准备了两种主要的“防忘秘籍”，或者说,两种把记忆存下来的方法。

第一种秘籍，叫做“拍快照”（RDB）。 （来源：文章中将此比喻为拍照）这个办法很直接，就是定期给Redis这个“记事本”里的所有内容拍一张完整的照片（也就是生成一个数据文件），然后把这张照片存到硬盘里，硬盘就像我们的U盘或电脑硬盘,断电了数据也不会丢。

这个过程有点像我们手机里的相册自动备份，你可以设置一个规则，比如每隔一小时拍一张照，或者当“记事本”里新写了1000条内容后就拍一张，这样做的好处是，最后留下来的是一张非常清晰的完整照片，文件也比较紧凑，万一服务器真的崩溃了，就可以用最近拍的那张照片,快速地把数据恢复到大差不差的状态。

但“拍快照”的缺点也很明显，你想啊，如果刚拍完照，服务器就出问题了，那么从拍照那一刻到出事之间的所有新记录，可就全丢了，这就像你旅游时每隔一小时才拍一张风景照,但可能错过了一群飞鸟掠过天空的精彩瞬间。

第二种秘籍，叫做“写日记”（AOF）。 （来源：文章中将此比喻为记日记）这个方法就更细致了，它不像拍照那样只记录结果，而是把Redis每一次“写”的操作命令（给用户A的购物车加入商品B”、“把文章C的点赞数加1”）都像写日记一样，原原本本地记下来,追加到一个日志文件的末尾。

这个“日记本”（AOF文件）也是存在硬盘上的，当服务器需要恢复数据时，它不需要看最后的照片什么样，而是把这篇“日记”从头到尾重新读一遍，按照上面记录的命令一条一条地重新执行，这样就能完美地还原出“记事本”最后的样子，这种方式的数据安全性非常高，理论上最多只会丢失最后一次“写日记”之后的一点点操作。

“写日记”的麻烦在于，这个日记本会变得越来越厚，因为所有的操作都记下来了，时间一长，文件会非常大，而且恢复数据的时候，要读完一本厚厚的日记，速度肯定比看一张照片慢得多，所以Redis也很聪明，它提供了一种“日记重写”机制，简单说就是定期把日记本里啰嗦、重复的内容整理一下，生成一个更精简的版本,但表达的意思还是一样的。

看到这儿你可能明白了，原来Redis的数据并不是永远只飘在内存里，它通过“拍快照”和“写日记”这两种方式，悄悄地把重要的记忆固化到了硬盘上，在实际生产中，为了平衡速度和数据安全，管理员往往会选择同时开启这两种方式,让它们互相配合。

这个存到硬盘上的“照片”（RDB文件）和“日记本”（AOF文件），具体放在哪里呢？（来源：文章中指出这是运维人员关心的实际问题）这其实完全取决于部署Redis服务器的人是怎么设置的，这个存储路径是Redis配置文件里的一个选项，有经验的运维人员通常会把它指定到一个容量足够大、并且读写速度比较快的硬盘分区上，甚至可能是更专业的SSD固态硬盘或者高性能的网络存储设备上，这个地方必须得稳定可靠，因为所有的数据备份都在这儿了,它可不能再出问题。

下次当你流畅地刷新页面、秒杀到商品时，可以想到，背后不仅有一个叫Redis的“闪电侠”在内存里飞速工作，还有一份沉甸甸的数据备份，正安安静静地躺在某个机房的硬盘里，守护着你的每一次操作，它并没有真正“离开记忆”，只是换了一种更持久的方式在“沉睡”，随时准备被唤醒，这种设计和安排，就是为了确保即使在最坏的情况下,我们的数字生活也能尽可能地少受影响。