大家都知道Redis 之所以快到起飞是因为它把数据全都放在了内存里。但内存有个致命的弱点一断电或者服务器一重启里面的数据就瞬间灰飞烟灭了。如果你只是拿 Redis 当单纯的缓存丢了就丢了大不了重新去 MySQL 查一次。但如果你用 Redis 做分布式锁、做点赞计数、甚至把它当做主数据库来用数据全丢那是绝对要背锅跑路的。为了解决这个问题Redis 提供了“持久化机制”说白了就是想办法把内存里的数据偷偷抄一份保存到硬盘上。就算服务器宕机重启也能从硬盘把数据恢复回来。Redis 提供了三种持久化玩法RDB、AOF以及混合持久化。咱们抛开枯燥的源码用生活中最通俗的例子把它们扒个底朝天。第一招RDB 快照Redis DataBase—— “照相机模式”原理是什么RDB 就像是给 Redis 拍一张全景照片。你可以和 Redis 约定一个规则“如果 5 分钟内有 100 个数据发生了变化你就按一下快门。”时间一到Redis 就会把当前内存里的所有数据压缩成一个体积非常小巧的二进制文件通常叫 dump.rdb然后扔到硬盘上。等到服务器重启时Redis 直接把这张“照片”洗出来放到内存里数据就恢复了。优点恢复速度极快因为 RDB 存的是二进制的真实数据Redis 重启时直接全盘加载咔咔几下就恢复完毕了。文件体积小非常适合做定期备份比如你每天晚上生成一个 RDB 文件传到别的服务器上容灾。性能影响小Redis 在拍照时会派出一个“分身”fork 一个子进程去默默写硬盘主进程依然可以专心处理客户端的读写请求。致命缺点会丢数据假设你设置的是 5 分钟拍一次照。在第 4 分钟的时候服务器突然停电了那么这过去的 4 分钟里用户写入的新数据还没来得及拍照就永远丢失了。对于那些对数据完整性要求极高的金融或电商业务RDB 的这个缺点是无法接受的。第二招AOF 日志Append Only File—— “记账本模式”原理是什么既然 RDB 隔一段时间才拍一次照会丢数据那有没有办法一条都不丢有这就是 AOF。AOF 就像是一个流水记账本。Redis 每收到一个修改数据的命令比如 SET key value、DEL key就会把这句命令原封不动地写到一本账本.aof 文件里。等服务器宕机重启时Redis 就拿出这个账本把上面的命令从头到尾重新执行一遍数据自然就恢复原样了。为了平衡性能和安全AOF 提供了三种写盘策略Always每次打卡来一条命令写一次硬盘。绝对不丢数据但硬盘会被狂刷Redis 性能大打折扣。Everysec每秒打卡最常用把命令先暂存在缓冲区每隔 1 秒钟往硬盘写一次。就算宕机最多也就丢 1 秒钟的数据性能和安全平衡得非常好。No佛系打卡Redis 不管了全权交由操作系统决定什么时候写硬盘。很不安全极少使用。AOF 的致命缺点账本越来越厚恢复太慢假设你对同一个商品的价格修改了 100 次RDB 只会记录最后一次的最终价格而 AOF 会傻乎乎地把这 100 条修改命令全记录下来。时间一长AOF 文件会膨胀得非常巨大。如果有几十个 GRedis 重启时要把这么多命令重新跑一遍可能得花好几个小时业务早就凉透了。怎么填这个坑AOF 重写机制为了解决账本太厚的问题Redis 发明了AOF 重写Rewrite。它会在后台把账本“精简”一下。比如原来记录了增加 1 块钱、扣减 1 块钱、又增加 1 块钱。重写后直接变成一句结论当前余额 1 块钱。这样 AOF 文件就瞬间瘦身了。终极绝招混合持久化 —— “成年人全都要”到了这一步咱们来总结一下RDB恢复极快但容易丢最后一段时间的数据。AOF数据最全最多丢 1 秒但文件太大恢复极慢。有没有一种完美的方案既能像 RDB 那样秒恢复又能像 AOF 那样不丢数据在 Redis 4.0 版本之后官方推出了终极杀器混合持久化RDB AOF。这也成为了现在业界最主流的方案。它是怎么玩的简单来说混合持久化发生在AOF 重写的时候。当 Redis 准备瘦身账本时它不再单纯地精简命令了。而是先把当前内存里的全量数据以RDB 照片的形式写到 AOF 文件的开头。在拍照和写 RDB 的这段时间里如果有新的命令打进来就以AOF 账本的形式追加到文件的后半段。最终形成的持久化文件长这样前半段是乱码一样的 RDB 数据后半段是看得懂的 AOF 命令日志。为什么说它完美当 Redis 宕机重启时先快速加载前半段的 RDB瞬间恢复了 99% 的历史数据。再执行后半段极少量的 AOF 命令把宕机前那一小撮新数据补全。完美实现了重启快、数据全实战总结项目中到底该怎么选面试官经常会问“你在实际项目中是怎么配置的”记住以下这几个实战结论直接拿去套用如果你把 Redis 当纯缓存丢了无所谓全靠 MySQL 撑着那就大胆把 RDB 和 AOF 全关掉省下写硬盘的开销让 Redis 爆发出最极限的纯内存读写性能。如果你的系统比较老Redis 版本在 4.0 以下建议RDB 和 AOF 同时开启。重启时Redis 会优先使用 AOF 恢复数据因为数据更全同时 RDB 留着做每天的异地灾备。如果是现在的新项目且对数据安全性有要求强推毫不犹豫地打开AOF 混合持久化在配置文件中把 aof-use-rdb-preamble 设置为 yes。这就是目前工业界应对 Redis 数据持久化的最佳标准答案。
Redis持久化：RDB快照 vs AOF日志终极对决
大家都知道Redis 之所以快到起飞是因为它把数据全都放在了内存里。但内存有个致命的弱点一断电或者服务器一重启里面的数据就瞬间灰飞烟灭了。如果你只是拿 Redis 当单纯的缓存丢了就丢了大不了重新去 MySQL 查一次。但如果你用 Redis 做分布式锁、做点赞计数、甚至把它当做主数据库来用数据全丢那是绝对要背锅跑路的。为了解决这个问题Redis 提供了“持久化机制”说白了就是想办法把内存里的数据偷偷抄一份保存到硬盘上。就算服务器宕机重启也能从硬盘把数据恢复回来。Redis 提供了三种持久化玩法RDB、AOF以及混合持久化。咱们抛开枯燥的源码用生活中最通俗的例子把它们扒个底朝天。第一招RDB 快照Redis DataBase—— “照相机模式”原理是什么RDB 就像是给 Redis 拍一张全景照片。你可以和 Redis 约定一个规则“如果 5 分钟内有 100 个数据发生了变化你就按一下快门。”时间一到Redis 就会把当前内存里的所有数据压缩成一个体积非常小巧的二进制文件通常叫 dump.rdb然后扔到硬盘上。等到服务器重启时Redis 直接把这张“照片”洗出来放到内存里数据就恢复了。优点恢复速度极快因为 RDB 存的是二进制的真实数据Redis 重启时直接全盘加载咔咔几下就恢复完毕了。文件体积小非常适合做定期备份比如你每天晚上生成一个 RDB 文件传到别的服务器上容灾。性能影响小Redis 在拍照时会派出一个“分身”fork 一个子进程去默默写硬盘主进程依然可以专心处理客户端的读写请求。致命缺点会丢数据假设你设置的是 5 分钟拍一次照。在第 4 分钟的时候服务器突然停电了那么这过去的 4 分钟里用户写入的新数据还没来得及拍照就永远丢失了。对于那些对数据完整性要求极高的金融或电商业务RDB 的这个缺点是无法接受的。第二招AOF 日志Append Only File—— “记账本模式”原理是什么既然 RDB 隔一段时间才拍一次照会丢数据那有没有办法一条都不丢有这就是 AOF。AOF 就像是一个流水记账本。Redis 每收到一个修改数据的命令比如 SET key value、DEL key就会把这句命令原封不动地写到一本账本.aof 文件里。等服务器宕机重启时Redis 就拿出这个账本把上面的命令从头到尾重新执行一遍数据自然就恢复原样了。为了平衡性能和安全AOF 提供了三种写盘策略Always每次打卡来一条命令写一次硬盘。绝对不丢数据但硬盘会被狂刷Redis 性能大打折扣。Everysec每秒打卡最常用把命令先暂存在缓冲区每隔 1 秒钟往硬盘写一次。就算宕机最多也就丢 1 秒钟的数据性能和安全平衡得非常好。No佛系打卡Redis 不管了全权交由操作系统决定什么时候写硬盘。很不安全极少使用。AOF 的致命缺点账本越来越厚恢复太慢假设你对同一个商品的价格修改了 100 次RDB 只会记录最后一次的最终价格而 AOF 会傻乎乎地把这 100 条修改命令全记录下来。时间一长AOF 文件会膨胀得非常巨大。如果有几十个 GRedis 重启时要把这么多命令重新跑一遍可能得花好几个小时业务早就凉透了。怎么填这个坑AOF 重写机制为了解决账本太厚的问题Redis 发明了AOF 重写Rewrite。它会在后台把账本“精简”一下。比如原来记录了增加 1 块钱、扣减 1 块钱、又增加 1 块钱。重写后直接变成一句结论当前余额 1 块钱。这样 AOF 文件就瞬间瘦身了。终极绝招混合持久化 —— “成年人全都要”到了这一步咱们来总结一下RDB恢复极快但容易丢最后一段时间的数据。AOF数据最全最多丢 1 秒但文件太大恢复极慢。有没有一种完美的方案既能像 RDB 那样秒恢复又能像 AOF 那样不丢数据在 Redis 4.0 版本之后官方推出了终极杀器混合持久化RDB AOF。这也成为了现在业界最主流的方案。它是怎么玩的简单来说混合持久化发生在AOF 重写的时候。当 Redis 准备瘦身账本时它不再单纯地精简命令了。而是先把当前内存里的全量数据以RDB 照片的形式写到 AOF 文件的开头。在拍照和写 RDB 的这段时间里如果有新的命令打进来就以AOF 账本的形式追加到文件的后半段。最终形成的持久化文件长这样前半段是乱码一样的 RDB 数据后半段是看得懂的 AOF 命令日志。为什么说它完美当 Redis 宕机重启时先快速加载前半段的 RDB瞬间恢复了 99% 的历史数据。再执行后半段极少量的 AOF 命令把宕机前那一小撮新数据补全。完美实现了重启快、数据全实战总结项目中到底该怎么选面试官经常会问“你在实际项目中是怎么配置的”记住以下这几个实战结论直接拿去套用如果你把 Redis 当纯缓存丢了无所谓全靠 MySQL 撑着那就大胆把 RDB 和 AOF 全关掉省下写硬盘的开销让 Redis 爆发出最极限的纯内存读写性能。如果你的系统比较老Redis 版本在 4.0 以下建议RDB 和 AOF 同时开启。重启时Redis 会优先使用 AOF 恢复数据因为数据更全同时 RDB 留着做每天的异地灾备。如果是现在的新项目且对数据安全性有要求强推毫不犹豫地打开AOF 混合持久化在配置文件中把 aof-use-rdb-preamble 设置为 yes。这就是目前工业界应对 Redis 数据持久化的最佳标准答案。
