Redis重启那会儿，它到底是怎么突然变得这么厉害的，命令也别忘了用起来

这事儿得从Redis的设计哲学说起，它之所以能在重启后“满血复活”，甚至感觉不到停顿，核心秘密就在于两个小家伙：RDB和AOF，你可以把它们想象成Redis记的两种不同风格的“日记”。（来源：Redis官方文档关于持久化的核心概念）

第一种日记：RDB（快照日记）

RDB就像是给Redis的内存数据拍一张全景快照，它会在一瞬间，把整个数据库的状态完整地保存到一个叫dump.rdb的文件里，这张照片拍的是某个时间点的静态画面，那什么时候会触发拍照呢？主要有两种情况：一是你手动下达命令，比如执行SAVE命令（但这个命令会阻塞所有请求，等拍完照才行，生产环境慎用）或者BGSAVE命令（这个就高级多了，是“后台保存”，Redis会fork一个子进程去默默拍照，父进程继续正常服务，不受影响）；二是你提前在配置文件里设置好规则，900秒内至少有1个键被改变”就自动触发一次BGSAVE。（来源：Redis配置文件中关于save选项的说明）

那RDB的好处是啥？就是快！恢复起来也快，因为恢复数据时，Redis只需要把这个完整的快照文件直接读回内存就行了，非常利索，但它的缺点也明显，就像拍照会错过镜头外的瞬间一样，如果Redis在两次快照之间突然宕机,那么从上一次拍照到宕机那一刻之间的所有数据更新就全丢了。

第二种日记：AOF（追加日志日记）

AOF的风格就完全不同了，它不拍静态照片，而是像个兢兢业业的书记官，把每一个会修改数据的写命令（比如SET, LPUSH, SADD等等）都原原本本地记录到一个日志文件（通常是appendonly.aof）的末尾，这样，AOF文件就变成了一份按时间顺序排列的“操作流水账”。（来源：Redis官方文档对AOF机制的描述）

当Redis重启的时候，它要做的就不是读取一个快照了，而是把这本厚厚的流水账从头到尾重新执行一遍，相当于把过去所有的操作重新做一遍，这样内存自然就恢复到了宕机前的状态，这种方式的好处是数据安全性极高，你甚至可以配置成让Redis每执行一个写命令就同步一次磁盘（appendfsync always），这样最多只会丢失一个命令的数据，几乎可以算是“准实时”的持久化了，但缺点也很突出：这本“流水账”会越来越长，导致恢复时间非常久；而且写操作频繁时,对磁盘IO的压力也更大。

Redis的聪明之处：混合双打

你看，RDB和AOF，一个像豪放派，一个像婉约派，各有优劣，那Redis是怎么变得“厉害”的呢？它最聪明的地方就在于，它不强迫你二选一，而是允许你同时开启这两种方式（在配置文件里设置appendonly yes和配置好RDB规则），并且还搞了个“混合持久化”的绝招。（来源：Redis 4.0版本开始引入的RDB-AOF混合持久化特性）

当开启了AOF持久化功能后，在进行AOF重写时（重写就是为了压缩AOF日志，把一些重复的、已过期的命令合并），Redis会先fork子进程，用类似RDB的方式将当前内存的数据快照写入一个新的AOF文件的开头部分，在重写过程中接收到的新写命令,会同时以AOF格式追加到这个新文件的后面。

这样，最终生成的新AOF文件就变成了一个“混血儿”：开头是一份二进制的RDB格式的全量数据快照，后面跟着的是AOF格式的增量命令日志，当Redis重启加载这个文件时，它会先快速加载开头的RDB快照，然后再重放后面一小段AOF日志，这样一来，既利用了RDB快速加载的优点，又保证了数据的完整性，重启效率得到了巨大的提升，这就好比你先用传送门把大部分人和物资瞬间运到目的地（RDB），再让一小部分后续部队步行跟上（AOF）,比所有人都步行快多了。

重启时用起来的命令

了解了原理,实际操作时你可能会用到这些命令：

1. 手动保存（谨慎使用）：

   • SAVE：同步保存，会阻塞所有客户端请求，直到RDB文件创建完毕,只在没有其他办法时再用。
   • BGSAVE：后台异步保存，Redis会返回Background saving started，然后你去干别的就行，可以用LASTSAVE命令查看最后一次成功保存RDB的时间戳。

2. 管理AOF：

   • BGREWRITEAOF：手动触发AOF文件重写，同样是在后台异步执行,用于压缩AOF文件大小。

3. 关机与重启：

   • SHUTDOWN [SAVE|NOSAVE]：最安全的关机命令，默认是SHUTDOWN SAVE，它会阻止新客户端连接，然后执行一次SAVE（如果RDB开启的话），保证数据落盘后再退出，如果你确定数据不重要，可以用SHUTDOWN NOSAVE，不做持久化直接退出,最快。
   • 重启的话，通常是在命令行用操作系统命令redis-server /path/to/redis.conf来启动Redis服务进程，只要你的RDB文件或AOF文件在配置的路径下,Redis启动时就会自动加载它们来恢复数据。

Redis重启后之所以能迅速“变得厉害”，不是因为它有什么魔法，而是因为它用了一种非常务实和聪明的组合策略，把两种持久化方式的优点结合了起来，既保证了数据安全，又最大限度地提升了重启恢复的速度，这一切，都依赖于你合理的配置和对这些“日记”机制的理解。