先删缓存还是先更新缓存：一次商品改价错 17 分钟的缓存一致性事故与 binlog 异步删除方案

结论先行：「先更新 DB 再删缓存」不是错，错的是把删除当成一次性的、同步的、必定成功的事件。缓存一致性事故 90% 不是「顺序写反了」，而是「删缓存这一步本身会失败、会乱序、会被旧读回填」。下面用一次真实的改价事故，把机制、正确顺序、以及为什么 binlog 异步删除才是兜底，一次讲清楚。

一、现象与背景

我们商品中心：SKU 表约 800 万行，读 QPS 峰值 12 万，Redis Cluster 8 分片承载热 SKU 缓存（TTL 2h）。去年一次大促前，运营在后台把 3 个 SKU 的价格从 299 改成 199，C 端持续 17 分钟看到旧价 299，客服后台 43 条工单，差点酿成资损。更诡异的是：DB 里价格早就改对了，缓存里却是旧值，而且「手动删一次缓存就立刻对了」——这说明不是数据没写进去，而是缓存被旧读回填并长期驻留。

二、原理：丢更新窗口到底发生在哪

Cache-Aside 的经典并发时序（写线程 W、读线程 R）：

R1: 缓存 miss            W1: 更新 DB 成功
R2: 读 DB（读到旧值 A）   W2: 删除缓存
R3: 回填缓存 = 旧值 A      （缓存里现在是被 R3 回填的旧值，且 TTL 重新起算 2h）

关键不是「W2 删早了」，而是 R3 的回填发生在 W2 删除之后，把旧值 A 重新塞回了缓存。只要读线程的「读 DB + 回填」跨过了写线程的「删缓存」，旧值就会驻留。窗口大小 = 一次 DB 读 + 一次缓存 set 的耗时（我们压测约 3~5ms），但一旦命中，旧值就带 2h TTL 长期存在——这就是「错 17 分钟」的真相：不是慢，是旧值被回填后 TTL 重新起算。

「延迟双删」本质是在 W2 删缓存后，再 sleep 一段（通常 500ms~1s）补删一次，赌 R3 的回填落在两次删除之间。它能缓解，但赌的是时间，对「回填耗时不可控 + 回填后 TTL 重起算」没有根治。

三、具体做法（可复现）

1）顺序必须是「先更新 DB → 再删缓存」（不是先删）。 用 Lua 保证「删缓存失败」能被感知，而不是 fire-and-forget：

// 伪代码：写路径
db.updatePrice(skuId, 199, version);   // 先落库，带 version 自增
Boolean ok = redis.del("sku:" + skuId);
if (ok == null || !ok) {
    retryQueue.offer(new EvictJob(skuId, now + 200)); // 删除失败进重试队列，最多 3 次
}

2）真正的兜底：订阅 binlog 异步删缓存。 应用删缓存失败/进程崩溃都不怕，因为 DB 一旦提交，binlog 必然产生事件：

# Canal 实例配置（节选）
canal.instance.filter.regex: shop_db\\.sku
canal.mq.topic: sku-evict

消费端逻辑极简且幂等：

def on_binlog(event):
    if event.table == "sku" and event.type in (UPDATE, DELETE):
        redis.delete(f"sku:{event.after['id']}")   # 幂等，重复删无害

3）读路径加版本号防回填。 缓存值里带 DB 的 version，回填前比对，发现 DB 已更新就放弃回填：

SELECT id, price, version FROM sku WHERE id = ?;
-- 回填时若 version > 上次读到的 version，说明中间发生过写，丢弃本次回填

四、踩过的坑 / 反直觉之处

• 延迟双删的 sleep 是玄学。我们最初 sleep 500ms 仍偶发旧值，因为读 DB 慢查询能到 20ms+，回填 set 又叠加网络往返；把 sleep 拉到 1s 又拖累写 RT。sleep 只能覆盖「常见」窗口，覆盖不了长尾——任何基于时间的方案都是概率缓解，不是正确性保证。
• DEL 不是风险点，「删了又被旧读回填」才是。很多人盯着「删除是否原子」，其实 DEL 单 key 天然原子；真正致命的是删除之后仍有一次旧读回填。
• binlog 删除有乱序与延迟。同一 key 的两次 UPDATE 在 Canal 侧可能乱序，所以消费端要只删不写、按最新事件删，绝不能「按 binlog 值回填缓存」。
• TTL 是双刃剑：2h TTL 让旧值「错 17 分钟」而非「错几秒」，但也让正常缓存命中率维持在 99.1%。别为了消灭旧值把 TTL 调到 5s——命中率会掉到 70%，DB 直接被打穿。

五、结论与可复用清单

1. 顺序铁律：先更新 DB，再删缓存；删除失败必须可感知、可重试，禁止静默吞掉。
2. 单靠「延迟双删」不够，binlog 异步删除是正确性兜底，应用内删除是低延迟优化，两者叠加。
3. 缓存值带 version，读路径回填前比对，杜绝旧值回填。
4. 消费 binlog 时只删不写，容忍乱序，靠幂等吸收重复。
5. TTL 是命中率与一致性的权衡旋钮，别用「调小 TTL」去解决回填问题。

留一个开放问题想抛给大家：当写 QPS 和读 QPS 接近（比如秒杀改价场景），「删缓存」这条异步链路本身成为吞吐瓶颈时，你会优先把删除下沉到 DB 触发器/CDC，还是改成「写穿透 + 版本号 CAS 回填」？这两条路在 12 万读 QPS 下的代价差，我还没找到干净的压测结论，想听听你们线上的真实数字。