缓存一致性实践：删除缓存不是银弹

缓存一致性实践：删除缓存不是银弹

一、缓存问题的本质是读写时序

缓存能显著降低数据库压力，但一致性问题也会随之出现。最常见的方案是“更新数据库后删除缓存”，它比直接更新缓存更稳妥，但并不是银弹。并发读写、删除失败、主从延迟、事务未提交、热点 key 重建，都可能导致脏数据或缓存击穿。

讨论缓存一致性时，应先明确业务容忍度。账户余额、库存、订单状态对一致性要求高；商品详情、文章统计、推荐列表可以接受短时间延迟。不同场景应该采用不同策略，而不是把所有缓存都套进同一个模板。

二、典型链路：数据库和缓存不是一个事务

sequenceDiagram participant U as 用户请求 participant S as Java 服务 participant C as Redis participant D as Database U->>S: 更新数据 S->>D: 提交事务 S->>C: 删除缓存 U->>S: 查询数据 S->>C: 未命中 S->>D: 读取新值 S->>C: 回填缓存

这个顺序看起来合理，但有几个细节需要注意。删除缓存必须发生在数据库事务提交之后，否则另一个线程可能在事务未提交时读到旧数据并回填缓存。删除失败要有重试或补偿，否则旧缓存会持续存在。高并发热点 key 回填时，要避免大量请求同时打到数据库。

还要考虑主从延迟。如果写入主库后，读请求从从库读取，再回填缓存，就可能把旧值放回 Redis。此时需要对关键读请求短时间走主库，或者使用版本号校验，避免旧数据覆盖新缓存。

三、代码实现：用事务后事件触发缓存删除

下面示例展示一种较稳妥的做法：业务事务提交后，再发布缓存删除动作。

@Transactional public void updateProduct(ProductUpdateCommand command) { Product product = productRepository.findById(command.id()) .orElseThrow(() -> new IllegalArgumentException("product not found")); product.changePrice(command.price()); productRepository.save(product); eventPublisher.publishEvent(new ProductChangedEvent(command.id())); } @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) public void onProductChanged(ProductChangedEvent event) { cacheService.delete("product:" + event.productId()); }

如果删除缓存失败，不要只打印日志。可以把失败事件写入可靠消息队列或本地补偿表，由后台任务重试。对于高价值数据，还可以加入版本号：数据库记录带version，缓存值也带version，回填前比较版本，避免旧查询覆盖新值。

热点 key 要配合互斥重建或逻辑过期。缓存失效瞬间，如果大量请求同时回源数据库，会形成击穿。可以用 Redis 分布式锁控制单线程回填，其余请求短暂等待或返回旧值。逻辑过期适合读多写少场景，用旧值换稳定性。

四、工程取舍：一致性、性能和复杂度要分层

强一致缓存通常成本很高，甚至违背缓存的初衷。大多数业务需要的是“可解释的最终一致”。例如商品价格更新后 1 秒内刷新可以接受，库存扣减则不能依赖缓存作为最终依据。把数据按一致性等级分层，才能避免过度设计。

监控也很重要。缓存命中率、删除失败次数、回源耗时、热点 key、数据库 QPS 和脏读投诉都应该被观察。没有监控时，缓存一致性问题往往只在用户反馈或对账中暴露，定位成本很高。

最后要给缓存 key 制定规范。包含业务前缀、对象 ID、版本或租户信息，避免不同模块误删、覆盖或复用同一个 key。缓存不是散落在代码里的小优化，而是系统架构的一部分。

缓存预热和缓存雪崩也需要提前规划。预热应在服务启动或扩容时主动加载高频数据，避免冷启动瞬间大量请求击穿到数据库。雪崩则来自批量 key 同时失效，可以通过随机过期时间、热点 key 永不过期配合后台刷新、或熔断机制来缓解。对于核心链路，建议准备本地缓存作兜底，在 Redis 不可用或大量 key 失效时提供降级能力。

五、总结

缓存一致性要围绕读写时序设计，更新数据库后删除缓存只是基础方案。事务后删除、失败补偿、版本校验、热点重建和一致性分层，才是生产环境更完整的答案。把业务容忍度说清楚，缓存策略才不会走偏。