Redis重启后数据没保存，持久化设置好像没生效，导致重启丢数据

我遇到了一个挺让人头疼的问题,就是Redis服务器重启之后，发现之前存在里面的数据都没了，好像重启了一次就清空了一样，我记得Redis不是有持久化功能可以把数据存到硬盘上吗？怎么感觉这个功能没起作用呢？后来我花了不少时间去查资料和看官方文档，才发现这里面有一些默认设置和不同的模式，如果没搞清楚，确实容易丢数据，我把了解到的情况说一下。

最直接的一个原因,可能就是我根本就没开启持久化，根据Redis官方文档的说明，为了追求最快的运行速度，Redis的默认配置是完全关闭持久化功能的，也就是说，如果你下载安装好Redis后，直接就去用了，没有修改任何配置文件，那么所有的数据都只存在于内存里，一旦服务器重启或者进程关闭，内存里的数据自然就全部清空了，重启之后就是一个全新的、空荡荡的数据库，这就像是你用电脑的记事本写了一篇很长的文章，但是没有点击“保存”，直接关了窗口，文章肯定就找不回来了，检查的第一步就是确认持久化功能是不是真的打开了。

即使我以为我打开了持久化,也可能因为配置不对而没生效，Redis主要有两种持久化方式，一种叫RDB，另一种叫AOF，RDB的方式就像是给数据拍一张快照，在某个时间点把完整的数据集保存到一个叫dump.rdb的文件里，这个“拍照”的动作是有条件的，根据默认配置，Redis可能会在比如900秒内至少有1个键被改变、或者300秒内至少有10个键被改变、或者60秒内至少有10000个键被改变时，才会触发一次快照保存，如果我写入数据后，还没来得及达到触发条件，或者数据变化的频率和数量没达到预设的标准，然后我就重启了服务器，那么从上一次快照到重启前的这段时间里新写入的数据，就会丢失，这就好比是学校拍毕业照，规定每隔一小时拍一张，但如果有个同学在拍照完后的第59分钟才赶到，很遗憾，他没能进入集体照，下一张照片要等一小时后才拍，这期间如果毕业典礼散了（服务器重启），这个同学就永远错过了这张照片。

另一种方式AOF,更像是写日记，会把每一个写操作命令都记录在一个文件里，重启的时候，Redis会重新执行一遍这个文件里的所有命令，从而恢复数据，这听起来比RDB的定时快照要安全，因为理论上每个操作都记录了，AOF也有它自己的问题，根据官方文档，AOF有一个配置项叫“appendfsync”，它控制着写命令同步到硬盘的频率，默认配置可能是每秒同步一次，这意味着最多可能会丢失一秒内的数据，虽然比RDB可能丢失几分钟数据要好，但也不是绝对的可靠，如果我把这个值设置为“no”，那么同步的时机就完全交给操作系统来决定了，丢失数据的风险会更大，还有一种情况是，AOF文件可能因为某些原因损坏了，比如磁盘满了或者突然断电，导致Redis在重启时无法正确读取AOF文件，数据恢复也会失败。

还有一个容易被忽略的点就是持久化文件的位置,Redis的RDB文件（dump.rdb）和AOF文件（appendonly.aof）默认会放在哪个目录下，这个在配置文件里是有设置的，如果我启动Redis的时候，没有使用我修改过的那个配置文件，或者配置文件里指定的目录没有正确的写入权限，那么Redis可能就无法成功创建这些持久化文件，它可能也不会报很明显的错误，程序照样运行，数据也能正常读写，但就是没有把数据真正写入硬盘，等到重启的时候，自然就找不到备份文件来恢复数据了。

还有一种比较特殊的情况是,我可能不小心手动删除了这些持久化文件，比如在服务器上进行一些清理工作的时候，没注意就把dump.rdb或者appendonly.aof文件给删掉了，那么即使之前持久化功能一直正常工作，因为唯一的备份文件被我删除了，重启后当然无数据可恢复。

总结下来,Redis重启后数据丢失，问题基本就出在持久化这个环节上，要么是根本没开启，要么是配置的策略不合适导致数据没来得及保存，要么是持久化文件本身出了什么问题（比如路径错误、权限不足或被误删），要解决这个问题，就得像侦探破案一样，一步一步去检查配置文件里的持久化设置是否启用、用的是哪种方式、触发条件是什么、文件路径在哪里、磁盘空间是否足够、文件是否真实存在且最新，这样才能找到数据丢失的真正原因。