Redis其实能让数据一直存着，不用担心丢失，永久保存真不是梦

“Redis其实能让数据一直存着，不用担心丢失，永久保存真不是梦”这个说法，其实来源于对Redis持久化机制的通俗理解，很多人刚开始用Redis，会听说它是一个内存数据库，所有数据都放在内存里，所以速度才那么快，但一想到内存的特性——一断电数据就全没了，心里就开始打鼓：这玩意儿靠谱吗？万一服务器重启或者宕机,我辛辛苦苦存进去的数据岂不是全丢了？

这时候，Redis的开发者们早就想到了这个问题，他们给Redis装上了“保险柜”功能，这就是持久化，持久化就是定期或者在特定条件下，把内存里的数据拷贝一份，存到硬盘上去，硬盘上的数据可是不怕断电的，这样就算Redis服务重启，也能从硬盘上把之前备份的数据重新加载到内存里，数据就找回来了，说Redis能让数据一直存着,核心指的就是它的持久化能力。

Redis是怎么做这个“备份”的呢？它主要有两种看家本领,你可以把它们想象成两种不同的备份策略。

第一种策略，叫做RDB，有人叫它“快照”（据Redis官方文档对RDB的描述），这个方法很直接，就像是给当前时刻的数据拍一张全景照片，Redis会在你设定的时间点，比如每隔一小时，或者每当有1000个键被修改了，就自动触发一次拍照，拍照的时候，它会创建一个子进程，这个子进程吭哧吭哧地把当前内存里所有数据完整地写到一个叫dump.rdb的压缩文件里，这个文件就是你的数据备份，这种方式的优点是，生成的RDB文件非常紧凑，就像把照片压缩成zip包一样，占用的硬盘空间小，用这个文件来恢复数据速度非常快，因为它是整个数据库的完整镜像，直接读进内存就行，但它的缺点也像拍照的缺点一样：不连续，你最后一次拍照到服务器宕机那一刻之间的所有数据变动，如果没来得及拍进下一张照片，那就真的丢失了，RDB适合那些对少量数据丢失不那么敏感的场景，比如用来做数据备份,或者需要快速重启恢复的情况。

第二种策略，叫做AOF，全称是“追加只写文件”（据Redis官方文档对AOF的描述），这个方法就不像拍照了，它更像是一个超级详细的日记本，Redis每执行一个能改变数据的命令（比如set一个键，del一个键），它都会把这个命令本身原原本本地记到这个日记本（也就是AOF文件）的末尾，这样一来，AOF文件里记录的不是某个时刻的数据状态，而是重现所有数据变化的“操作步骤”，当Redis需要重启恢复数据时，它不需要直接加载数据，而是像个听话的机器人，把AOF文件里的命令从头到尾重新执行一遍，这样内存里的数据就恢复到宕机前的样子了，这种方式的巨大优点是数据安全性非常高，你可以配置成每秒钟同步一次日记到硬盘，这样最多也就丢失一秒钟的数据，甚至可以配置成每次写命令都同步，这样几乎就是零数据丢失，但性能开销会比较大，AOF的缺点呢，就是日记本会越写越厚，AOF文件通常比RDB文件大得多，恢复数据的时候需要重新执行所有命令，如果日记很长,恢复过程就会比较慢。

看到这里你可能会想，这两种方式各有好坏，能不能结合起来用呢？答案是肯定的，而且这往往是生产环境下的最佳实践！Redis允许你同时开启RDB和AOF，这样，你可以用RDB快照来做定期的完整备份，它的文件小，恢复快，用AOF来记录两次快照之间的所有操作，保证即使最新的RDB备份是半小时前的，你也最多只丢失半小时的数据，而不是全部，当Redis重启时，它会优先使用AOF文件来恢复数据,因为AOF的数据完整性通常更高。

回到最开始的说法。“Redis其实能让数据一直存着，不用担心丢失，永久保存真不是梦”这句话，虽然不是百分之百的精确（因为理论上硬盘也可能损坏，需要做更进一步的异地备份），但确实道出了Redis通过RDB和AOF这两种强大的持久化机制，能够提供极高的数据可靠性，通过合理地配置这两种策略，你完全可以让Redis在享受内存高速读写的同时，满足业务对数据持久化的要求，让“数据永久保存”在绝大多数实际应用场景下,成为一个可以实现的梦。