cache aside 是主流工程实践，采用先更新 mysql 再删除 redis 缓存的策略，配合延迟双删、异步重试与 ttl 兜底，将不一致窗口压缩至毫秒级，兼顾性能与最终一致性。
Cache Aside 是携程等一线大厂在 MySQL + Redis 双写场景中实际落地的主流策略，不是“理论上可行”，而是经过高并发压测验证的工程选择。它不追求强一致，但通过“先更新 MySQL，再删除 Redis 缓存”+ 补偿机制，把不一致窗口压缩到毫秒级，并规避了绝大多数脏数据风险。
为什么不能用 updateRedis() 替代 delRedis()
很多人直觉认为“更新缓存 = 数据最新”，但这是高并发下最危险的假设：
- 两个线程 A、B 同时更新同一商品库存：A 写 DB 成功（设为 99），B 写 DB 成功（设为 98），但 B 的
updateRedis(98)先执行，A 的updateRedis(99)后执行 → 缓存最终是 99，而 DB 是 98 - 缓存值需计算（如拼接 JSON、查关联表），每次写 DB 都触发全量计算，浪费 CPU 且拖慢写路径
- 如果该 key 很少被读，
updateRedis()就是纯冗余操作
而 delRedis() 是幂等、轻量、无状态的操作，删完就完事，后续读请求自然触发回源加载——这才是以读换写、用空间换时间的真实逻辑。
DEL 后 MySQL 更新失败怎么办？靠重试 + 状态标记
单纯 delRedis() + updateMySQL() 串行调用，一旦 MySQL 更新失败（如唯一键冲突、主从延迟超时），就会导致 Redis 为空、DB 未变，下次读直接穿透，但用户看到的是“数据消失”。真实做法是：
- 在事务内完成 MySQL 更新；仅当事务 commit 成功后，才执行
delRedis() - 若
delRedis()失败（网络抖动、Redis 拒绝连接），立即记录失败 key 到本地队列或 DB 表（如cache_delete_fail），并启动异步重试（最多 3 次，间隔 100ms/500ms/1s） - 关键字段加
updated_at时间戳，配合 Redis 设置短 TTL（如 60s），即使重试全部失败，也能兜底过期回源
高并发下“先更 DB 后删缓存”仍会脏读？用延迟双删压住窗口
经典竞态：A 更新 DB 后还没删缓存，B 此时读缓存 miss → 查 DB（读到旧快照）→ 回填缓存 → A 才删缓存。结果缓存里是旧值，且长期存在（尤其没设 TTL 时）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
携程内部实践是“延迟双删”：
- 第一步：
delRedis(key) - 第二步：
updateMySQL(...)（含事务 commit） - 第三步：
Thread.sleep(100)或更稳妥地用TimeUnit.MILLISECONDS.sleep(100) - 第四步：
delRedis(key)（再次删除）
这个 100ms 不是拍脑袋：它略大于主从同步延迟 P99（通常 delRedis() 就能把它干掉。线上实测可将脏读概率从 ~0.3% 压到
真正难啃的骨头：跨服务、跨库、非幂等写操作
上面所有方案都默认一个前提：更新操作是单库、单表、幂等的。但携程订单系统里常见：
- 一个“支付成功”事件要更新 MySQL 订单表、更新 Redis 库存、通知风控服务、发 Kafka 日志 —— 这已经超出双写范畴，必须上 Saga 或可靠消息
- “用户修改收货地址”涉及分库分表，MySQL 更新成功但某分片路由失败，此时删 Redis 就会漏掉部分缓存
- 没有主键的宽表更新（如统计汇总表），无法用 key 精准定位缓存，只能粗粒度
delRedis("order_summary_*")，极易误伤
这些场景下，Cache Aside 不是银弹。得配合 Binlog 解析（如 Canal）+ 消息队列（如 Kafka）做最终一致性同步，或者对热点 key 加分布式锁（如 Redlock）保原子性——但锁本身又带来性能折损和死锁风险。工程落地永远是在“一致性、性能、复杂度”三角里找动态平衡点。
