写完数据库后缓存更新失败该如何处理？

## 作用 数据库更新成功后，如果缓存更新失败，会导致缓存长期保留旧值，后续读请求可能命中错误数据。因此需要通过重试、异步补偿和过期机制，尽量缩小数据库与缓存的不一致时间。 ## 处理方案 - **不要直接更新缓存，优先删除缓存** - 写数据库成功后删除缓存，让后续读请求回源数据库并重新写入最新值。 - 删除缓存相比更新缓存，更适合复杂缓存场景，也能减少并发写入导致的旧值覆盖。 - **缓存删除失败时进行重试** - 捕获缓存操作异常，进行有限次数重试。 - 可将失败的 key 写入消息队列、日志或重试表，由异步消费者继续删除，避免因网络抖动或缓存服务短暂故障导致旧数据长期存在。 - **使用消息队列保证缓存操作可靠送达** - 数据库事务提交后发送“删除缓存”消息。 - 消费方删除缓存，并依赖消息队列的重试、死信等机制处理持续失败。 - 删除缓存操作应设计成幂等操作，避免重复消费产生副作用。 - **使用延迟双删降低并发读写干扰** - 可先删除缓存，再更新数据库；等待一段时间后再次删除缓存。 - 第二次删除用于处理“更新数据库期间，旧值又被读请求写回缓存”的情况。 - 延迟时间通常要覆盖一次读业务和写缓存的耗时，需要结合实际压测设置。 - **给缓存设置过期时间** - 即使所有主动删除或补偿机制都失败，缓存到期后也会自动失效。 - 这是最终一致性的兜底手段，但在过期前仍可能读到旧数据。 - **高一致性场景增加对账补偿** - 通过定时任务扫描数据库与缓存差异，或根据 binlog 订阅变更，异步删除或重建异常缓存。 - 适合对一致性要求较高、缓存失败不能仅靠过期时间兜底的场景。 ## 核心原则 - 数据库是最终数据源，缓存失效后应能从数据库重建。 - 缓存操作失败不能静默忽略，需要有重试、异步补偿和过期兜底。 - 这类方案通常只能降低不一致窗口、保证最终一致；如果要求强一致，需要引入分布式事务、读写串行化或在一致性窗口内禁用缓存等更强保障。

## 作用 数据库更新成功后，如果缓存删除或更新失败，会导致缓存中仍保留旧数据，应用可能读取到脏数据。处理目标是保证数据库与缓存最终一致，并在缓存服务异常时避免数据库被压垮。 ## 原理 - **先确认缓存服务状态** - 检查 Redis、Memcached 等缓存服务是否正常运行，是否存在宕机、拒绝连接、超时等问题。 - 查看服务日志和监控，必要时启用主从切换或故障转移。 - **检查缓存配置** - 核对应用中的缓存地址、端口、密码、连接池等配置是否正确。 - 配置变更后要同步更新应用，避免请求发到错误的缓存实例。 - **采用延时双删** - 更新数据库后先删除一次缓存。 - 如果删除失败，或担心并发请求在更新过程中把旧数据重新写入缓存，可以延迟一段时间后再次删除缓存。 - 延迟时间通常要大于一次读请求回填旧缓存所需的时间。 - **通过消息队列异步补偿** - 如果删缓存失败，可以把删除事件写入消息队列。 - 由消费者异步重试删除或更新缓存，成功后再确认消息，从而实现最终一致性。 - **设置合理的过期时间** - 缓存必须设置 TTL，作为最后的兜底手段。 - 即使缓存更新失败，过期后也会重新从数据库加载最新数据。 - 热点数据可适当延长缓存时间，但要避免大量 key 同时过期。 - **使用持久化降低故障影响** - 可开启 Redis 的 RDB 或 AOF 持久化，减少缓存服务重启后的数据丢失。 - **故障时降级或熔断** - 缓存服务不可用时，可以暂时访问数据库，但要配合限流、熔断和降级，避免大量请求直接打垮数据库。 - 必要时返回默认数据、旧数据或“系统繁忙”等提示。 - **使用多级缓存** - Redis 故障时，可以使用本地缓存作为二级缓存兜底。 - 同时通过负载均衡分散数据库压力，降低缓存雪崩风险。