先更新数据库再删缓存是当前生产环境最常用、风险相对可控的方案，因其轻量安全、符合cache-aside设计前提，但需通过mq重试、幂等删除和监控兜底保障删缓存动作的可达性与最终一致性。
先更新数据库再删缓存 是当前生产环境最常用、风险相对可控的方案，但不是“一设就稳”，关键在如何落地删缓存这一步——它容易失败、容易被并发绕过、容易因网络抖动静默丢弃。
为什么选「删缓存」而不是「更新缓存」
对 Redis Hash 类型（比如用 HSET user:1001 name "Alice" age 28 存用户信息），更新缓存意味着要从 DB 查全量字段再写入，而删缓存只需 DEL user:1001 或 HDEL user:1001 name。实际业务中：
- 多数写操作只改部分字段（如仅更新用户头像），没必要重载整个 Hash
- DB 字段可能新增或逻辑删除，缓存字段结构滞后时，
HSET会覆盖错或漏写 - 并发写同一 Hash 的多个字段时，
HSET非原子，可能相互覆盖（除非用 Lua 封装）
所以删缓存更轻量、更安全，代价是下次读触发回源重建 —— 这正是 Cache-Aside 模式的设计前提。
删缓存失败怎么办：必须加补偿机制
直接调用 redis.del("user:1001") 后不检查返回值，等于裸奔。常见失败场景包括：Redis 网络超时、集群节点临时失联、客户端连接池耗尽。此时 DB 已更新，缓存却残留旧数据，不一致即发生。
正确做法是把「删缓存」变成一个可重试、可观测的操作：
- 更新 DB 成功后，同步尝试删缓存；若失败（抛异常或返回 0），立即发一条 MQ 消息，内容为
{"key": "user:1001", "type": "hash"} - 消费者监听该 topic，执行
DEL或FLUSHDB（按需）；失败则指数退避重试（如 1s/3s/10s/30s） - 超过 5 次仍失败，写入告警表并触发企业微信/钉钉告警，人工介入
注意：MQ 消息体里不要放具体字段值，只传 key 和类型，避免敏感信息落盘或被误消费。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
Hash 字段级删除 vs 全 key 删除
如果业务只更新用户邮箱，而你删了整个 user:1001，下次读会把全部字段从 DB 拉一遍 —— 浪费 IO，还可能因部分字段未查出导致 Hash 缺失。更精细的做法是：
- 明确哪些字段可独立更新（如
email、phone），对应使用HDEL user:1001 email - 字段间有强依赖（如
status和last_login_time必须一起刷新），那就删整个 key - 用统一的缓存 Key 命名规范，例如
user:1001:profile（主信息）、user:1001:stats（统计），按域拆分，缩小删除粒度
别为了“看起来精确”而给每个字段建单独 Hash key（如 user:1001:email），那会极大增加 key 数量和内存碎片，得不偿失。
延迟双删真的必要吗
所谓「删缓存 → 更新 DB → 延迟 N 秒 → 再删一次」，初衷是防止线程 A 删缓存后、DB 还没提交，线程 B 就回源写入旧值。但在真实系统中：
- 延迟时间难设定：太短（如 100ms）挡不住慢 SQL；太长（如 1s）又拖累主流程
- MySQL 默认 RR 隔离级别下，B 读到的其实是 A 事务前的快照，即使 A 还没 commit，B 也读不到“将要提交”的新值 —— 所以该问题在多数 OLTP 场景中实际不成立
- 真正需要延迟双删的，是那些显式开启
READ-COMMITTED且存在长事务的业务（如报表导出），非常态
除非你明确观察到「更新后立刻读到旧值」且确认是回源重建导致，否则不要加延迟双删。它增加复杂度，却不解决主流问题。
最终一致性不是靠某一行代码保证的，而是靠删缓存动作的**可达性**（MQ 补偿）、**幂等性**（DEL 多次无副作用）、以及**监控兜底**（缓存命中率突降、MQ 积压告警）。别迷信“删完就完事”，要盯住删的动作有没有真正抵达 Redis。
