Redis持久化那点事儿，聊聊两种方式到底咋选和用

综合自Redis官方文档、多位技术社区博主如“程序员囧辉”、“小林coding”的解析文章，以及《Redis设计与实现》一书中的相关概念）

Redis这家伙，速度快是快，但它的数据都放在内存里，你想啊，万一服务器突然断电或者宕机了，内存里的数据不就全没了吗？那可就出大事了，Redis提供了两种主要的“持久化”方法，说白了就是想办法把内存里的数据给你存到硬盘上去，保证数据不会轻易丢失，这两种方法就是RDB和AOF，它俩思路完全不同,用起来感觉也不一样。

先说说RDB（快照方式）

RDB的方式特别像拍照，想象一下，在某个时间点，Redis给当前内存中完整的数据集“咔嚓”拍一张快照，然后把这个快照保存成一个压缩过的二进制文件，默认名字叫dump.rdb。

• 它是怎么工作的？ 主要有三种触发方式：

  

  1. 自动触发： 你可以在配置文件里设置规则，900秒内至少有1个键被改变”就拍一张，“300秒内至少有10个键被改变”再拍一张，达到条件了，Redis就会在后台fork一个子进程来专门负责写RDB文件,主进程继续处理命令。
  2. 手动触发： 在命令行里执行SAVE命令，但注意，这个命令会阻塞所有其他客户端请求，直到快照完成为止,生产环境基本不用。
  3. 手动触发（推荐）： 执行BGSAVE命令，这个命令就是上面说的“后台”拍照，主进程几乎不受影响,是常用的方式。

• RDB的优点：

  • 恢复速度快： 因为恢复时直接把这个紧凑的二进制文件读回内存就行了,非常适合做大规模数据的灾难恢复。
  • 文件紧凑，节省空间： RDB文件是压缩的二进制格式,比AOF文件小很多。
  • 适合备份： 你可以定时把某个时间点的RDB文件拷贝到别的地方，比如远程服务器或者云存储,非常简单。

• RDB的缺点：

  • 可能会丢数据： 这是最要命的一点，如果上次快照之后，还没到下一次快照的时间，服务器宕机了，那么这期间的所有数据更新就全丢了,所以数据安全性低。
  • 快照时可能有点卡： 虽然BGSAVE是后台操作，但fork子进程的瞬间，如果数据量特别大，可能会导致主进程短暂停顿（比如毫秒级），数据量越大,停顿可能越明显。

再聊聊AOF（日志方式）

AOF的思路就不是拍照了，而是“写日记”，它会把Redis执行过的每一个写命令（比如SET, LPUSH等）都记录到一个日志文件里（默认是appendonly.aof），当Redis重启时，就会把这个“日记”从头到尾重新执行一遍,从而还原出内存数据。

• 它是怎么工作的？

  • 实时记录： 客户端发来一个写命令，Redis先执行它,然后把这个命令按照协议格式追加到AOF文件的末尾。
  • 文件刷盘策略（这个很重要）： 命令追加到文件缓冲区后，什么时候真正写到硬盘上，有三种策略让你选（来源：Redis官方配置说明）：
    1. appendfsync always： 每个写命令都立刻刷到硬盘，最安全，基本不会丢数据（除非硬盘坏了），但速度也最慢,不推荐。
    2. appendfsync everysec： 默认推荐选项，每秒刷一次盘，就算宕机，最多丢1秒钟的数据,在安全性和性能之间取得了很好的平衡。
    3. appendfsync no： 让操作系统决定什么时候刷盘，性能最好,但丢数据的风险最大。

• AOF的优点：

  • 数据安全性高： 特别是用everysec策略，最多丢一秒数据,比RDB强多了。
  • 可读性强： AOF文件是纯文本格式，里面记录着所有操作命令，万一出问题了，你甚至可以用文本编辑器打开看看（虽然通常不需要手动改）。

• AOF的缺点：

  • 文件体积大： 日积月累，AOF文件会变得非常庞大，因为它记录的是所有操作，比如你对一个计数器INCR了100万次，AOF文件里就有100万条记录,而RDB里只有一个最终的键值对。
  • 恢复速度慢： 重新执行一遍所有命令来恢复数据,通常比加载RDB快照要慢。
  • 虽然文件大，但Redis提供了AOF重写机制（命令BGREWRITEAOF），这个机制会fork子进程，根据当前数据库状态，生成一个新的、更小的AOF文件（比如上面的计数器，重写后就直接记录最终值）,这个机制保证了AOF文件不会无限膨胀。

那到底该怎么选、怎么用呢？

（来源：业界常见实践和Redis官方建议）

这俩不是二选一，很多时候是配合着用,你可以根据你对数据安全性和性能的要求来决定。

1. 追求极致的数据安全，能容忍一点性能损失： 开启AOF，并使用appendfsync everysec（甚至always，如果硬盘够快），这样即使宕机，损失也很小,这是目前生产环境最常见的做法。

2. 数据没那么关键，追求更快的启动速度和备份效率： 可以只用RDB，并设置合理的快照频率（比如5分钟一次），适合用作缓存场景,数据丢了可以从源头数据库重新加载。

3. 最稳妥的“黄金搭档”方案（推荐）： 同时开启RDB和AOF。

   • 这样做的好处是，兼得了两者的优点，你用AOF来保证数据的安全性,确保平时不丢数据。
   • 定期生成的RDB文件是一个完美的“冷备份”，它文件小，恢复快，你可以在半夜流量低的时候用BGSAVE做个RDB快照，然后把这个dump.rdb文件备份到别处，万一哪天AOF文件被意外损坏了（比如磁盘坏道），你还可以用RDB文件恢复到某个时间点,损失会比完全没有备份小得多。

简单总结一下：

• RDB像拍照片，定期留档，恢复快，但可能丢数据,适合备份和快速重启。
• AOF像记日记，操作一笔笔都记下来，更安全，但文件大、恢复慢。

在实际应用中，理解它们各自的脾气秉性，根据你的业务场景灵活配置，甚至让它们俩一起为你工作，才是用好Redis持久化的关键，别把它们想得太复杂，就是给内存里的数据找个靠谱的、硬盘上的“家”。