后端面试必备：Redis中如何保证缓存与数据库的数据一致性

Redis面试题 - Redis中如何保证缓存与数据库的数据一致性?

回答重点

缓存和数据库的同步可以通过以下几种方式：

• 先更新缓存，再更新数据库
• 先更新数据库存，再更新缓存
• 先删除缓存，再更新数据库，后续等查询把数据库的数据回种到缓存中
• 先更新数据库，再删除缓存，后续等查询把数据库的数据回种到缓存中
• 缓存双删策略。更新数据库之前，删除一次缓存；更新完数据库后，再进行一次延迟删除
• 使用Binlog异步更新缓存，监听数据库的Binlog变化，通过异步方式更新Redis缓存

以上就是实现数据库与缓存一致性的六种方式，这里前面三种都不太推荐使用，后面三种的话其主要根据实际场景：

• 如果是要考虑实时一致性的话，先写MySQL，再删除Redis应该是较为优的方案，虽然短期内数据可能不一致，不过其能尽量保证数据的一致性。
• 如果考虑最终一致性的话，推荐的是使用binlog+消息队列的方式，这个方案其有重试和顺序消费，能够最大限度地保证缓存与数据库的最终一致性。

---

引言

在现代Web应用中，Redis作为高性能的缓存层被广泛使用，但随之而来的是缓存与数据库数据一致性的挑战。本文将深入探讨Redis缓存与数据库一致性问题，分析常见解决方案，并提供实践建议。

一、数据一致性问题的本质

缓存与数据库的一致性问题源于两者的异步特性。当数据被修改时，我们需要确保：

1. 缓存和数据库中的数据最终保持一致
2. 在一致的过程中，系统能正确处理并发请求

是

否

客户端请求

数据在缓存中?

从缓存返回数据

从数据库读取数据

将数据写入缓存

二、常见解决方案

1. Cache Aside Pattern（旁路缓存模式）

这是最常用的模式，其核心思想是应用程序直接管理缓存和数据库的读写。

读流程：

Client Cache DB 读取数据 返回数据 读取数据 返回数据 写入数据 alt [命中缓存] [未命中] Client Cache DB

写流程：

Client Cache DB 更新数据 删除缓存 Client Cache DB

优点：

• 实现简单
• 缓存命中率高
• 能处理大部分场景

缺点：

• 存在短暂的不一致窗口
• 并发写时可能有问题

2. Read/Write Through Pattern（读写穿透模式）

在这种模式下，缓存作为主要数据源，由缓存自己负责与数据库的同步。

写流程：

客户端

写入缓存

缓存同步写入数据库

优点：

• 客户端代码简单
• 一致性更好保证

缺点：

• 实现复杂
• 缓存组件需要支持此功能

3. Write Behind Caching Pattern（异步缓存写入）

修改只写入缓存，然后异步批量写入数据库。

客户端

写入缓存

缓存定期批量写入数据库

优点：

• 写入性能极高
• 减少数据库压力

缺点：

• 数据丢失风险
• 一致性最差

三、进阶解决方案

1. 双删策略

Client Cache DB 删除缓存 更新数据 延迟再次删除缓存 Client Cache DB

适用场景：对一致性要求较高的场景

2. 基于消息队列的最终一致性

数据库更新

发送binlog变更

消息队列

缓存服务消费

更新缓存

3. 分布式锁方案

Client1 Client2 Lock DB Cache 获取锁 成功 更新数据 删除缓存 释放锁 获取锁 读取数据(未命中) 读取数据 写入缓存 释放锁 Client1 Client2 Lock DB Cache

四、实践建议

1. 根据业务场景选择策略：

   • 强一致性要求：分布式锁+双删
   • 最终一致性：Cache Aside+消息队列

2. 设置合理的过期时间：

   SET key value EX 3600  # 1小时后过期
   

3. 监控与报警：

   • 监控缓存命中率
   • 监控数据库与缓存差异

4. 降级方案：

   • 缓存故障时直接访问数据库
   • 数据库压力大时增加本地缓存

五、总结

保证Redis缓存与数据库数据一致性是一个需要权衡性能与一致性的复杂问题。没有放之四海而皆准的解决方案，最佳实践取决于您的具体业务需求、性能要求和一致性需求。

是

否

是

否

选择一致性策略

需要强一致性?

考虑分布式锁+双删

Cache Aside+消息队列

写入频繁?

考虑Write Behind

标准Cache Aside

通过理解各种模式的优缺点，结合实际业务场景，您可以构建出既高效又可靠的数据缓存系统。