先声明一个前提这篇文章里的“数据丢失”指的都是 Redis 在异常宕机、主从切换、内存淘汰、进程崩溃等场景下丢数据的问题。Redis 能保证高性能本质上是因为它把数据放在内存里而内存的天然属性就是“断电即失”。所以凡是生产环境用了 Redis第一步要面对的就是怎么在性能和持久化之间找平衡。我见过太多同行栽在这上面开发环境随便跑业务量一上来就出事。最常见的就是主节点挂了从节点顶上之后数据对不上更常见的是没开持久化或者持久化配置不合理服务重启一次缓存全部清空后面的请求直接把数据库打爆。这篇文章不是给纯新手科普 Redis 命令而是从“丢数据”这个具体问题出发把 RDB、AOF、主从复制、脑裂保护、过期策略和内存淘汰这些硬知识点串成一条线讲清楚每个环节背后“为什么这样做”以及你在生产环境里到底该怎么配置才能少吃亏。先交代一下适合谁看已经用过 Redis懂得基本命令但对“持久化原理”和“数据可靠性保障机制”只有模糊概念的人。如果你是刚接触 Redis 不久前几节可能需要多看两遍配合文中的配置参数实际敲一遍理解会加深很多。1. 数据到底丢在哪先给问题画个像很多人一提“Redis 数据丢失”第一反应就是“Redis 本身就是内存数据库丢数据很正常”。这个说法太粗糙了。同样是丢丢的环节不一样原因和解决方案完全不同。我习惯把 Redis 丢数据拆成四类场景来分析排查的时候先对号入座能省下一大半时间。1.1 进程退出造成的全量丢失这条最好理解Redis 进程没了内存里的数据跟着没了。进程退出的原因可能是崩溃比如访问了非法内存地址被系统杀掉、可能是 OOM 被内核 kill也可能就是有人误执行了 shutdown 或者重启容器。如果此时 RDB 和 AOF 都没配那数据就是彻底没了想找回都无从谈起。有人觉得“我配置了 RDB是不是就安全了”不一定。RDB 是间隔性快照最近一次的持久化点跟崩溃时刻之间仍然有一段窗口期数据会丢。比如你设置的 save 规则是 900 秒内至少 1 次写操作才执行持久化那 900 秒内的数据可能全丢。这在防缓存击穿场景上是致命的数据库那边可能要承受上百万次直接查询。1.2 主从切换产生的部分丢失这是生产环境最常见的坑。主库 Master 和从库 Replica 之间靠异步复制同步数据也就是说主库处理完写命令后不会等从库确认写成功就返回给客户端“写入完成”。这几毫秒的时间差里如果主库突然宕机尚未同步给从库的那部分写操作就丢失了。这段话值得反复读三遍哪怕你的 RDB、AOF 配置都完美无缺只要主从复制是异步的就有丢失窗口。Redis 默认的异步复制机制从设计上就没有办法做到“一条都不丢”。业界大部分公司采用的方法是“尽量缩小窗口”而不是“完全消除丢失”。1.3 脑裂导致的丢失脑裂是分布式系统里最隐蔽的数据丢失场景也是最容易被忽略的。所谓脑裂就是主库因为网络分区比如网线被切断、交换机故障、长时间 GC 导致的心跳超时跟其他从库和客户端之间“失联”但主库进程本身没有退出。哨兵Sentinel集群这时候检测到主库掉线执行故障转移把某个从库提升为新的主库。然而网络故障只是暂时性的老主库过一会儿恢复了跟新主库形成两个“主”并存的状态客户端写入会产生混乱。最严重的问题是老主库恢复后会被作为一个从库重新挂到新主库下面同步新主库数据这意味着老主库在故障期间接收的新写入数据会被同步操作清掉——因为从库不允许保留自己的差异数据。从业务视角看用户写入成功了但数据没了而且看起来毫无痕迹。1.4 内存淘汰策略造成的“软丢失”严格来说这类丢数据不算“故障丢失”但在业务感知上就是“我写进 Redis 的数据消失了”。Redis 有 maxmemory 限制当内存使用超过阈值会根据配置的淘汰策略主动删除一部分 key。如果用的是 volatile-lru 或 allkeys-lru 这类策略且业务高峰期内存打满那些不太活跃的数据就会被无声无息地扔掉。这类丢失让人最头疼的地方在于它不是崩溃引发不会在日志里留下明显的 ERROR很多团队甚至不知道 Redis 在偷偷删数据。排查方式就是监控 evicted_keys 指标用 Grafana 或者 Prometheus 盯住这个计数器一旦发现持续上涨基本可以断定是内存淘汰在起作用。所以要是有人问我“为什么 Redis 会丢数据”我的回答通常不是单一答案而是反问他丢在哪个环节进程退出丢全量、主从切换丢增量、脑裂丢大量、内存淘汰丢冷数据。这四类分别有不同的应对方案接下来逐个拆解。2. 持久化解析RDB 和 AOF 最全对比与选择持久化是防丢数据的第一个堡垒。Redis 提供两种持久化机制RDB 快照和 AOF 日志它们的设计哲学完全不一样适用场景也不同而且可以有四种组合方式配置错了照样丢数据。2.1 RDB 快照的工作原理与盲区RDB 是 Redis 默认的持久化方式。它做的事情是每隔一段时间把内存里所有的数据生成一个二进制快照文件默认叫 dump.rdb写入磁盘。这个过程采用操作系统提供的 fork 技术主进程 fork 一个子进程出来子进程负责把数据写到临时文件写完再原子性地替换旧文件。好处是主进程完全不用阻塞在磁盘 I/O 上性能影响极小。RDB 最核心的配置就是 save 参数默认配置如下save 3600 1 save 300 100 save 60 10000这三行的意思是如果 3600 秒1 小时内至少有 1 次写操作就触发一次 RDB 持久化。如果 300 秒5 分钟内至少有 100 次写操作就触发一次。如果 60 秒内至少有 10000 次写操作就触发一次。注意这三个条件之间是或的关系满足任意一个就会保存。这个机制在低频写场景下显得很“佛系”。比如一个电商网站高峰期 1 秒几千次写入此时 60 秒 10000 次的条件很容易满足RDB 会频繁生成但如果业务是深夜低峰期5 分钟 100 次都达不到那这只“小猪”就一直在睡觉到凌晨三四点数据库出了故障停机前十几分钟甚至几小时的数据全部丢失。RDB 最大的盲区就在这里基于时间间隔的触发机制决定了它天然存在数据丢失窗口。即便你像下面这样把 save 间隔调到很小比如 60 秒一次也仍然有最多 60 秒的写入会丢。但你要知道RDB 生成是全量快照数据集如果达到 10GB每次生成快照的开销都不小太频繁反而严重影响性能。所以我的建议是RDB 不能作为唯一的持久化手段它更适合用来做冷备份和灾后恢复。RDB 文件体积小、加载速度快适合周期性备份到其他机器哪怕丢失最近一小段数据也能快速恢复到相对完整的版本。但如果你对数据完整性的要求比较高那就必须引入 AOF。2.2 AOF 日志的写入时机与三种策略AOFAppend Only File的思路跟 RDB 完全相反不拍快照而是记录每一次写命令。Redis 收到写请求在修改内存数据结构的同时把这条命令追加到 AOF 缓冲区然后根据配置的刷盘策略决定何时写入磁盘。AOF 的刷盘策略由 appendfsync 参数控控制共有三种策略appendfsync 值行为数据安全性性能影响每次都刷always每条写命令都同步落盘最高最多丢一条命令最慢每条写都要做一次磁盘 fsync每秒刷everysec每秒钟统一把缓冲区刷一次盘中等最多丢 1 秒数据折中方案性能损耗可接受交给系统no由操作系统决定何时刷盘最差可能丢数秒数据最快几乎不主动做 fsync生产环境我建议直接用everysec这是 Redis 官方默认也是绝大多数公司的选择。每秒一次的刷盘频率下Redis 做基准测试性能损耗很小但最坏情况只丢 1 秒内的写入命令对于大多数业务场景完全可接受。追求极限数据安全比如支付交易流水才能考虑 always但是每条命令都要同步刷盘单线程的 Redis 性能会明显下降高并发场景下吞吐量几乎腰斩。no 策略千万别用它把刷盘时机完全交给操作系统的 page cache 刷写逻辑一旦进程崩溃或者整机断电丢失的数据量可能是几秒甚至十几秒的完全没有可控性。这里补充一个重要概念AOF 不是简单地一直追加命令就行。随着运行时间变长AOF 文件里累计的命令越来越多比如同一个 key 被 set 了 100 万次文件里就会留 100 万条 set 记录文件体积越来越夸张。这时需要触发 AOF 重写机制Redis 会扫描当前内存里的数据生成恢复当前数据集所需的最精简命令集覆盖掉历史冗余日志。重写由 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 两个参数控制默认是当 AOF 文件体积超过上次重写后体积的一倍percentage100同时最小超过 64MB 才触发。生产环境一般不用改这两个默认值但如果你的业务写命令特别频繁可以适当调低 percentage让重写发生得更勤快一些防止 AOF 文件暴涨后恢复变慢。2.3 混合持久化日常服务与极端恢复的折中Redis 4.0 之后引入了一个非常实用的能力混合持久化。通过配置 aof-use-rdb-preamble yes 开启。原理是在 AOF 文件的开头写入一段 RDB 格式的二进制数据之后才是增量写命令的 AOF 格式日志。这样做的好处是两全其美RDB 部分保证了大部分数据以紧凑的二进制格式存储占用的空间小加载快。AOF 部分记录重写之后的新写入命令补上了 RDB 原本存在的时间窗口盲区。发生崩溃恢复时Redis 先快速加载 RDB 段恢复主干数据再逐条执行 AOF 段的命令补齐最新写入恢复速度比纯 AOF 快一个量级同时数据完整性又能保证到秒级。当前最新版本的 Redis官方是默认开启混合持久化的这份配置我建议保持开启不要关。需要留意的是AOF 的追加方式在极端情况下还是有隐患。比如服务器突然断电AOF 文件最后几条命令可能是“半截命令”也就是只写了一半就断电了。Redis 启动时会检测到 AOF 文件尾部损坏默认情况下会因为 aof-load-truncated 参数为 yes 而自动截断尾部然后继续加载。不会因为一个小尾巴就拒绝启动。但这里有个重大风险如果你因为 AOF 文件尾部损坏就手动删掉整个文件或者用编辑器打开改成“正确格式”再保存反而可能毁掉整个 AOF 文件的可解析性导致 Redis 恢复失败。正确做法是让它自动截断或者用 redis-check-aof 工具修复修复之后单独做一个哨兵检查。3. 主从复制与哨兵同步机制、丢失窗口与坑点持久化解决的是“进程重启后的数据恢复”问题但生产环境真正考验人的是“主库宕机如何故障转移”的场景。这就要讲到主从复制和哨兵机制。很多同学会用 Docker 部署“Redis 主从”以为配好了就稳了其实里面的同步断点、复制积压缓冲区、脑裂保护每个都是一道坎。3.1 主从复制的两阶段流程Redis 主从复制的完整流程可以从一张图来理解整体逻辑但这里不画图直接用文字拆从库启动或断线重连时向主库发送psync命令参数包含复制 IDreplication ID和偏移量offset。主库判断从库携带的复制 ID 是否跟自己的相同。如果相同且偏移量还在自己的复制积压缓冲区repl-backlog-size范围内就进行增量同步只把从库缺失的部分命令发给它——这种临时的断线重连开销很小。如果复制 ID 不一致或者偏移量已经超出了复制积压缓冲区的内容范围主库就只能做全量同步。此时主库会 fork 子进程生成一份当前数据的 RDB 快照发给从库在传输期间收到的写命令会暂存在复制缓冲区里等 RDB 传完之后一并发给从库追补。正是这个“复制积压缓冲区”的概念引出了主从场景第一个丢数据的隐患如果从库断线时间太长、落下的位移超过 repl-backlog-size 设定的大小就会被强制做全量同步。全量同步期间主库生成的 RDB 文件和追补命令一旦传输过程因为网络问题中断从库可能反复失败。但如果只是临时断线几秒、几十秒应该尽量让增量同步成功避免全量同步。所以生产环境建议把 repl-backlog-size 调大一些默认是 1MB我实际使用下来一般调到 64MB 甚至 128MB覆盖更长的断线场景。3.2 异步复制与无穷小的丢失窗口Redis 主从的数据复制是异步的这意味着主库即使收到了从库的 ACK也不会阻塞客户端的写请求。这是一把双刃剑性能高但数据不一致窗口客观存在。量化一下网络 RTT 在局域网内通常是 0.1ms 到 1ms 级别也就是说从库同步的延迟通常极低在毫秒量级。但只要主库在这几毫秒里宕机那几毫秒的写入就会丢。数据丢失的“量”等于写入速率乘以延迟时间。举个例子一个峰值每秒写入 10 万次的 Redis 主库若主从同步延迟 1ms丢失窗口内的写入量就是 100 条命令。对大多数业务来说100 条命令的丢失可能不痛不痒但如果这 100 条里有下单支付的关键操作那就很难接受了。注意这不是 Redis 配置错误而是异步复制机制天生的特性想消除就得让主从复制变成同步复制但那样会大幅牺牲写入性能。因此很多团队引入了一种“双保险”在主从同步之外另启一套应用层补偿机制。比如先写本地消息队列消费成功后再确认写入 Redis若发现丢失则从消息队列重新推送。Redis 本身解决不了绝对不丢需要业务架构层的兜底。3.3 哨兵模式下的脑裂保护参数哨兵Sentinel是 Redis 官方提供的 HA 方案负责监控主库健康状态在主库异常时自动执行故障转移。但前面提到主库异常并不等于进程退出也可能是网络分区。网络分区恢复后老主库以从库身份重新接入集群就会被新主库的数据覆盖这会造成脑裂丢失。Redis 针对脑裂提供了两个重要参数min-replicas-to-write主库至少需要多少个健康的从库连接才允许执行写操作。min-replicas-max-lag这些从库跟主库之间允许的最大延迟秒数。组合逻辑是如果主库发现与从库的连接数量低于 min-replicas-to-write或者从库延迟超过了 min-replicas-max-lag主库会拒绝执行写命令对客户端返回错误。这相当于给主库加了一个“保险开关”当它感知到自己可能已经跟集群失联时暂停写入从而避免网络分区期间暗地里接收大量写入然后恢复后被新主库清空。举个例子配置如下min-replicas-to-write 1 min-replicas-max-lag 10意味着主库在以下两个条件同时满足时才允许写入至少 1 个从库在线且从库复制延迟不超过 10 秒。假设主库因为网络分区导致所有从库失联触发主库拒绝写入这时候客户端收到错误但不至于数据丢失。网络分区结束后新主库已经通过哨兵完成切换老主库降级为从库那些“拒绝写入”的请求数据虽然没写进 Redis但业务层面能感知到异常做补偿比“数据莫名消失”要好得多。我见过不少团队没配这两个参数导致脑裂问题排查了好几个星期。如果你现在就管理着一套哨兵模式集群赶紧看下这两个参数配了没有。这也是 Redis 官方配置模板里容易被人忽略的两行。3.4 Docker 部署主从的独特风险用 Docker 部署 Redis 主从已经成为开发环境的主流选择毕竟镜像拉取、快速起实例都非常方便。但 Docker 环境的 Redis 有它特殊的丢数据风险要特别注意Docker 容器默认没有持久化存储层容器删除后数据跟着没。所以必须在 docker run 时用 -v 参数把容器内的 /data 目录映射到宿主机磁盘或者使用 Docker Compose 声明 volumes。Redis 官方镜像的持久化目录就是 /data不映射等于白干。容器重启策略要配好。比如--restart always不然宿主机重启时容器不会自动恢复哨兵会误判主库宕机触发无谓的故障转移从而产生脑裂风险。Docker 宿主机的时钟漂移会干扰 Redis 的过期时间判断。如果宿主机时钟不准比如向后跳了几分钟Redis 就会认为一些 key 已经过期而提前删除造成“数据丢失”。容器内用 UTC 时间的 Debian 基础镜像问题不大但一定要保证宿主机开启 NTP 同步这点很多人完全没意识到。关于 Docker 部署还有一个比较隐蔽的坑Redis 官方镜像默认用 root 用户运行还是非 root 用户不同版本不一致。如果你用映射卷方式挂载目录要注意容器内 redis 用户是否有权限写挂载目录否则 Redis 进程会报错然后退出看起来像“数据丢失”其实是持久化文件写不进去。这个坑排查起来非常耗时因为 Redis 启动时可能不报错而是写日志到 stderr如果不看容器日志根本发现不了。4. 过期策略与内存淘汰两类“软丢失”的真相上面讲的都是机器故障场景。但还有一类数据丢失Redis 运行完全正常、没有任何报错但业务就是发现 key 没了。这就是过期策略与内存淘汰我把它称为“设计性丢失”。4.1 过期 key 删除策略惰性删除与定期删除每一把 Redis key 都可以通过 expire 设置过期时间。到了过期时间Redis 并不保证立刻删除这个 key而是采用惰性删除 定期删除组合策略惰性删除客户端访问一个 key 时Redis 首先检查它是否已经过期如果过期则删除并返回空。定期删除Redis 每隔一段时间默认每秒 10 次从设置了过期时间的 key 集合中随机抽查一部分如果发现过期就删除。这意味着一个 key 过期后如果没有任何客户端访问它在内存里可能还会存留一段时间直到过期且被定期删除任务扫描到。从业务视角看过期时间一到其实就认为数据“不存在了”。这里有个容易混淆的概念过期时间不是精确的。你设置 key 只活 60 秒但 Redis 可能在第 60 秒整被“惰性删除”检查到并返回不存在也可能第 60 秒时还在内存里第 60.5 秒才被定期删除扫掉。对大多数业务无所谓但如果你的业务逻辑依赖“没有过期 key 就不能再次写入”这类操作要注意此处的语义。4.2 maxmemory 与淘汰策略谁动了我的数据当 Redis 内存达到 maxmemory 阈值且继续有新的写请求进来Redis 必须腾出空间。腾空间的方式就是执行淘汰策略策略由 maxmemory-policy 配置项决定。常见策略对比策略作用范围行为noeviction全部不淘汰任何 key新写入直接报错allkeys-lru全部 key从所有 key 中按 LRU最近最少使用淘汰volatile-lru仅设置了过期时间的 key从设置了过期时间的 key 中按 LRU 淘汰allkeys-random全部 key随机淘汰任意 keyvolatile-random仅设置了过期时间的 key从设置了过期时间的 key 中随机淘汰volatile-ttl仅设置了过期时间的 key优先淘汰剩余存活时间最短的 key重点说一下。很多公司的缓存场景Redis 里存的既有长期有效的 token 类 key又有短期的验证码 key还有一些不设过期时间的基础配置。如果 maxmemory-policy 配的是 allkeys-lru那基础配置也可能被淘汰业务可能找不到配置而异常。反之配 volatile-lru 则只影响设了过期时间的 key相对更安全。但 volatile-lru 有个毛病如果大量 key 都没设过期时间淘汰范围很小内存很快又塞满了Redis 进入 noeviction 模式写入报错。我在生产环境的经验是要求每一条缓存 key 都必须设置合理过期时间然后使用 volatile-lru这样既能淘汰冷数据又不会伤到不设过期时间的关键配置。另一个容易踩的坑是修改 maxmemory-policy 需要重启吗不需要Redis 支持 config set 在线修改但我建议生产环境不要在高峰期乱动淘汰策略因为切换策略的瞬间 Redis 可能会执行一次全量淘汰扫描对短时性能有影响。4.3 业务侧如何应对“软丢失”针对过期与淘汰造成的软丢失我的建议是分层设计关键数据不要只存 Redis要有 MySQL 或其他持久层做最终一致性兜底。Redis 只做加速层。缓存写入时宁可设置较短的 TTL也不要“永久不过期”。永久 key 一旦被淘汰故障范围往往更大。监控 evicted_keys、expired_keys 和 mem_fragmentation_ratio把它们加入可观测性大盘。一旦 evicted_keys 在快跑要么加内存要么调淘汰范围要么检查代码里有没有不合理的大 key 写入。这里还牵涉到一个热度问题有些 key 明明已被批量预热但实际业务访问频率低很容易被 LRU 策略“误杀”。解法是给热点 key 的过期时间设长一点或者用对象池保证周期性刷新过期时间。5. 数据丢失排查清单一分钟对准故障类型讲了这么多理论落地到实际故障处理时很多人还是不知道从哪个指标入手。我前面说过先给故障类型分好类再排查。这里给出我自己的排查顺序几乎覆盖了我这几年的线上经验。5.1 五大排查步骤第一步看 Redis 日志。是崩溃退出还是正常 shutdown有没有 OOM Killer 的痕迹通过 dmesg 查看有没有Out of memory: Kill process日志有没有持久化失败或者 AOF 加载截断的警告第二步看监控大盘。同时拉出全量内存、used_memory、evicted_keys、expired_keys、rejected_connections、connected_slaves 这些指标。重点看故障时间点有没有 evicted_keys 暴涨、connected_slaves 下降。第三步查哨兵日志。主从切换时间点、切换原因主观下线客观下线、切换前后的主库是谁。这一步能快速定位“是否发生脑裂”。第四步验证 AOF/RDB 文件。AOF 文件在不在大小是否正常用 redis-check-aof 检查文件完整性用 redis-check-rdb 检查 RDB 文件。第五步回放业务写入。如果发现确实丢了数据再看这些数据是否在消息队列里还留有副本能不能补偿回写。这个顺序基本上可以覆盖 95% 的“Redis 数据丢失”类问题。如果是纯业务写法错误比如误用 DEL、误设置了相同 key 覆盖日志和监控都不会有异常那就需要查应用侧代码了。5.2 常见问题速查表症状可能原因排查重点重启后 Redis 所有数据都没了未开启持久化或持久化目录映射丢失检查持久化配置、挂载路径重启后只剩部分数据RDB 间隔触发导致窗口期丢失检查 save 参数与最后一次 RDB 时间戳主从切换后写入数据丢失异步复制窗口 主库宕机评估写入量与延迟考虑同步机制扩展网络分区恢复后老主库数据消失脑裂配置 min-replicas-to-write 与 min-replicas-max-lag内存打满后某些 key 消失内存淘汰策略查看 evicted_keys 指标、调整淘汰策略设置了过期时间的 key 提前消失时钟漂移或惰性删除语义理解偏差校准宿主机时钟确认业务语义AOF 文件损坏导致启动失败异常断电写入半截使用 redis-check-aof 修复或开启自动截断Docker 部署重启后数据丢失容器卷未映射、redis 用户无权限检查 volumes 映射和容器日志这张表可以截图存着排查故障时对着找方向比自己瞎猜高效得多。6. 生产级持久化与高可用配置参考前面的原理讲完了最后给出一份我自己在生产环境中沉淀下来的配置基线你可以拿去做模板记得根据实际业务调整。6.1 Redis 持久化推荐配置# RDB 配置 save 3600 1 save 300 100 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /usr/local/redis/data # AOF 配置 appendonly yes appendfilename appendonly.aof appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes aof-use-rdb-preamble yes几个参数的解释stop-writes-on-bgsave-error yes表示 RDB 快照写失败时Redis 拒绝新的写入。这个参数有两面性。好处是能第一时间暴露磁盘故障避免后续数据越积越多却完全不能持久化坏处是磁盘一坏业务直接受影响。对数据敏感的业务建议保持 yes对缓存场景且容忍部分丢失的可以考虑 no。no-appendfsync-on-rewrite yes表示 AOF 重写期间不做 fsync防止 AOF 重写与刷盘竞争造成阻塞。aof-use-rdb-preamble yes开启混合持久化强烈建议保持开启。6.2 哨兵与主从配置要点哨兵配置文件里要做下面三件事sentinel monitor mymaster 主库IP 主库PORT 2仲裁需要多少个哨兵同意才判定主库客观下线一般配置为总哨兵数的大多数多数奇数。sentinel down-after-milliseconds mymaster 5000主库多久无响应才判定为“主观下线”。生产环境建议 5 秒到 10 秒太短容易误判太长则故障转移太慢。min-replicas-to-write 1和min-replicas-max-lag 10这是主库的脑裂保护非常重要的底线之前已经详细介绍过原因。6.3 业务层面的双写双删策略光靠 Redis 自身配置解决不了所有数据一致性问题业务层面还要有一个兜底方案。我强烈推荐“双写双删”方案先更新数据库。再删除 Redis 旧的缓存 key。延迟几百毫秒后再次删除一次该 key。为什么要延迟再次删除因为并发场景下可能出现线程 A 更新数据库线程 B 读数据库旧值然后写回缓存线程 C 删除缓存时线程 B 的旧值刚好写回。此时缓存又变成了旧值第三次延迟删除就能补偿。这个方案很简陋但很实用很多团队用它在无侵入情况下把缓存最终一致性做到可接受。另一种更稳妥的方案是引入消息队列。更新数据库后发一条“清缓存”消息给消费者消费者收到后删除对应 key。即使删缓存失败消费者可以做重试数据不一致的时间窗口从“随机”变成“可控”。但我得坦诚地讲这种方案要额外维护消息队列和消费者复杂度变大不是所有项目都值得做。6.4 备份策略除了线上实时持久化我建议至少每日做一次冷备份redis-cli -h 127.0.0.1 -p 6379 BGSAVE cp /data/dump.rdb /backup/redis/$(date %F)_dump.rdb redis-cli -h 127.0.0.1 -p 26379 -a 密码 SENTINEL get-master-addr-by-name mymaster通过 BGSAVE 触发一次 RDB 生成然后把 RDB 文件拷贝到其他机器或云存储。切记备份文件一定要做异地冗余不能只放在同一台机器上否则磁盘故障时备份跟着一起没了。模拟演练也很重要至少每半年要拿最新的备份文件放到新的 Redis 实例上做一次冷启动验证确认文件没有损坏、数据可以恢复。很多团队的备份脚本跑了几年结果真出事时才发现备份文件早已损坏或者格式不兼容等于白备份。6.5 容器化场景的配置清单最后给用 Docker Compose 跑 Redis 的读者一个精简版参考services: redis: image: redis:7-alpine container_name: redis-master restart: always command: [redis-server, /usr/local/etc/redis/redis.conf, --appendonly, yes] ports: - 6379:6379 volumes: - ./redis.conf:/usr/local/etc/redis/redis.conf - ./data:/data environment: - TZAsia/ShanghaiDocker 部署的三个底线数据目录一定要映射、容器启动命令里一定要写对配置文件路径、容器要设置时区。这三个都看着不起眼任何一个配错了丢数据的概率都会成倍上升。最后再分享一点经验在实际运维中我最大的感受是Redis 的参数配置从来不是“照着抄就行”而是要在每一类数据丢失场景里想清楚“我能容忍丢多少、丢多久、如何补偿”。比如我们的订单系统用 Redis 做库存预扣减库存数据丢了就是超卖事故所以我们在 Redis 之上还维护了一个 MySQL 库存表Redis 只是高性能读缓存而我们的用户会话 token 数据丢了顶多让用户重新登录一次所以这个 Redis 业务就放心用了 everysec 模式。同一个集群里跑不同业务对数据安全性的要求完全不同不要让所有业务共用一套无脑的“默认配置”。还有一句话非常重要不要在出问题的时候才去翻文档。生产环境的持久化配置、哨兵参数、备份脚本、恢复演练一定要提前准备。等真正的故障到来时你不会有时间读这篇文章的。希望这篇整理能帮你把 Redis 数据丢失问题从“玄学”变成“科学”。各位在生产和实验环境中还有哪些独特的数据丢失场景或者踩过更深的坑欢迎一起交流。