缓存 (Caching) 的七宗罪：当面试官问“数据不一致怎么办”时，别只说“设置过期时间”。

在后端架构面试中，Redis 缓存与数据库的数据一致性问题不仅是考察技术深度的试金石，更是区分初级开发者与资深架构师的分水岭。面对这一挑战，仅仅回答“设置过期时间”是远远不够的，因为TTL 仅仅是一种被动的兜底手段，无法解决高并发场景下因网络抖动、服务重启或并发时序错乱导致的脏数据驻留问题。引入缓存本质上是将系统升级为微型分布式架构，根据 CAP 定理，我们必须在高性能与强一致性之间做出艰难权衡，其核心目标通常是实现将脏数据窗口压缩至毫秒级的最终一致性。真正成熟的回答，必须建立在旁路缓存（Cache Aside Pattern）的基准之上，深刻理解为何在高并发竞态条件（Race Condition）下，“删除缓存”在幂等性和并发安全性上远优于“更新缓存”，以及为何“先更新数据库再删除缓存”是工业界的标准范式。除此之外，为了应对“删除缓存失败”这一极端风险，你还需要掌握延时双删策略、利用消息队列进行补偿重试，以及基于 Canal 订阅 MySQL Binlog 进行异步同步等高阶技巧。本文将透过七种常见的认知误区，从底层并发原理层面剖析双写一致性的核心难点与架构权衡，助你构建出一套既能应对海量并发又能保障数据准确性的系统化解决方案。

为什么“数据一致性”是缓存设计的核心考题？

在面试中，当话题转向 Redis 或缓存架构时，“如何保证缓存与数据库的数据一致性”几乎是一道必考题。这不仅仅是在考察你对 Redis API 的熟悉程度，更是在测试你对分布式系统设计权衡（Trade-off）的深度理解。

引入缓存的初衷是为了高性能（High Performance），但根据分布式系统的 CAP 定理，在网络分区（Partition Tolerance）必然存在的情况下，我们往往需要在可用性（Availability）和一致性（Consistency）之间做出艰难的选择。当你将数据分散存储在数据库（MySQL）和缓存（Redis）两个地方时，系统实际上已经变成了一个微型的分布式架构。此时，任何网络抖动、服务重启或并发时序错乱，都可能导致“双份数据”出现偏差。

别只拿“过期时间”当挡箭牌

许多初级开发者在面对这个问题时，习惯性地回答：“设置一个过期时间（TTL），数据过期后自然会重新加载。”

这种回答在面试官眼中往往是不合格的，原因在于它回避了核心矛盾：

• 被动防御而非主动控制：TTL 是一种兜底机制，而非一致性保障策略。在数据过期前的这段窗口期（可能是 5 分钟甚至 1 小时），业务端可能会持续读取到脏数据。
• 业务场景不容忍：对于新闻列表，用户看到旧标题可能无伤大雅；但对于电商库存、金融账户余额或配置开关，几秒钟的数据不一致都可能导致超卖、资金风险或逻辑错误。

追求“最终一致性”而非“强一致性”

需要明确的是，在绝大多数使用 Redis 的互联网场景下，追求像银行转账那样的强一致性（Strong Consistency）是不切实际的。实现强一致性通常需要引入分布式事务（如 2PC、3PC）或复杂的共识算法（如 Paxos/Raft），这将带来巨大的性能开销，直接抵消了引入缓存的初衷。

因此，面试官真正期待的答案，是你如何通过架构设计，将数据不一致的时间窗口压缩到最小，即实现最终一致性（Eventual Consistency）。这需要开发者对并发场景下的“竞态条件”（Race Condition）有清晰的预判，并能根据业务对脏数据的容忍度，选择最合适的同步策略。

简而言之，这道题考察的不是“完美方案”，而是你是否有能力在高性能与数据准确性的钢丝绳上找到平衡点。

基础模式：旁路缓存 (Cache Aside Pattern) 的正确姿势

在绝大多数非硬件加速的业务开发场景中（如用户画像、商品库存、订单状态），我们最常使用的缓存策略被称为 旁路缓存 (Cache Aside Pattern)。

当面试官询问“如何保证一致性”时，首先必须明确你的基准模式。很多初学者容易混淆 Write Through（写穿）或 Write Behind（写回）等策略，但在 Redis + MySQL 的标准架构下，Cache Aside 才是工业界的绝对主流。

标准交互流程

Cache Aside 的核心逻辑在于：应用程序（Application）直接与数据库和缓存交互，而非由缓存组件代理数据库操作。

• 读路径 (Read Flow)：

1. 1. 应用接收读请求，先检查缓存。
   2. Cache Hit（命中）： 直接返回缓存数据。
   3. Cache Miss（未命中）： 从数据库读取数据，将数据回写（Set）到缓存，然后返回。

• 写路径 (Write Flow)：

1. 1. 更新数据库中的数据。
   2. 删除 (Delete/Invalidate) 缓存中的对应数据。

关键抉择：为什么是“删除缓存”而不是“更新缓存”？

这是面试中第一个主要的陷阱。许多候选人直觉上认为：“修改数据库后，应该顺便把缓存里的旧值更新为新值，这样下次读取更快。”

绝对不要这样做。 在高并发环境下，“双写模式”（Update DB + Update Cache）是导致数据脏读的温床。

场景分析：双写模式的并发灾难

假设有两个并发写请求，线程 A 试图将用户年龄改为 10，线程 B 试图改为 20：

1. 线程 A 更新数据库（Age = 10）。
2. 线程 B 更新数据库（Age = 20）。
3. 线程 B 更新缓存（Age = 20）。
4. 线程 A 更新缓存（Age = 10）。

结果：数据库是 20（新值），缓存却是 10（旧值）。由于网络抖动或 CPU 调度差异，请求的执行顺序无法保证，导致了覆盖写（Overwrite） 错误，产生了持久的脏数据。

删除缓存的优势 (Lazy Loading)

相比之下，删除缓存 (Delete Cache) 策略更加稳健且高效：

• 避免并发竞争： 删除是一个幂等操作（在某种程度上），不涉及新旧值的时序覆盖问题。一旦被删除，下一个读请求会自动触发“读数据库 + 回写缓存”的逻辑，利用数据库的事务特性保证读取到最新值。
• 懒加载 (Lazy Loading) 节省资源： 如果一个数据在 1 分钟内被修改了 100 次，但只被读取了 1 次。使用“更新缓存”策略，你需要写 100 次 Redis；使用“删除缓存”策略，你只需要删除 100 次（甚至更少，如果已经删除了就不需要再操作），且只有最后那次读取会产生一次 Redis 写入。这大大减少了无效的计算和 I/O 开销。

既然确定了“写操作需要删除缓存”，那么接下来的核心争议点就变成了：是先删缓存，还是先写数据库？ 这两个操作的顺序不同，会导致完全不同的并发风险。

争议焦点：先删缓存还是先写数据库？

在旁路缓存（Cache Aside）模式中，“更新数据库”和“删除缓存”这两个动作的执行顺序，直接决定了系统在并发场景下的数据一致性强度。这不仅仅是代码书写的顺序问题，更是对并发竞态条件（Race Condition）理解深度的考验。

面试中，如果你回答“两者都可以”或“看心情”，往往会被标记为缺乏高并发实战经验。业界公认的标准答案是 “先更新数据库，再删除缓存”，但要拿满分，你必须能够通过场景推演，清晰地解释为什么另一种方案是错的，以及标准方案潜在的微小风险。

1. 为什么“先删缓存，再更新数据库”是错误的？

这个方案看似符合直觉：先清理旧缓存，再写入新数据。但在读写并发的场景下，它极易导致严重的脏数据驻留问题。

场景推演（Race Condition）：
假设数据库中某条记录 X = 10。

1. 线程 A（写请求）：准备将 X 更新为 20。它先执行 删除缓存。
2. 线程 B（读请求）：此时并发进入。发现缓存为空（被 A 删了），于是去查询数据库。
3. 线程 B：读取数据库，由于线程 A 还没来得及更新 DB，线程 B 读到了旧值 10。
4. 线程 B：将旧值 10 回写到缓存中。
5. 线程 A：完成数据库更新，X 变为 20。

后果：
此时，数据库是新值 20，但缓存中却永久驻留了旧值 10（直到过期时间到达）。这种不一致是必然发生的，只要读请求在写请求的“空隙”中执行，就会产生脏数据。正如 腾讯云技术社区 的分析指出，这种方案导致缓存长期持有脏数据，因此在生产环境中应尽量避免。

2. 为什么“先更新数据库，再删除缓存”是主流选择？

这个顺序是 Cache Aside Pattern 的标准实现，也被 Facebook 等大厂采用。虽然它不能保证 100% 的强一致性，但在绝大多数业务场景下，它将不一致的概率降到了最低。

场景推演（为何它更安全）：
假设数据库 X = 10。

1. 线程 A（写请求）：先更新数据库，X 变为 20。
2. 线程 B（读请求）：并发读取。

• • 情况 1（缓存命中）：读到旧缓存 10。这在线程 A 删除缓存前是可能的，但这只是短暂的“最终不一致”，一旦 A 删除了缓存，后续请求就能读到新值。
  • 情况 2（缓存未命中）：线程 B 读数据库得到 20，回写缓存。数据一致。

1. 线程 A：执行 删除缓存。

唯一的理论风险（极低概率）：
要让这个方案出现脏数据，需要满足一个极其苛刻的并发条件：

1. 缓存刚好失效（或不存在）。
2. 线程 B 读取数据库，拿到旧值 10（此时线程 A 还没开始写）。
3. 线程 A 更新数据库 20。
4. 线程 A 删除缓存。
5. 线程 B 将旧值 10 写入缓存（注意：这要求线程 B 的“读DB + 写缓存”操作耗时，竟然比线程 A 的“写DB + 删缓存”还要长，且步骤 5 必须晚于步骤 4 发生）。

在实际工程中，数据库的写操作（涉及加锁、日志持久化）通常比内存中的缓存写操作慢得多。因此，线程 B 在线程 A 完成整个更新流程后才回写旧值的概率极低。根据 小林coding 的分析，这种极端情况属于“理论上的可能性”，在实际高并发系统中极少出现。

3. 真正的风险点

虽然“先更库，再删缓存”规避了大部分逻辑漏洞，但它引入了一个现实的工程挑战：如果第二步“删除缓存”失败了怎么办？

如果数据库更新成功，但 Redis 删除指令因网络抖动或超时而失败，那么缓存中依然保留着旧数据，且不会被修正。这才是面试官追问“数据不一致”时的真正考点，也是引入“延时双删”或“消息队列重试机制”的契机。

进阶方案：如何解决“删除失败”与“并发脏读”？

在上一节中，我们确立了 Cache Aside Pattern（先更新数据库，再删除缓存） 作为大多数业务场景的标准解法。对于 99% 的非核心业务（如用户头像、资讯列表等），这种策略配合合理的 过期时间（TTL） 已经足够应付。哪怕出现了短暂的数据不一致，依靠 TTL 的自动过期也能实现最终一致性，成本与收益的性价比极高。

然而，面试官的追问通常针对那剩下的 1% 极端场景，或者是对数据一致性要求极高的核心链路（如秒杀库存、金融账户）。在这些高并发或网络不稳定的环境下，标准方案会暴露两个致命隐患：

1. 删除失败：如果数据库更新成功，但随后的 Redis 删除操作因为网络抖动或服务宕机失败了，缓存中将永久残留脏数据（直到过期）。
2. 并发脏读：在数据库读写分离架构中，主从同步存在延迟。如果线程 A 更新主库并删除了缓存，线程 B 在从库尚未同步完成时读取了旧数据并回填到缓存，那么缓存中又变回了脏数据。

本章节将深入探讨两种进阶方案来填补这些漏洞：一种是面试中常见的 “延时双删”策略，另一种是工业界更推崇的 “基于 Binlog 的异步删除”架构。我们将分析它们分别如何通过牺牲一定的吞吐量或增加架构复杂度，来换取更高的一致性保障。

方案一：延时双删策略 (Delayed Double Delete)

在面试中，当被问及“先删缓存还是先更库”引发的并发脏读问题时，“延时双删”往往是候选人最先想到的进阶回答。它在标准 Cache Aside 模式的基础上增加了一步“回马枪”式的操作，试图通过时间差来抹平并发导致的不一致。

核心流程与设计意图

延时双删的核心在于“双删”：在更新数据库的前后，各执行一次缓存删除操作。其标准执行步骤如下：

1. 删除缓存：先清除旧数据，防止读请求直接命中过期缓存。
2. 更新数据库：执行业务逻辑，提交事务。
3. 休眠（Sleep T）：线程挂起或异步延时一段时间。
4. 再次删除缓存：清理掉在第 2、3 步期间，因并发读请求可能写入缓存的脏数据。

为什么要“休眠”？
这个策略主要为了解决一种特定的竞态条件：在线程 A 更新数据库期间，线程 B 发现缓存缺失，去读取数据库（此时可能读到旧值），并将旧值写入缓存。如果没有第二次删除，这个“脏旧值”将长期驻留。休眠的时间 T，本质上是为了覆盖“数据库主从同步延迟” + “并发读请求的执行耗时”，确保在第二次删除时，所有并发线程的脏数据写入动作都已经完成。

深度解析：面试中的“高分陷阱”

虽然延时双删在逻辑上看似闭环，但在生产环境落地时，它往往是一个“看起来很美”的方案。在面试中，如果你能主动指出以下痛点，会比单纯背诵流程更能体现工程经验。

1. 吞吐量的隐形杀手
最直观的问题在于 Thread.sleep(T)。如果在核心业务的主线程中执行休眠，即便只是几十毫秒，也会导致接口响应时间（RT）飙升，严重拖累系统吞吐量。

优化思路：通常建议将“第二次删除”异步化。例如，使用额外的线程池或简单的延时队列来执行最后一步删除，避免阻塞主业务流程。

2. 难以量化的“魔法时间 T”
参数 T 的设置是一门玄学。正如华为云技术博客所指出的，这个时间需要大于“主从同步最大延迟 + 读请求耗时 + 网络抖动缓冲”。

• 时间太短：无法覆盖主从延迟或慢查询，脏数据依然会写入缓存，策略失效。
• 时间太长：虽然安全性提高，但如果是同步休眠，性能代价过大；如果是异步删除，则意味着数据不一致的窗口期被拉长。
  在实际生产中，数据库的主从延迟是动态波动的（例如遇到大事务或网络抖动），静态配置的 T 很难应对所有极端情况。

3. 第二次删除失败的风险
如果步骤 4 执行失败（例如 Redis 网络抖动），那么缓存中依然会残留脏数据。为了保证最终一致性，你往往需要引入重试机制。一旦引入了重试，逻辑的复杂度就会迅速上升——你可能需要把删除动作扔到消息队列中去保证“至少消费一次”。

面试官视角：何时使用？

延时双删并非一无是处，它是一个低成本的折中方案。

• 适用场景：读多写少、并发量中等、对一致性容忍度较高（能接受秒级脏读）的业务，如用户资料更新、非核心配置项。
• 不适用场景：秒杀库存扣减、金融账户余额变动等对一致性要求极高或高频写入的场景。

当你在面试中抛出这个方案时，请务必补上一句：“这是一个在没有引入复杂中间件（如 Canal + MQ）之前的权衡之策，它用极小的代码改动解决了 99% 的并发脏读，但无法提供 100% 的一致性保证。”

方案二：基于 Binlog 的异步删除 (Canal + MQ)

如果面试官追问：“如果业务代码不能容忍任何 Thread.sleep 带来的阻塞，或者我们需要将缓存维护逻辑与业务逻辑完全解耦，该怎么办？” 此时，你需要抛出工业级的重型武器：基于 Binlog 的异步删除模式。

这是一种最终一致性（Eventual Consistency）的架构方案，它将“数据更新”与“缓存淘汰”在物理层面完全剥离，是目前大厂处理高并发、核心链路（如订单、账务）的主流选择。

1. 核心架构流程

在这个方案中，业务代码只负责“更新数据库”，完全不需要编写任何操作 Redis 的代码。整个流程由基础设施自动驱动：

1. 应用层更新：业务服务（App）执行 SQL 更新 MySQL 数据库，事务提交即结束。
2. 日志记录：MySQL 自动将变更写入 Binlog 日志。
3. 日志捕获：中间件（如阿里开源的 Canal）伪装成 MySQL Slave，实时订阅并解析 Binlog。
4. 消息投递：Canal 将解析后的变更数据（Table, Key, Value）投递到消息队列（MQ，如 Kafka 或 RocketMQ）。
5. 异步消费：专门的消费者服务（Consumer）监听 MQ，解析消息并执行 Redis.del(key)。

2. 为什么这是面试中的“满分答案”？

相比于“延时双删”，这种方案在架构层面解决了三个痛点：

• 完全解耦（Decoupling）：
  业务代码不需要关心缓存是否存在，也不需要引入 Redis 客户端依赖。后续如果缓存策略变更（例如从 Redis 换成其他存储，或 Key 规则变化），只需要修改下游的 Consumer 代码，上游业务零感知。
• 流量削峰与无损性能：
  由于移除了业务线程中的 Redis IO 和 Sleep 等待，接口响应时间（RT）仅取决于数据库写操作，写性能达到物理极限。
• 可靠性兜底（Reliability）：
  这是该方案最大的杀手锏。如果 Redis 宕机或网络抖动导致删除失败，利用 MQ 的 ACK 机制（Acknowledgment），消费者可以拒绝确认消息。MQ 会自动进行重试，直到删除成功为止。这从根本上解决了“删除失败导致脏数据驻留”的问题。

3. 落地实现的“深水区”细节

在面试中，仅仅画出流程图是不够的，你还需要展示对落地细节的把控，以证明你具备 实际工程经验：

• Binlog 格式要求：
  必须将 MySQL 的 binlog_format 设置为 ROW 模式。只有 ROW 模式才能记录每一行数据的变更细节，避免 STATEMENT 模式在某些特定 SQL（如 now() 函数）下产生的不一致。
• 消息消费的幂等性：
  MQ 可能会重复投递消息，或者 Binlog 产生重复事件。Consumer 端的删除操作（del）天然是幂等的，但如果涉及复杂的缓存重建逻辑，需要额外注意防重。
• 多级缓存的清理：
  如果架构中还包含本地缓存（如 Caffeine），可以通过 MQ 广播模式（Broadcast）通知所有应用节点清理本地缓存，这是 Binlog 方案相对于简单双删的另一个扩展优势。

4. 架构权衡：引入复杂度的代价

没有任何方案是完美的。在推荐该方案时，必须以此结尾，展示你的架构视野：

“虽然基于 Binlog 的方案在一致性和性能上表现优异，但它引入了基础设施的复杂度。我们需要维护 Canal 集群、MQ 集群以及专门的消费服务。对于中小团队或非核心业务，这可能属于‘过度设计’。因此，选择该方案的前提是：业务具备高并发写诉求，且团队具备完善的中间件运维能力。”

通过这种“先扬后抑”的回答，你不仅解决了技术问题，还体现了对技术成本（ROI）的敏感度，这正是高级工程师的核心素质。

终极手段：分布式锁与强一致性

在绝大多数面试场景中，我们讨论的“缓存一致性”通常是指最终一致性（Eventual Consistency）。面试官可能会追问：“如果我的业务要求强一致性，绝不允许读到脏数据，比如涉及金钱交易或极度敏感的库存扣减，该怎么办？”

这时候，你需要拿出“终极手段”：放弃部分并发性能，引入分布式锁。

什么时候必须使用强一致性？

当业务场景对数据的准确性要求高于并发性能时，普通的“延时双删”或“异步消息”方案就不够用了。典型的场景包括：

• 金融账户余额：用户充值或转账后，查询余额必须立即显示最新金额，不能有毫秒级的延迟。
• 电商秒杀库存：虽然秒杀通常在Redis中扣减，但在某些严格的库存同步场景下，必须保证数据库与缓存的绝对一致，防止超卖。
• 配置中心元数据：某些系统全局配置修改后，所有节点必须立即生效，不能容忍旧配置残留。

解决方案：读写锁 (Read-Write Lock)

要实现缓存与数据库的强一致性，最直接的方法是将并行操作“串行化”。但如果对所有请求都加互斥锁（Mutex），系统的吞吐量将直接跌入谷底。因此，更成熟的方案是使用分布式读写锁。

在 Java 生态中，最常用的实现是 Redisson 的 RReadWriteLock。其核心逻辑如下：

1. 读数据（Read Lock）：

• • 当多个线程同时读取数据时，它们会申请读锁。
  • 读锁之间是共享的，这意味着如果当前没有写操作，成千上万个读请求可以并发执行，不会阻塞。
  • 如果此时有写锁存在，读请求会被阻塞，直到写锁释放。

1. 写数据（Write Lock）：

• • 当需要更新数据库时，线程申请写锁。
  • 写锁是排他的。一旦加上写锁，其他的读请求和写请求都会被阻塞，直到当前线程完成“更新数据库 + 更新/删除缓存”的所有操作。

通过这种机制，我们强制让“读”和“写”操作互斥，从而彻底消除了“先更后删”或“先删后更”中存在的并发时间窗口。

参考资料：关于具体的实现细节与一致性保障，可以参考 Redisson 和 SpringCache 实现 Redis 缓存分布式锁与数据一致性 中的相关实践。

致命代价：并发性能的崩塌

虽然分布式锁解决了数据不一致的问题，但它违背了引入缓存的初衷——高性能。

• 性能瓶颈：一旦加上写锁，所有的读请求都会被阻塞。在高并发场景下（例如热点 Key 更新），这会导致请求队列瞬间积压，响应时间（RT）从几毫秒飙升至几百毫秒甚至超时。
• 系统复杂度：引入分布式锁增加了系统的脆弱性。你需要处理锁的超时机制（Watch Dog）、死锁检测以及 Redis 集群故障时的锁安全性（如 Redlock 算法 解决的主从切换锁丢失问题）。

面试官眼中的“红线”

在回答这个问题时，态度必须谨慎且坚定。不要轻易建议使用分布式锁，除非你明确指出了它的代价。

你可以这样总结：

“使用读写锁可以保证 100% 的强一致性，但这是以牺牲并发能力为代价的。如果业务真的需要强一致性，我们首先应该反思：这个数据真的需要缓存吗？ 直接查数据库是否更合适？只有在‘读多写少’且对一致性有硬性要求的极端场景下，才考虑使用分布式读写锁。”

这不仅展示了你对技术的掌握，更体现了架构设计中的权衡思维（Trade-off）。

决策清单：不同业务场景该怎么选？

在面试中，当被问到“应该选择哪种方案”时，最忌讳的是直接抛出一个“最佳实践”。架构设计没有银弹，只有权衡（Trade-off）。为了展现你的技术深度，建议从一致性级别、实现复杂度和性能影响三个维度，结合具体的业务场景给出决策路径。

核心策略对比总览

以下是四种主流策略的详细对比，你可以将其作为面试时的“思维导图”：

选型决策漏斗

在实际落地或回答面试题时，可以遵循以下“三步走”的决策启发式规则（Heuristics）：

1. 默认首选：Cache Aside Pattern

口诀： “读多写少用标准，容忍秒级不一致。”
对于大多数互联网应用（如新闻列表、商品详情页），先更新数据库，再删除缓存 是性价比最高的选择。虽然理论上存在“读操作在写操作删除缓存前读取旧数据”的微小窗口，但在实际网络环境下，这种概率极低。正如部分技术博客所言，如果团队规模小、没有专门的 DBA 或 MQ 基础设施，这就是最稳妥的方案。

2. 进阶场景：引入异步补偿 (Async Binlog)

口诀： “高并发写怕脏读，解耦重试保最终。”
当业务面临 高并发写入 或者 数据敏感度较高（不允许长时间脏数据）时，简单的 Cache Aside 可能因为删除失败导致数据长期不一致。此时，利用 Canal 监听 Binlog 投递到消息队列 是最佳实践。

• 优势： 即使 Redis 宕机或网络抖动，消息队列的重试机制也能保证缓存最终被删除（At-least-once）。
• 适用： 已有完善中间件基础设施的中大型项目。

3. 极端场景：放弃缓存或使用锁

口诀： “涉及钱财别侥幸，要么强锁要么查库。”
如果业务场景是 用户余额、转账、实时库存扣减，且业务方要求“绝对不能看到旧数据”：

• 方案 A (推荐)： 直接放弃缓存，所有读写直连数据库（利用数据库的 MVCC 和行锁保证一致性）。
• 方案 B (妥协)： 如果必须用缓存抗读压力，则必须使用 分布式读写锁 (ReadWriteLock)。虽然这会牺牲并发性能，但能通过串行化强制保证一致性。

面试高分话术总结

“在我的经验中，脱离业务场景谈一致性都是耍流氓。

对于绝大多数读多写少的场景，我会直接采用 Cache Aside（先更库后删存），配合设置合理的过期时间作为兜底，因为简单且高效。

如果是对一致性要求较高的核心链路，比如千万级流量的商品中心，我会引入 Binlog + MQ 异步删除，利用消息队列的重试机制来消除‘删除失败’的风险，实现高可靠的最终一致性。

只有在涉及资金核算等零容忍场景下，我才会考虑使用分布式锁，或者干脆去掉缓存直接查库，毕竟在这种场景下，数据的准确性远比响应速度重要。”