在Java后端面试中，面试题：如何保证数据库和缓存的一致性是高并发场景下的核心考察点——它不仅能考察求职者对缓存架构的理解深度，更能看穿你平衡“数据一致性、系统性能、架构复杂度”三者的能力。鳄鱼java社区的面试跟踪数据显示，能结合业务场景给出分级落地方案的求职者，高并发岗位通过率比只会背“先更库再删缓存”的高75%。
一、先拆解：面试题背后的考察点与一致性本质
很多求职者开口就说“先更新数据库，再删除缓存”，但这完全没触及面试官的考察点。这个面试题的核心是要你先明确两个关键：
1. 一致性的分级：数据库和缓存的一致性不是“非黑即白”，需分为强一致性（数据必须实时一致，如金融转账、库存扣减）和最终一致性（允许短暂不一致，但最终会同步，如电商商品详情、用户动态）；
2. 不一致的本质：数据库和缓存是两个独立存储系统，读写并发、更新顺序错误、缓存过期、网络异常都会导致数据冲突。比如先删缓存再更新数据库时，若有读请求在数据库更新前拿到旧数据并写回缓存，会产生长期脏数据。
鳄鱼java社区的架构专家强调：面试中第一个提到“一致性分级”的求职者，会立刻获得面试官的好感——这证明你不是在背模板，而是懂业务场景的开发者。
二、核心冲突：数据库和缓存不一致的4种典型场景
要给出正确解决方案，必须先识别导致不一致的根源场景：
1. 读写并发冲突：更新操作和读请求并发执行，读请求拿到旧数据并写回缓存，导致脏数据；
2. 更新顺序错误：采用“先更新缓存，再更新数据库”的顺序，若数据库更新失败，缓存会残留脏数据；
3. 缓存删除失败：网络波动导致删除缓存的请求超时，旧缓存数据长期与数据库不一致；
4. 缓存过期不合理：过期时间太短导致缓存击穿，太长导致脏数据长期存在。
三、场景化解决方案：从强一致到最终一致的落地方案
针对不同一致性要求的场景，业界有5种主流落地方案，下面结合代码和鳄鱼java实战案例讲解：
1. 基础方案：先更新数据库，再删除缓存（最终一致性）
原理：先确保数据库数据正确，再删除缓存，后续读请求会从数据库加载最新数据到缓存。这是业界默认的基础方案，因为读请求通常远快于写请求，并发导致脏数据的概率极低。
示例代码（Spring Boot+Redis）：
@Autowired private StringRedisTemplate redisTemplate;@Transactional(rollbackFor = Exception.class) public void updateProduct(Product product) { // 1. 更新数据库 productMapper.updateById(product); // 2. 删除缓存 String cacheKey = "product:" + product.getId(); redisTemplate.delete(cacheKey); }
适用场景：最终一致性场景，如电商商品详情、用户个人资料，允许短暂不一致；
优化点：若要进一步降低脏数据概率，可添加延迟双删——删除缓存后，延迟100-500ms再删一次缓存，覆盖读请求写回缓存的时间窗口。
2. 强一致性方案：分布式锁+读写串行化
原理：用Redis的setnx实现分布式锁，保证同一时间只有一个线程更新数据，读写操作串行化，彻底避免并发冲突。适合强一致性场景，如金融转账、库存扣减，必须保证数据实时一致。
示例代码：
public void deductStock(String productId, int num) {
String lockKey = "lock:stock:" + productId;
try {
// 1. 获取分布式锁，过期时间30s，避免死锁
Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS);
if (!Boolean.TRUE.equals(locked)) {
throw new RuntimeException("当前操作繁忙，请稍后再试");
}
// 2. 先更新数据库
int result = stockMapper.deduct(productId, num);
if (result == 0) {
throw new RuntimeException("库存不足");
}
// 3. 删除缓存
redisTemplate.delete("stock:" + productId);
} finally {
// 4. 释放锁
redisTemplate.delete(lockKey);
}
}
鳄鱼java社区的某金融项目采用该方案后，库存扣减的一致性达到100%，彻底解决了转账场景的脏数据问题。
3. 高性能最终一致：binlog+Canal异步同步缓存
原理：通过Canal模拟MySQL Slave节点获取binlog，解析后异步更新Redis缓存，彻底避免业务代码与缓存操作耦合，性能高且一致性可达99.9%。适合高并发最终一致性场景，如电商订单、商品评价。
架构流程：1. MySQL写入binlog；2. Canal模拟Slave节点同步binlog；3. Canal解析binlog后发送到Kafka/RabbitMQ；4. 消费端监听消息，更新Redis缓存。
鳄鱼java社区的某电商项目用该方案后，缓存同步延迟从1s降至100ms，一致性问题减少99%，业务代码的缓存操作代码减少了80%。
4. 兜底方案：缓存过期时间+主动预热
无论采用哪种方案，都必须给缓存设置过期时间作为兜底——即使缓存更新失败，过期时间到了也会自动加载最新数据。同时，对热点数据进行主动预热，避免缓存击穿导致的不一致。比如用定时任务每天凌晨加载热门商品数据到缓存，避免峰值时段的缓存击穿。
四、面试应答技巧：怎么组织语言拿满分？
回答面试题：如何保证数据库和缓存的一致性时，必须遵循“一致性分级→场景选型→方案细节→权衡分析”的逻辑，示例应答：
“面试官您好，保证数据库和缓存的一致性要分场景来看：
1. 强一致性场景：比如金融转账、库存扣减，我会用分布式锁+先更库再删缓存，通过串行化读写保证数据实时一致；
2. 最终一致性场景：比如电商商品详情，我会优先用binlog+Canal异步同步，解耦业务与缓存，性能更高；若场景简单，用先更库再删缓存+延迟双删即可；
3. 无论哪种方案，都会加缓存过期时间作为兜底，保证即使同步失败，最终也能一致。我在鳄鱼java社区的电商实战项目中，用Canal解决了商品缓存一致性问题，将脏数据率从0.5%降至0.01%。”
五、避坑指南：面试中不能踩的雷区
1. 不要说“先更新缓存再更新数据库”：并发下会导致永久脏数据，比如两个写请求，A更新缓存为1，B更新缓存为2，但A的数据库更新失败，此时缓存是2，数据库是旧数据；
2. 不要忽略缓存删除失败的情况：要加重试机制，比如用消息队列异步删缓存，删除失败后重试3次，避免旧缓存长期残留；
3. 不要混淆强一致和最终一致：金融场景不能用Canal，电商场景不用分布式锁，要根据业务优先级平衡性能和一致性。
六、总结与思考
回答面试题：如何保证数据库
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
