2026/9/11 9:31:17
FEATURED · 精选文章 
事发那天的经过我现在还记得很清楚。凌晨两点四十值班群一下子炸了告警一条接一条弹出来核心接口耗时从 30ms 涨到 8s慢查询缓存穿透率飙升到 70%数据库 CPU 直接 99%。最开始我只以为是流量异常直到看到 Redis 所在节点的 load average 冲到 40才意识到问题不在应用层而在持久化这一层——这是整个 Redis 集群的事故源头。那轮故障从发现到基本恢复花了将近 50 分钟影响了一批读多写少的核心接口。事后我拉着开发、DBA 一起翻配置、看监控、复盘时间线发现真正的导火索就是一条 AOF 刷盘策略配置。**appendfsync 被设成了 always配合高频写入和单机部署把 Redis 主线程活活卡死了。**而这个险情最终能稳住靠的也不是单点 Redis 的配置调优而是前面那套多级缓存扛住了瞬时流量。所以这轮复盘我想把整个链路拆开讲透从 AOF 刷盘策略到多级缓存一致性保障一次性把该踩的坑和该补的课都说清楚。这篇内容适合正在负责 Redis 运维、缓存架构设计或者在做高并发系统兜底方案的同学。不管是 Redis 持久化参数选型、AOF rewrite 触发问题还是本地缓存与 Redis 数据一致性更新策略我都会结合这次故障的实际排查过程讲清楚并提供可以直接落地的配置和代码参考。1. 故障复盘从“Redis 抖动”到“缓存雪崩”的完整链路1.1 故障时间线与表象分析先还原一下当时的时间线。02:38监控发现 Redis 节点 CPU 飙升至 380%load average 持续走高。02:41多个核心接口 P99 延迟从 30ms 涨至 3s 以上。02:43数据库连接数被打满MySQL CPU 超过 90%慢查询量暴涨。02:45确认 Redis 读写超时开始有大量异常上报。02:50临时将 Redis 持久化策略从 always 改为 everysec并重启主节点。03:28接口延迟回落至 200ms 以内数据库负载逐步恢复。表象上看是 Redis 变慢了但为什么一个持久化参数能把整个集群拖垮原因在于 Redis 是单线程模型所有命令都在主线程中串行执行。如果某个操作在主线程中耗时过长所有客户端请求都会被阻塞。appendfsync always的含义是每个写命令执行后都调用 fsync 强制将 AOF 缓冲区数据刷入磁盘。这个 fsync 操作是同步的且磁盘 IO 的延迟远高于内存操作。高并发写入场景下每次写请求都要等磁盘落盘完成才返回主线程等于被磁盘 IO 拖住了。这里就涉及 Redis 持久化的两个关键机制AOF 追加写与 fsync 刷盘。1.2 从单点阻塞到雪崩的传导路径单点 Redis 变慢之后缓存雪崩的传导路径是Redis 请求阻塞 - 超时重试 - 流量穿透到数据库 - 数据库连接耗尽 - 应用线程阻塞 - 级联故障。很多团队的缓存架构是应用 - Redis - MySQL。正常情况下大部分读请求命中了 Redis 缓存数据库压力很小。可一旦 Redis 不可用或响应慢所有请求都会绕过缓存直达数据库。如果没有兜底和降级策略数据库崩溃是早晚的事。这次故障之所以没有彻底打垮整个系统幸亏当时做了两级缓存兜底本地进程缓存Caffeine Redis 外部缓存。Redis 抖动时本地缓存还在拦截了一部分热点请求。但这里又暴露了另一个问题——本地缓存与 Redis 缓存之间的一致性维护这正是后面要重点讲的多级缓存一致性保障。这里先做一个临时结论Redis 持久化配置不当引发的不是“数据丢失风险”而是“瞬时阻塞风险”。两者的差异决定了你的排查方向完全不同。2. Redis 持久化机制深挖RDB 与 AOF 的选型与配置误区2.1 RDB 与 AOF 各自的设计意图和适用场景Redis 持久化有两个核心机制RDBRedis DataBase定时生成内存快照保存的是某个时间点的全量数据。优点是恢复速度快文件紧凑缺点是可能在两次快照之间丢失数据。AOFAppend Only File以日志追加的方式记录每个写操作重启时通过回放日志恢复数据。优点是数据更安全缺点是文件体积增长快恢复速度慢。这两种机制不是互斥的生产环境通常搭配使用。RDB 负责快速恢复全量数据AOF 负责补齐两次 RDB 之间的增量数据。这里有一个经常被忽略的点Redis 重启后加载数据的优先级。**如果同时开启了 RDB 和 AOFRedis 会优先加载 AOF 文件而不是 RDB。**原因是 AOF 文件中的数据通常比 RDB 更新。如果你配置了混合持久化aof-use-rdb-preamble yesAOF 文件头部会包含 RDB 格式的全量数据后续追加增量命令兼顾了恢复速度和数据安全。2.2 三种 appendfsync 刷盘策略的深度对比AOF 刷盘策略由appendfsync参数控制共有三个可选值配置值行为优点缺点适用场景always每个写命令执行后同步 fsync数据最安全最多丢失一个命令吞吐量暴跌主线程阻塞风险高几乎不用除非对数据安全要求极高且写入量极低everysec每秒异步 fsync 一次性能与安全性平衡最多丢 1 秒数据极端情况下可能丢 1 秒数据生产环境默认推荐no由操作系统决定何时刷盘性能最好丢失数据窗口不可控可以接受较大数据丢失的场景这次故障的配置就是always。正常情况下Redis 写命令处理速度是微秒级但磁盘 fsync 延迟通常在毫秒到几十毫秒之间机械盘甚至更高。也就是说一个写请求的耗时一下子从微秒级变成毫秒级Redis 主线程的全部吞吐都被拖垮。有些同学会问everysec也会每秒做一次 fsync会不会也造成阻塞答案是不会。everysec是后台异步执行 fsync主线程不会被阻塞但如果磁盘 IO 本身已经饱和fsync 排队也可能会影响性能。所以生产环境不能只看参数还要监控磁盘 IO 延迟和 Redis 的aof_pending_bio_fsync指标。2.3 AOF rewrite 机制的隐性风险除了刷盘策略AOF 还有一个隐藏的坑AOF 文件重写rewrite引发的阻塞。AOF 文件会随着写入不断增长为了控制体积Redis 会在满足条件时触发 rewrite将当前数据集生成最小化的写命令集合。rewrite 由 fork 子进程执行主进程继续接受读写请求。但 fork 过程本身是耗时的尤其在内存占用大的实例上。fork 期间主进程需要复制页表内存越大耗时越长。如果 rewrite 期间写请求量很大AOF 缓冲区中需要同步给子进程的数据也会增多Redis 会阻塞等待缓冲区清理造成延迟毛刺。实际遇到的案例一个 16GB 内存的 Redis 实例fork 花了将近 2 秒。触发 rewrite 时正好赶上业务高峰线上出现了一波 1~2 秒的 Redis 超时。排查了很久才发现是 rewrite 引发的抖动脉冲。生产中建议关注这几个参数auto-aof-rewrite-percentage默认 100表示 AOF 文件比上次 rewrite 时增长超过 100% 才触发 rewrite。auto-aof-rewrite-min-size默认 64mb文件小于这个值不触发 rewrite。aof-timestamp-enabled开启后可以查看 AOF 文件的写入时间。实测下来建议将auto-aof-rewrite-percentage调整到 200 或更高降低 rewrite 触发频率。如果实例内存大注意监控 fork 耗时指标latest_fork_usec。3. 从故障中拆解持久化参数到底应该怎么配置3.1 生产环境推荐的持久化参数组合这次故障后我们重新梳理了生产环境的持久化配置。下面这套组合在多个项目中经过验证兼顾了性能和数据安全appendonly yes appendfilename appendonly.aof appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 200 auto-aof-rewrite-min-size 512mb aof-load-truncated yes aof-use-rdb-preamble yes save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes几个关键参数的说明appendfsync everysec主线程完全不阻塞最多丢 1 秒数据。大部分业务场景都能接受。no-appendfsync-on-rewrite yesrewrite 期间不执行 fsync避免 rewrite 和 fsync 同时抢占磁盘 IO。aof-use-rdb-preamble yes开启混合持久化AOF 文件头部是 RDB 格式恢复速度快。stop-writes-on-bgsave-error yesRDB 快照失败时停止写入防止数据丢失扩大化。3.2 什么时候才应该使用 always虽然always在某些场景下看起来更安全但实际业务中能用到的场景非常少。以我们这次故障为例业务方最初配置always是因为“担心丢失数据”。但 Redis 在这套体系里是缓存层还是数据存储层决定了持久化策略的选择。如果 Redis 只做缓存数据可以从数据库回源完全没必要开启 AOF如果 Redis 承载了部分不能丢失的计数、Token 等数据那么需要评估的是数据丢失容忍度而不是简单粗暴设置为 always。always真正适用的场景是写入量极低比如每秒几个写请求且单条数据不能丢失的强一致场景。正常每秒几千甚至几万写入的业务设置always就是在自杀。而且要想真正避免“丢失 1 秒数据”光靠 Redis 持久化是不够的。Redis 的everysec并不能完全保证数据安全崩溃时 AOF 文件末尾可能有不完整的命令。这时需要配合其他机制写操作同步双写一份到消息队列由消费者异步落库。关键业务数据直接写 MySQLRedis 只做加速。启用 Redis 主从复制主节点故障时从节点接管AOF 只是兜底。3.3 Redis 7.0 的新特性AOF 多文件机制在 Redis 7.0 中AOF 机制发生了重大变化原来的单文件 AOF 被拆分为多个文件包括 base 文件、incr 文件和 manifest 清单文件。整体思路是将全量 RDB 数据和增量命令分开存储配合 rewrite 时不再生成完整的新 AOF 文件而是通过 manifest 管理文件集合。这个升级对运维和恢复流程影响很大。恢复时不再像以前那样简单加载一个 appendonly.aof而是读取 manifest 文件确认文件集合。升级到 Redis 7.0 后要特别检查备份脚本是否适配了新的 AOF 文件格式我见过有团队的备份脚本还在拷贝旧的单文件路径结果备份一直失败数据恢复时才发现根本没有可用的 AOF 文件。4. 故障背后的真正问题缓存一致性如何保障4.1 缓存雪崩与缓存穿透的差别这次故障中Redis 不可用直接触发了缓存雪崩但外面很多人会把雪崩和穿透混为一谈。缓存穿透请求查询的数据在缓存和数据库中都不存在每次请求都直达数据库数据库压力巨大。缓存雪崩大量缓存同时失效或者缓存整体不可用所有请求同时打到数据库。缓存击穿某个热点 key 失效的瞬间大量并发请求绕过缓存直达数据库。这次故障就是典型的缓存雪崩Redis 整体不可用所有读请求全部落到数据库。要有效预防这三类问题光靠 Redis 本身的配置调优还不够必须在架构层面做兜底。多级缓存就是最有效的手段之一。4.2 多级缓存的经典架构本地缓存 Redis 数据库多级缓存的标准布局是一级缓存本地缓存部署在应用进程内如 Caffeine、Guava Cache。访问速度最快纳秒级响应但容量有限且多实例各自独立。二级缓存分布式缓存Redis跨进程共享毫秒级响应容量较大。三级存储数据库最终一致性数据源。读请求处理顺序本地缓存 - Redis - 数据库。找到即返回并逐级回填。这套架构能扛住 Redis 故障的核心原因在于**本地缓存其实挡掉了大部分热点请求。**Redis 不可用时Caffeine 仍然能在应用内返回数据虽然命中率不如 Redis 高但足以让数据库扛住瞬时压力。实测时我们通过本地缓存拦截了大约 30% 的读流量数据库压力从 99% 降到了 60% 左右。接着手动切换 Redis 持久化策略后Redis 恢复系统才彻底稳定。4.3 本地缓存与 Redis 的一致性更新策略多级缓存最大的难点不是读而是写。当数据更新时如何保证本地缓存、Redis、数据库三者之间的数据一致性。先说不推荐的方案先更新数据库再删除缓存。这个方案在单机缓存场景下没问题但在多级缓存场景下有个坑本地缓存没有失效机制时其他实例的本地缓存不会感知数据更新继续返回旧数据。标准做法是“订阅变更 - 主动失效本地缓存 - 更新数据库 - 删除 Redis 缓存”业务操作中先更新数据库。发送一个缓存失效消息到消息队列或 Redis Pub/Sub、Canal Binlog 监听。所有应用实例收到消息后删除本地缓存中对应 key。同时删除 Redis 中的对应 key。后续读请求发现缓存未命中回源数据库并重新回填各级缓存。这个方案能保证最终一致性。短期内的数据不一致窗口取决于消息处理延迟通常可以控制在几百毫秒以内。还有一种更轻量的做法本地缓存设置极短的过期时间如 30 秒配合主动失效机制兜底保证数据不会长时间不一致。这种做法实现简单但存在一个问题如果主动失效消息丢失数据不一致窗口会被拉长到过期时间。所以两者需要配合使用。4.4 缓存更新策略选型Cache Aside 与延迟双删多级缓存场景下更新策略的选型很重要。我这里直接给出经验结论Cache Aside旁路缓存读请求未命中则回源数据库并回填缓存写请求先更新数据库再删除缓存。这是最通用的方案适合读多写少场景。延迟双删先删缓存再更新数据库延迟后再次删缓存主要解决“先更新数据库再删缓存”的并发竞态问题。但实现复杂且延迟时间不好把握我建议只在与第三方系统对接、无法使用消息队列时才考虑。Write Through / Write Back直写/回写缓存层直接承担写入责任对 Redis 的依赖度高适合把 Redis 当作存储的场景但在缓存架构中不常用。从实际维护角度看我推荐Cache Aside 数据库 Binlog 监听 消息队列失效缓存的组合。这套方案可解释性强、链路清晰、不易出幺蛾子。5. 恢复演练与“Redis 可用性”的进一步治理5.1 故障恢复的标准动作与顺序Redis 故障后的恢复顺序很多人第一步就做错了。比如这次故障中有人第一时间提议直接重启 Redis重启后 AOF 日志会全部回放如果 AOF 文件很大回放会导致长时间不可用。正确顺序应该是先限流瞬间将不重要的非核心流量拒绝掉保护后端数据库。不要指望 Redis 快速恢复先保住系统不崩溃。降级把回源数据库的读请求切换为查备库或本地缓存兜底。查因确认 Redis 阻塞原因进程还在就通过redis-cli info persistence和redis-cli info stats检查持久化相关指标确认是不是 fsync 或 rewrite 阻塞。调整配置临时修改appendfsync为everysec必要时使用CONFIG SET热加载。观察恢复等待 Redis 延迟指标回归正常后逐步放开限流。根本治理恢复之后并不代表结束。要复盘配置、完善监控报警制定持久化配置规范评估架构层面是否引入多级缓存、主从高可用。这套顺序的关键在于“先保护数据库再恢复 Redis”。如果顺序反了Redis 一恢复就放开全部流量数据库可能直接被击穿。5.2 Redis 高可用部署的核心手段这次故障中单点 Redis 是放大器。如果当时有主从切换机制Redis 主节点卡死后哨兵会自动把从节点提升为主节点业务影响时间能从 50 分钟缩短到 10 秒以内。部署建议至少一主一从从节点不仅用于高可用还可以承载读流量。如果只需要部分场景强一致主从模式下可开启读写分离但要注意主从复制延迟问题。哨兵模式Sentinel是生产环境的最低要求。三个哨兵节点互相通信自动完成故障检测和故障转移。Redis Cluster 适合数据量超过单机内存、需要水平扩展的场景。但 Cluster 运维复杂度更高数据分片、槽位迁移都有一套独立的运维逻辑。5.3 全链路缓存治理从 Redis 到多级缓存的一致性保障通过这次故障我们最终的治理方案可以归纳为“持久化配置规范 多级缓存兜底 高可用切换 全链路监控”四位一体。在 Redis 侧明确 appendfsync 统一为 everysec。开启混合持久化aof-use-rdb-preamble yes。监控持久化阻塞指标aof_delayed_fsync、aof_pending_bio_fsync、latest_fork_usec。当有多实例时统一配置管理平台避免人工登录修改配置。在多级缓存侧本地缓存 Caffeine Redis MySQL 三级架构。数据更新走“先 DB 后失效缓存”的最终一致性链路。本地缓存失效订阅通过 Redis Pub/Sub 或 MQ 广播。定期压测多级缓存的容灾能力模拟 Redis 实例宕机确保本地缓存和数据库能扛住 5 分钟以上的瞬时流量。6. 常见问题与排查技巧实录6.1 Redis 延迟毛刺如何定位是持久化问题Redis 主线程阻塞最容易被忽略的就是持久化相关的指标。遇到延迟毛刺按以下顺序排查redis-cli --latency -h host -p port确认延迟情况。redis-cli -h host -p port info persistence查看aof_last_write_status、aof_delayed_fsync、rdb_last_bgsave_status。redis-cli -h host -p port info stats查看latest_fork_usec如果超过 1 秒就要关注 fork 耗时。查看系统层面的磁盘 IOiostat -x 1关注%util和await指标。结合慢日志SLOWLOG GET 20看是否有BIO_AOF_FSYNC等内部操作或异常命令。注意Redis 的慢日志不一定只记录命令Redis 7.0 中部分后台操作也会记录到慢日志中看到BIO相关条目时不要忽略。6.2everysec也可能丢数据如何处理 AOF 文件截断everysec模式下Redis 每秒执行一次 fsync如果机器突然断电或崩溃最后一秒写入的数据可能丢失。即使不崩溃AOF 文件末尾也可能存在不完整记录。Redis 针对 AOF 文件截断的情况有一个参数aof-load-truncated。默认值为 yes表示加载 AOF 时如果发现文件被截断会忽略尾部的残缺部分正常加载。生产环境建议保留默认配置不要改成 no。如果改成 noRedis 会拒绝启动还要手动修复 AOF 文件运维成本很高。排查 AOF 文件问题可以用这个命令redis-check-aof --fix appendonly.aof但注意这个命令会删除损坏部分的数据。在操作之前先备份原始文件。6.3 Redis 主从复制与 AOF 的联动关系主从环境下主节点的持久化配置会影响复制性能。主节点开启 AOF从节点同步数据的来源是主节点的 RDB 快照和复制缓冲区从节点自身的持久化配置不影响同步但会影响从节点的重启恢复能力。如果主节点关闭了持久化而哨兵自动把从节点提升为主节点此时新的主节点可能没有任何 AOF/RDB 数据一旦重启数据全部丢失。所以高可用环境下主从节点都要开启持久化不能为了省 IO 只让主节点开持久化。6.4 多级缓存构建中的典型问题速查问题原因解决方案本地缓存命中率低缓存过期时间过短设置不同 key 的差异化过期时间热点 key 时间更长本地缓存数据不一致主动失效消息延迟或丢失缩短兜底过期时间使用消息队列保证投递可靠性Redis 抖动导致数据库被打挂缺少本地缓存兜底或者本地缓存容量不够增加 Caffeine 容量按热点 key 设置随意淘汰策略缓存穿透导致数据库压力大查询的数据不存在缓存层从未生效布隆过滤器或者缓存空值短过期缓存击穿导致热点 key 失效key 过期瞬间被大量访问热点 key 不设置过期时间后台定期刷新或者使用互斥锁回源7. 日常运维中非常值得做的小改进这套方案跑了一段时间后我整理了三个落地后收益最大的改进分享给大家。第一个是给 Redis 的关键指标建立独立监控面板。不要等告警才看指标。平时就要周期性关注aof_delayed_fsync、rdb_bgsave_in_progress、latest_fork_usec这几个值。延迟毛刺通常在这些指标上会提前很多天暴露出来。第二个是定期做故障演练。每个月模拟一次 Redis 宕机验证多级缓存兜底能力检查本地缓存的命中率是否足够数据库连接池是否够用。演练中发现的问题通常比线上故障更值得修复因为代价小。第三个是配置变更全平台化。所有 Redis 配置统一走配置中心不能让人 SSH 到机器上手工改配置。手工改配置意味着没有审计、没有回滚、没有告警这次故障的根源就是某个同学直接在服务器上改了配置没有走流程。最后再分享一个小技巧排查缓存类故障时不要只盯着 Redis 看要从全链路视角看。从应用进程 - 本地缓存 - 网络 - Redis - 数据库逐层排查才能找到真正的瓶颈。很多时候你以为是 Redis 出了问题真相却是数据库慢查询拖垮了缓存回填线程导致缓存全部过期。这种障眼法我在线上见过太多次了。
Redis AOF配置陷阱与多级缓存一致性实战复盘
事发那天的经过我现在还记得很清楚。凌晨两点四十值班群一下子炸了告警一条接一条弹出来核心接口耗时从 30ms 涨到 8s慢查询缓存穿透率飙升到 70%数据库 CPU 直接 99%。最开始我只以为是流量异常直到看到 Redis 所在节点的 load average 冲到 40才意识到问题不在应用层而在持久化这一层——这是整个 Redis 集群的事故源头。那轮故障从发现到基本恢复花了将近 50 分钟影响了一批读多写少的核心接口。事后我拉着开发、DBA 一起翻配置、看监控、复盘时间线发现真正的导火索就是一条 AOF 刷盘策略配置。**appendfsync 被设成了 always配合高频写入和单机部署把 Redis 主线程活活卡死了。**而这个险情最终能稳住靠的也不是单点 Redis 的配置调优而是前面那套多级缓存扛住了瞬时流量。所以这轮复盘我想把整个链路拆开讲透从 AOF 刷盘策略到多级缓存一致性保障一次性把该踩的坑和该补的课都说清楚。这篇内容适合正在负责 Redis 运维、缓存架构设计或者在做高并发系统兜底方案的同学。不管是 Redis 持久化参数选型、AOF rewrite 触发问题还是本地缓存与 Redis 数据一致性更新策略我都会结合这次故障的实际排查过程讲清楚并提供可以直接落地的配置和代码参考。1. 故障复盘从“Redis 抖动”到“缓存雪崩”的完整链路1.1 故障时间线与表象分析先还原一下当时的时间线。02:38监控发现 Redis 节点 CPU 飙升至 380%load average 持续走高。02:41多个核心接口 P99 延迟从 30ms 涨至 3s 以上。02:43数据库连接数被打满MySQL CPU 超过 90%慢查询量暴涨。02:45确认 Redis 读写超时开始有大量异常上报。02:50临时将 Redis 持久化策略从 always 改为 everysec并重启主节点。03:28接口延迟回落至 200ms 以内数据库负载逐步恢复。表象上看是 Redis 变慢了但为什么一个持久化参数能把整个集群拖垮原因在于 Redis 是单线程模型所有命令都在主线程中串行执行。如果某个操作在主线程中耗时过长所有客户端请求都会被阻塞。appendfsync always的含义是每个写命令执行后都调用 fsync 强制将 AOF 缓冲区数据刷入磁盘。这个 fsync 操作是同步的且磁盘 IO 的延迟远高于内存操作。高并发写入场景下每次写请求都要等磁盘落盘完成才返回主线程等于被磁盘 IO 拖住了。这里就涉及 Redis 持久化的两个关键机制AOF 追加写与 fsync 刷盘。1.2 从单点阻塞到雪崩的传导路径单点 Redis 变慢之后缓存雪崩的传导路径是Redis 请求阻塞 - 超时重试 - 流量穿透到数据库 - 数据库连接耗尽 - 应用线程阻塞 - 级联故障。很多团队的缓存架构是应用 - Redis - MySQL。正常情况下大部分读请求命中了 Redis 缓存数据库压力很小。可一旦 Redis 不可用或响应慢所有请求都会绕过缓存直达数据库。如果没有兜底和降级策略数据库崩溃是早晚的事。这次故障之所以没有彻底打垮整个系统幸亏当时做了两级缓存兜底本地进程缓存Caffeine Redis 外部缓存。Redis 抖动时本地缓存还在拦截了一部分热点请求。但这里又暴露了另一个问题——本地缓存与 Redis 缓存之间的一致性维护这正是后面要重点讲的多级缓存一致性保障。这里先做一个临时结论Redis 持久化配置不当引发的不是“数据丢失风险”而是“瞬时阻塞风险”。两者的差异决定了你的排查方向完全不同。2. Redis 持久化机制深挖RDB 与 AOF 的选型与配置误区2.1 RDB 与 AOF 各自的设计意图和适用场景Redis 持久化有两个核心机制RDBRedis DataBase定时生成内存快照保存的是某个时间点的全量数据。优点是恢复速度快文件紧凑缺点是可能在两次快照之间丢失数据。AOFAppend Only File以日志追加的方式记录每个写操作重启时通过回放日志恢复数据。优点是数据更安全缺点是文件体积增长快恢复速度慢。这两种机制不是互斥的生产环境通常搭配使用。RDB 负责快速恢复全量数据AOF 负责补齐两次 RDB 之间的增量数据。这里有一个经常被忽略的点Redis 重启后加载数据的优先级。**如果同时开启了 RDB 和 AOFRedis 会优先加载 AOF 文件而不是 RDB。**原因是 AOF 文件中的数据通常比 RDB 更新。如果你配置了混合持久化aof-use-rdb-preamble yesAOF 文件头部会包含 RDB 格式的全量数据后续追加增量命令兼顾了恢复速度和数据安全。2.2 三种 appendfsync 刷盘策略的深度对比AOF 刷盘策略由appendfsync参数控制共有三个可选值配置值行为优点缺点适用场景always每个写命令执行后同步 fsync数据最安全最多丢失一个命令吞吐量暴跌主线程阻塞风险高几乎不用除非对数据安全要求极高且写入量极低everysec每秒异步 fsync 一次性能与安全性平衡最多丢 1 秒数据极端情况下可能丢 1 秒数据生产环境默认推荐no由操作系统决定何时刷盘性能最好丢失数据窗口不可控可以接受较大数据丢失的场景这次故障的配置就是always。正常情况下Redis 写命令处理速度是微秒级但磁盘 fsync 延迟通常在毫秒到几十毫秒之间机械盘甚至更高。也就是说一个写请求的耗时一下子从微秒级变成毫秒级Redis 主线程的全部吞吐都被拖垮。有些同学会问everysec也会每秒做一次 fsync会不会也造成阻塞答案是不会。everysec是后台异步执行 fsync主线程不会被阻塞但如果磁盘 IO 本身已经饱和fsync 排队也可能会影响性能。所以生产环境不能只看参数还要监控磁盘 IO 延迟和 Redis 的aof_pending_bio_fsync指标。2.3 AOF rewrite 机制的隐性风险除了刷盘策略AOF 还有一个隐藏的坑AOF 文件重写rewrite引发的阻塞。AOF 文件会随着写入不断增长为了控制体积Redis 会在满足条件时触发 rewrite将当前数据集生成最小化的写命令集合。rewrite 由 fork 子进程执行主进程继续接受读写请求。但 fork 过程本身是耗时的尤其在内存占用大的实例上。fork 期间主进程需要复制页表内存越大耗时越长。如果 rewrite 期间写请求量很大AOF 缓冲区中需要同步给子进程的数据也会增多Redis 会阻塞等待缓冲区清理造成延迟毛刺。实际遇到的案例一个 16GB 内存的 Redis 实例fork 花了将近 2 秒。触发 rewrite 时正好赶上业务高峰线上出现了一波 1~2 秒的 Redis 超时。排查了很久才发现是 rewrite 引发的抖动脉冲。生产中建议关注这几个参数auto-aof-rewrite-percentage默认 100表示 AOF 文件比上次 rewrite 时增长超过 100% 才触发 rewrite。auto-aof-rewrite-min-size默认 64mb文件小于这个值不触发 rewrite。aof-timestamp-enabled开启后可以查看 AOF 文件的写入时间。实测下来建议将auto-aof-rewrite-percentage调整到 200 或更高降低 rewrite 触发频率。如果实例内存大注意监控 fork 耗时指标latest_fork_usec。3. 从故障中拆解持久化参数到底应该怎么配置3.1 生产环境推荐的持久化参数组合这次故障后我们重新梳理了生产环境的持久化配置。下面这套组合在多个项目中经过验证兼顾了性能和数据安全appendonly yes appendfilename appendonly.aof appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 200 auto-aof-rewrite-min-size 512mb aof-load-truncated yes aof-use-rdb-preamble yes save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes几个关键参数的说明appendfsync everysec主线程完全不阻塞最多丢 1 秒数据。大部分业务场景都能接受。no-appendfsync-on-rewrite yesrewrite 期间不执行 fsync避免 rewrite 和 fsync 同时抢占磁盘 IO。aof-use-rdb-preamble yes开启混合持久化AOF 文件头部是 RDB 格式恢复速度快。stop-writes-on-bgsave-error yesRDB 快照失败时停止写入防止数据丢失扩大化。3.2 什么时候才应该使用 always虽然always在某些场景下看起来更安全但实际业务中能用到的场景非常少。以我们这次故障为例业务方最初配置always是因为“担心丢失数据”。但 Redis 在这套体系里是缓存层还是数据存储层决定了持久化策略的选择。如果 Redis 只做缓存数据可以从数据库回源完全没必要开启 AOF如果 Redis 承载了部分不能丢失的计数、Token 等数据那么需要评估的是数据丢失容忍度而不是简单粗暴设置为 always。always真正适用的场景是写入量极低比如每秒几个写请求且单条数据不能丢失的强一致场景。正常每秒几千甚至几万写入的业务设置always就是在自杀。而且要想真正避免“丢失 1 秒数据”光靠 Redis 持久化是不够的。Redis 的everysec并不能完全保证数据安全崩溃时 AOF 文件末尾可能有不完整的命令。这时需要配合其他机制写操作同步双写一份到消息队列由消费者异步落库。关键业务数据直接写 MySQLRedis 只做加速。启用 Redis 主从复制主节点故障时从节点接管AOF 只是兜底。3.3 Redis 7.0 的新特性AOF 多文件机制在 Redis 7.0 中AOF 机制发生了重大变化原来的单文件 AOF 被拆分为多个文件包括 base 文件、incr 文件和 manifest 清单文件。整体思路是将全量 RDB 数据和增量命令分开存储配合 rewrite 时不再生成完整的新 AOF 文件而是通过 manifest 管理文件集合。这个升级对运维和恢复流程影响很大。恢复时不再像以前那样简单加载一个 appendonly.aof而是读取 manifest 文件确认文件集合。升级到 Redis 7.0 后要特别检查备份脚本是否适配了新的 AOF 文件格式我见过有团队的备份脚本还在拷贝旧的单文件路径结果备份一直失败数据恢复时才发现根本没有可用的 AOF 文件。4. 故障背后的真正问题缓存一致性如何保障4.1 缓存雪崩与缓存穿透的差别这次故障中Redis 不可用直接触发了缓存雪崩但外面很多人会把雪崩和穿透混为一谈。缓存穿透请求查询的数据在缓存和数据库中都不存在每次请求都直达数据库数据库压力巨大。缓存雪崩大量缓存同时失效或者缓存整体不可用所有请求同时打到数据库。缓存击穿某个热点 key 失效的瞬间大量并发请求绕过缓存直达数据库。这次故障就是典型的缓存雪崩Redis 整体不可用所有读请求全部落到数据库。要有效预防这三类问题光靠 Redis 本身的配置调优还不够必须在架构层面做兜底。多级缓存就是最有效的手段之一。4.2 多级缓存的经典架构本地缓存 Redis 数据库多级缓存的标准布局是一级缓存本地缓存部署在应用进程内如 Caffeine、Guava Cache。访问速度最快纳秒级响应但容量有限且多实例各自独立。二级缓存分布式缓存Redis跨进程共享毫秒级响应容量较大。三级存储数据库最终一致性数据源。读请求处理顺序本地缓存 - Redis - 数据库。找到即返回并逐级回填。这套架构能扛住 Redis 故障的核心原因在于**本地缓存其实挡掉了大部分热点请求。**Redis 不可用时Caffeine 仍然能在应用内返回数据虽然命中率不如 Redis 高但足以让数据库扛住瞬时压力。实测时我们通过本地缓存拦截了大约 30% 的读流量数据库压力从 99% 降到了 60% 左右。接着手动切换 Redis 持久化策略后Redis 恢复系统才彻底稳定。4.3 本地缓存与 Redis 的一致性更新策略多级缓存最大的难点不是读而是写。当数据更新时如何保证本地缓存、Redis、数据库三者之间的数据一致性。先说不推荐的方案先更新数据库再删除缓存。这个方案在单机缓存场景下没问题但在多级缓存场景下有个坑本地缓存没有失效机制时其他实例的本地缓存不会感知数据更新继续返回旧数据。标准做法是“订阅变更 - 主动失效本地缓存 - 更新数据库 - 删除 Redis 缓存”业务操作中先更新数据库。发送一个缓存失效消息到消息队列或 Redis Pub/Sub、Canal Binlog 监听。所有应用实例收到消息后删除本地缓存中对应 key。同时删除 Redis 中的对应 key。后续读请求发现缓存未命中回源数据库并重新回填各级缓存。这个方案能保证最终一致性。短期内的数据不一致窗口取决于消息处理延迟通常可以控制在几百毫秒以内。还有一种更轻量的做法本地缓存设置极短的过期时间如 30 秒配合主动失效机制兜底保证数据不会长时间不一致。这种做法实现简单但存在一个问题如果主动失效消息丢失数据不一致窗口会被拉长到过期时间。所以两者需要配合使用。4.4 缓存更新策略选型Cache Aside 与延迟双删多级缓存场景下更新策略的选型很重要。我这里直接给出经验结论Cache Aside旁路缓存读请求未命中则回源数据库并回填缓存写请求先更新数据库再删除缓存。这是最通用的方案适合读多写少场景。延迟双删先删缓存再更新数据库延迟后再次删缓存主要解决“先更新数据库再删缓存”的并发竞态问题。但实现复杂且延迟时间不好把握我建议只在与第三方系统对接、无法使用消息队列时才考虑。Write Through / Write Back直写/回写缓存层直接承担写入责任对 Redis 的依赖度高适合把 Redis 当作存储的场景但在缓存架构中不常用。从实际维护角度看我推荐Cache Aside 数据库 Binlog 监听 消息队列失效缓存的组合。这套方案可解释性强、链路清晰、不易出幺蛾子。5. 恢复演练与“Redis 可用性”的进一步治理5.1 故障恢复的标准动作与顺序Redis 故障后的恢复顺序很多人第一步就做错了。比如这次故障中有人第一时间提议直接重启 Redis重启后 AOF 日志会全部回放如果 AOF 文件很大回放会导致长时间不可用。正确顺序应该是先限流瞬间将不重要的非核心流量拒绝掉保护后端数据库。不要指望 Redis 快速恢复先保住系统不崩溃。降级把回源数据库的读请求切换为查备库或本地缓存兜底。查因确认 Redis 阻塞原因进程还在就通过redis-cli info persistence和redis-cli info stats检查持久化相关指标确认是不是 fsync 或 rewrite 阻塞。调整配置临时修改appendfsync为everysec必要时使用CONFIG SET热加载。观察恢复等待 Redis 延迟指标回归正常后逐步放开限流。根本治理恢复之后并不代表结束。要复盘配置、完善监控报警制定持久化配置规范评估架构层面是否引入多级缓存、主从高可用。这套顺序的关键在于“先保护数据库再恢复 Redis”。如果顺序反了Redis 一恢复就放开全部流量数据库可能直接被击穿。5.2 Redis 高可用部署的核心手段这次故障中单点 Redis 是放大器。如果当时有主从切换机制Redis 主节点卡死后哨兵会自动把从节点提升为主节点业务影响时间能从 50 分钟缩短到 10 秒以内。部署建议至少一主一从从节点不仅用于高可用还可以承载读流量。如果只需要部分场景强一致主从模式下可开启读写分离但要注意主从复制延迟问题。哨兵模式Sentinel是生产环境的最低要求。三个哨兵节点互相通信自动完成故障检测和故障转移。Redis Cluster 适合数据量超过单机内存、需要水平扩展的场景。但 Cluster 运维复杂度更高数据分片、槽位迁移都有一套独立的运维逻辑。5.3 全链路缓存治理从 Redis 到多级缓存的一致性保障通过这次故障我们最终的治理方案可以归纳为“持久化配置规范 多级缓存兜底 高可用切换 全链路监控”四位一体。在 Redis 侧明确 appendfsync 统一为 everysec。开启混合持久化aof-use-rdb-preamble yes。监控持久化阻塞指标aof_delayed_fsync、aof_pending_bio_fsync、latest_fork_usec。当有多实例时统一配置管理平台避免人工登录修改配置。在多级缓存侧本地缓存 Caffeine Redis MySQL 三级架构。数据更新走“先 DB 后失效缓存”的最终一致性链路。本地缓存失效订阅通过 Redis Pub/Sub 或 MQ 广播。定期压测多级缓存的容灾能力模拟 Redis 实例宕机确保本地缓存和数据库能扛住 5 分钟以上的瞬时流量。6. 常见问题与排查技巧实录6.1 Redis 延迟毛刺如何定位是持久化问题Redis 主线程阻塞最容易被忽略的就是持久化相关的指标。遇到延迟毛刺按以下顺序排查redis-cli --latency -h host -p port确认延迟情况。redis-cli -h host -p port info persistence查看aof_last_write_status、aof_delayed_fsync、rdb_last_bgsave_status。redis-cli -h host -p port info stats查看latest_fork_usec如果超过 1 秒就要关注 fork 耗时。查看系统层面的磁盘 IOiostat -x 1关注%util和await指标。结合慢日志SLOWLOG GET 20看是否有BIO_AOF_FSYNC等内部操作或异常命令。注意Redis 的慢日志不一定只记录命令Redis 7.0 中部分后台操作也会记录到慢日志中看到BIO相关条目时不要忽略。6.2everysec也可能丢数据如何处理 AOF 文件截断everysec模式下Redis 每秒执行一次 fsync如果机器突然断电或崩溃最后一秒写入的数据可能丢失。即使不崩溃AOF 文件末尾也可能存在不完整记录。Redis 针对 AOF 文件截断的情况有一个参数aof-load-truncated。默认值为 yes表示加载 AOF 时如果发现文件被截断会忽略尾部的残缺部分正常加载。生产环境建议保留默认配置不要改成 no。如果改成 noRedis 会拒绝启动还要手动修复 AOF 文件运维成本很高。排查 AOF 文件问题可以用这个命令redis-check-aof --fix appendonly.aof但注意这个命令会删除损坏部分的数据。在操作之前先备份原始文件。6.3 Redis 主从复制与 AOF 的联动关系主从环境下主节点的持久化配置会影响复制性能。主节点开启 AOF从节点同步数据的来源是主节点的 RDB 快照和复制缓冲区从节点自身的持久化配置不影响同步但会影响从节点的重启恢复能力。如果主节点关闭了持久化而哨兵自动把从节点提升为主节点此时新的主节点可能没有任何 AOF/RDB 数据一旦重启数据全部丢失。所以高可用环境下主从节点都要开启持久化不能为了省 IO 只让主节点开持久化。6.4 多级缓存构建中的典型问题速查问题原因解决方案本地缓存命中率低缓存过期时间过短设置不同 key 的差异化过期时间热点 key 时间更长本地缓存数据不一致主动失效消息延迟或丢失缩短兜底过期时间使用消息队列保证投递可靠性Redis 抖动导致数据库被打挂缺少本地缓存兜底或者本地缓存容量不够增加 Caffeine 容量按热点 key 设置随意淘汰策略缓存穿透导致数据库压力大查询的数据不存在缓存层从未生效布隆过滤器或者缓存空值短过期缓存击穿导致热点 key 失效key 过期瞬间被大量访问热点 key 不设置过期时间后台定期刷新或者使用互斥锁回源7. 日常运维中非常值得做的小改进这套方案跑了一段时间后我整理了三个落地后收益最大的改进分享给大家。第一个是给 Redis 的关键指标建立独立监控面板。不要等告警才看指标。平时就要周期性关注aof_delayed_fsync、rdb_bgsave_in_progress、latest_fork_usec这几个值。延迟毛刺通常在这些指标上会提前很多天暴露出来。第二个是定期做故障演练。每个月模拟一次 Redis 宕机验证多级缓存兜底能力检查本地缓存的命中率是否足够数据库连接池是否够用。演练中发现的问题通常比线上故障更值得修复因为代价小。第三个是配置变更全平台化。所有 Redis 配置统一走配置中心不能让人 SSH 到机器上手工改配置。手工改配置意味着没有审计、没有回滚、没有告警这次故障的根源就是某个同学直接在服务器上改了配置没有走流程。最后再分享一个小技巧排查缓存类故障时不要只盯着 Redis 看要从全链路视角看。从应用进程 - 本地缓存 - 网络 - Redis - 数据库逐层排查才能找到真正的瓶颈。很多时候你以为是 Redis 出了问题真相却是数据库慢查询拖垮了缓存回填线程导致缓存全部过期。这种障眼法我在线上见过太多次了。 
