Redis里那个RDB持久化方式，感觉挺轻量，也挺实用，就是那种简单快速保存数据的办法吧

Redis确实提供了两种主要的持久化方式,用来把内存中的数据保存到硬盘上，防止服务器断电或者崩溃时数据全部丢失，你提到的RDB就是其中一种，另一种叫做AOF，咱们现在就专门聊聊这个RDB，它确实像你感觉的那样，非常轻量和实用，可以理解成是给Redis的数据拍一张快照。

RDB到底是什么？简单来说就是“数据快照”

你可以把RDB想象成给Redis当前的状态拍一张全景照片,这张照片记录的是在某个时间点上，Redis数据库里所有的键值对数据，拍好之后，Redis会把这张“照片”保存成一个压缩过的二进制文件，默认的名字叫dump.rdb，这个文件非常紧凑，占用的磁盘空间比较小。

当Redis服务器需要重启的时候,它就会去找到这个dump.rdb文件，然后直接把里面的数据全部加载回内存，因为整个过程就是读取一个文件，把数据还原，所以恢复速度非常快，这对于需要快速重启服务的场景来说，是个巨大的优势。

RDB是怎么工作的？主要靠“触发时机”

RDB不是时时刻刻都在拍照的,那样太耗费资源了，它会在特定的“触发时机”才会执行快照操作，主要有以下几种方式：

1. 手动触发：这是最直接的方式，Redis提供了两个命令让你手动创建RDB快照：

   • SAVE命令：这个命令会阻塞Redis服务器，意思是，执行SAVE的时候，Redis会开始创建RDB文件，在这个过程中，它不能再处理任何其他的命令请求，所有客户端都得等着，直到快照完成，如果数据量很大，这个等待时间可能会很长，所以一般在生产环境中不太会用。
   • BGSAVE命令：这个命令是后台异步执行的，当你输入BGSAVE后，Redis会立刻给你返回一个响应，告诉你后台已经开始创建快照了，而它自己会fork出一个子进程（可以理解为复制了一个当前Redis进程的副本），由这个子进程去默默地创建RDB文件，而主进程继续正常地处理客户端的命令请求，完全不受影响，这是我们最常用、最推荐的手动方式。

2. 自动触发：这是生产环境中最主要的配置方式，你可以在Redis的配置文件redis.conf里进行设置，让Redis在满足一定条件时，自动在后台执行BGSAVE，配置的格式类似于：“在多少秒内，如果发生了多少次数据变更，就自动触发一次BGSAVE”。 举个例子，默认配置里可能有这么一行：save 900 1，它的意思是：在900秒（15分钟）之内，如果至少有1个键的值发生了变化，那就自动触发一次后台保存，你可以配置多个这样的条件，Redis会检查所有条件，只要满足其中一个就会触发，这种自动触发机制很好地平衡了数据安全性和性能，既保证了数据不会丢失太多，又不会频繁执行快照影响性能。

3. 特殊触发：还有一些特殊情况也会导致RDB快照的生成，比如执行SHUTDOWN命令关闭Redis服务器时，如果开启了RDB持久化，它会默认先执行一次快照再关闭，在主从复制架构中，当一个从节点刚连接上主节点时，主节点通常会发送一个RDB文件给从节点来完成数据的全量同步。

RDB的优点和缺点，就像硬币的两面

你感觉它轻量、实用，说得很对，它的优点非常突出：

• 恢复速度快：RDB是紧凑的二进制文件，加载回内存的速度极快，非常适合用于灾难恢复（比如服务器宕机后快速重启）和数据迁移。
• 对性能影响小：由于是定时快照，并且通常采用后台BGSAVE的方式，fork出子进程来工作，主进程服务基本不受影响，保证了Redis的高性能。
• 文件紧凑，节省磁盘空间：RDB文件是经过压缩的，相比于另一种AOF方式生成的日志文件，在同样数据量下，RDB文件通常小得多，方便你备份和传输。

它也有非常明显的缺点,这也是为什么Redis还要提供AOF方式的原因：

• 可能丢失较多数据：这是RDB最大的风险，因为它是定时快照，如果服务器在两次快照之间突然宕机，那么从上一次快照到宕机这个时间窗口内，所有写入的数据就全部丢失了，根据你的配置（比如save 900 1），可能会丢失几分钟甚至更长时间的数据，对于数据安全性要求极高的场景（比如金融交易），这是不可接受的。
• fork操作可能阻塞服务：虽然BGSAVE是后台执行，但fork这个创建子进程的动作本身，在数据量非常大的时候，可能会消耗较多CPU时间，并且如果内存占用巨大，fork过程可能会比较耗时，导致主进程短暂停顿，在极端情况下，可能会感觉到服务有卡顿。

总结一下

RDB持久化方式就像是一个简单粗暴的“定时拍照员”，它不那么啰嗦，不会记录每一个操作步骤（那是AOF干的事），而是定期把整个数据库的样子拍下来存档，这种做法带来的就是简单、快速、文件小的特点，非常适合做冷备份（定期备份用于存档）、快速恢复和数据迁移。

你也要清楚地知道它的代价：可能会丢失一段时间的数据，选择RDB还是AOF，或者两者结合使用，完全取决于你的业务需求，如果你的数据可以容忍几分钟的丢失，追求最高的性能和快速的恢复能力，那么RDB是一个非常棒的选择，如果你要求数据尽可能不丢失，哪怕服务器宕机也只能丢失一秒内的数据，那么你可能需要转向AOF或者混合持久化的方案了。