Redis持久化怎么搞才能数据不丢失，redis自带的那些功能其实挺关键的

Redis想要尽可能保证数据不丢失，核心就在于用好它自带的两种持久化机制：RDB和AOF，你不能只依赖其中一个，得把它们结合起来用，才能形成一个相对安全的防护网，下面我就详细说说这两样东西是怎么工作的,以及怎么搭配。

来说说RDB（快照）。

你可以把RDB想象成给Redis的数据拍一张全景照片，在某个时间点，Redis会把内存里所有的数据完整地备份到一个叫dump.rdb的文件里，这个文件是一个压缩过的二进制文件,非常紧凑。

那什么时候会触发拍照呢？主要有两种方式：

1. 自动触发：你在配置文件redis.conf里可以设置规则，900秒内至少有1个键被改动”就拍一张，或者“300秒内至少有10个键被改动”也拍一张,这就像你设置手机相册定期自动备份一样。
2. 手动触发：通过运行SAVE或BGSAVE命令。SAVE会阻塞所有请求，直到拍照完成，期间Redis不能干活，所以线上环境基本不用，而BGSAVE是关键，它会fork出一个子进程来负责拍照，主进程继续正常处理命令,这样服务就不会中断。

RDB的好处非常明显：

• 文件小：因为是紧凑的二进制文件，非常适合做灾难恢复，比如你数据量很大,用RDB恢复起来比AOF快得多。
• 对性能影响小：主要工作在子进程,避免了主进程的阻塞。

但RDB的致命缺点也正是“数据不丢失”的关键挑战：

• 会丢数据：既然是一次快照，那么从上一次拍照结束，到下一次拍照开始之前，这段时间内写入的所有数据，如果Redis突然宕机，就全部丢失了，你设置的自动触发条件间隔越长，可能丢失的数据就越多，比如你设置每5分钟拍一次，那最坏情况可能丢失5分钟的数据，对于某些业务来说,这是无法接受的。

正因为RDB有这个缺陷，所以Redis提供了另一个更强大的工具：AOF（追加日志）。

AOF的思路和RDB完全不同，它不拍全景照，而是像记日记一样，把每一个会修改数据的写命令（比如SET, LPUSH等）都记录下来，追加到一个文件的末尾，这个文件就是AOF文件，当Redis重启时，它会“回放”这个日记文件里的所有命令，一步一步地重新执行一遍,从而恢复数据。

AOF的工作机制有几个非常关键的步骤，这些步骤是保证数据可靠性的核心：

1. 命令追加：收到写命令后，先执行命令，然后把这个命令写到AOF缓冲区，这样就算宕机，命令还在内存缓冲区里，没写到磁盘,还是会丢。

2. 文件同步：这才是决定数据安全程度的关键，Redis允许你通过配置appendfsync来决定多久把缓冲区里的日记“真正”写到磁盘上，这里有三个档位,你需要认真选择：

   • no：Redis不主动刷盘，交给操作系统去决定，性能最好，但丢数据风险最大,操作系统可能隔几十秒才同步一次。
   • everysec：这是默认值，也是推荐值，每秒同步一次，这意味着即使宕机，最多也只丢失1秒钟的数据,在性能和安全性之间取得了很好的平衡。
   • always：每执行一个写命令，就立刻同步到磁盘，这样最安全，理论上最多只丢失一个命令的数据，但缺点是性能损耗非常大，因为写磁盘操作非常频繁和慢,会严重影响Redis的吞吐量。

3. AOF重写：因为AOF文件是追加日志，所以它会无限变大，而且里面可能有很多冗余命令，比如你对同一个键SET了10次，那么日记里就有10条记录，但只有最后一条是有效的，AOF重写就是为了解决这个问题，它会fork一个子进程，根据当前数据库的状态，逆向出一个新的、更小的AOF文件，这个文件包含的命令集合，能最精简地重建当前数据，重写期间，新的写命令会同时记录到旧的AOF缓冲区和重写缓冲区,确保数据一致。

   

到底怎么搞才能数据不丢失？答案就是：混合使用。

光用RDB，怕丢数据太多，光用AOF，恢复速度又比较慢，所以Redis从4.0版本开始，引入了AOF和RDB的混合持久化。

你可以在配置文件中开启aof-use-rdb-preamble yes，这个功能的作用是：当进行AOF重写时，子进程不再是生成一个新的纯AOF格式文件，而是先把当前数据的全量快照（也就是RDB格式的数据）写进新的AOF文件，然后再把重写缓冲区的增量写命令（AOF格式）追加到文件后面。

这样生成的新AOF文件，前半部分是RDB的二进制数据，后半部分是增量的AOF日志,它同时拥有了RDB的快照恢复速度和AOF的增量数据安全性。

要达到尽可能高的数据不丢失目标，你应该这样做：

1. 务必开启AOF持久化：在配置文件里设置appendonly yes,这是基础。
2. 设置AOF同步策略为everysec：这能在保证性能的同时，将数据丢失窗口缩短至1秒，如果你的业务对数据有极端要求，且能承受性能损失，可以考虑always。
3. 开启混合持久化：设置aof-use-rdb-preamble yes，这样既能享受AOF的安全,又能利用RDB快速恢复的优势。
4. 合理配置RDB快照：不要完全放弃RDB，可以设置一个比默认更频繁一点的RDB快照规则（例如每小时一次），作为AOF出问题时的备用恢复方案，定期把RDB文件备份到别的服务器上,做冷备。

Redis自带的RDB、AOF以及它们的混合模式，就是保证数据不丢失的最关键功能，你的任务不是去开发新的持久化工具，而是理解这些自带工具的原理，并根据自己业务的容忍度，做出正确的配置选择，没有一劳永逸的“绝对不丢失”，只有通过合理配置,将风险降到业务可接受的水平。