📌关键词：Redis 、缓存、数据库架构、高并发、一致性
大家好，我是数据库小学妹👋！
前面几期，我们讲了分库分表和读写分离，把数据库从“单打独斗”变成了“千军万马”。但在面对秒杀、抢购这种瞬时百万级的流量，光靠数据库集群依然扛不住。这时候，我们需要在应用和数据库之间，加一个速度极快的“临时仓库”——Redis缓存。
今天，我们就来聊一个后端开发绕不开的灵魂拷问：数据库扛不住高并发时，Redis缓存怎么用？数据更新后，缓存数据不一致怎么办？ 这背后就是经典的 “双写一致性” 难题。别慌，小学妹带你拆解4种主流方案，并融合实战避坑经验，让你的系统既快又稳！
一、 为什么需要Redis缓存？
当系统面临高并发（如秒杀、热点新闻、用户会话）时，数据库往往是性能瓶颈。Redis作为内存数据库，能将数据从磁盘搬到内存，访问速度从毫秒级降到微秒级，堪称“涡轮增压”。典型场景：
● 读多写少：商品详情、用户配置、会话信息等。
● 全局锁：秒杀扣库存、订单防重（用Redisson分布式锁，自动续期防死锁）。
● 计数器/限流：PV统计、接口频率控制（如INCR命令+过期时间）。
但缓存引入后，数据同步成为新痛点：更新数据库后，Redis里的旧数据怎么办？
二、 双写一致性的挑战：一个并发场景引发的“惨案”
假设业务场景：用户充值100元，系统需更新数据库余额并同步到Redis缓存。如果操作顺序或并发控制不当，可能触发以下“惨案”：
- 线程A：更新数据库余额为200元。
- 线程B（同时）：查询缓存，发现无数据，从数据库读到旧值100元，并写入缓存。
- 线程A：删除缓存（或更新失败）。
- 结果：数据库是200元，Redis缓存却是100元！用户看到的是“假余额”。
核心矛盾：数据库和Redis是两个系统，无法原子化同步。如何设计更新策略，确保数据最终一致？
三、4种双写一致性方案：原理、利弊与实战建议
🏆方案1：先删缓存，再更新数据库（慎用！）
① 删Redis缓存 → ② 更新MySQL数据库
风险：若①后②前发生读请求，会读到旧数据并写回缓存，导致永久不一致（除非缓存过期）。几乎不推荐，除非对一致性无要求。
🏆方案2：先更新数据库，再删缓存（推荐！⭐⭐⭐⭐⭐）
① 更新MySQL数据库 → ② 删除Redis缓存
原理：删除缓存是“瞬时”操作，即使①和②之间有短暂不一致窗口（读请求读到旧数据），后续请求会重建正确缓存。适合90%互联网场景，如用户资料、商品属性等。
避坑指南：
- 删缓存失败：用消息队列（MQ）异步重试，确保最终删除。
- 兜底策略：给缓存设置合理过期时间（如5分钟），防止删缓存失败时数据长期不一致。
代码示例（Java + Redisson）：
@Transactional
public void updateBalance(Long userId, int newBalance) {
// 1. 更新数据库
balanceDao.update(userId, newBalance);
// 2. 删缓存（用Redisson确保高并发安全）
RLock lock = redisson.getLock("balance:lock:" + userId);
try {
if (lock.tryLock(3, TimeUnit.SECONDS)) {
redisTemplate.delete("balance:" + userId);
}
} finally {
lock.unlock();
}
}
🏆方案3：延时双删（进阶版）
① 删Redis缓存 → ② 更新MySQL数据库 → ③ 延时（如500ms）→ ④ 再删Redis缓存
目的：解决“先删缓存”方案的并发问题。延时时间需大于“读数据库+写缓存”的耗时。
利弊：
- 优点：进一步降低不一致概率。
- 缺点：写性能降低，需预估延时时间（可用延时队列替代
Thread.sleep()）。
适用场景：对一致性要求高但能容忍写延迟，如库存系统。
🏆方案4：订阅Binlog，异步同步（终极解法）
MySQL → Binlog → Canal/Debezium → 消息队列（MQ） → 消费者删除/更新Redis缓存
原理：用工具（如阿里开源的Canal）监听数据库的binlog变更，实时触发缓存同步。
优势：
- 最终一致性强：异步解耦，不影响主业务。
- 可靠性高：MQ自带重试机制，确保同步成功。
缺点：架构复杂，需部署额外组件（Canal、MQ）。
适用场景：高并发、数据一致性要求极高的核心系统（如订单、支付）。
四、实战避坑指南：缓存的“三座大山”
🚀 缓存雪崩 (Cache Avalanche)
- 现象：Redis里大量的数据在同一时间过期，瞬间所有请求都打到了数据库，数据库直接被压垮。
- 解决：
- 随机过期时间：给缓存过期时间加个随机值（比如 5分钟 + 随机0-300秒），让过期时间分散。
- 多级缓存：本地缓存 (Caffeine) + Redis，双重保险。
🚀 缓存击穿 (Cache Breakdown)
- 现象：某个热点Key（比如爆款商品）过期的瞬间，无数并发请求同时涌入，直接穿透到数据库。
- 解决：
- 互斥锁 (Mutex Lock)：第一个查数据库的线程加锁，查完更新缓存，其他线程等一下再去缓存拿。
- 热点永不过期：对极热点数据设置永不过期，后台异步更新。
🚀 缓存穿透 (Cache Penetration)
- 现象：有人恶意查询不存在的数据（比如 id=-1），缓存没有，数据库也没有，每次都要查库，把库查崩了。
- 解决：
- 布隆过滤器 (Bloom Filter)：在缓存前加一道“安检门”，如果数据肯定不存在，直接拦截，不查库。
- 缓存空值：数据库查不到，也在Redis里存个
null，并设置短过期时间（比如1分钟）。
五、总结：
缓存是高并发架构的“涡轮增压器”。
- 读写策略：记住 Cache Aside 模式，先更库，后删缓。
- 三大坑：雪崩（随机过期）、击穿（加锁）、穿透（布隆过滤器/空值）。
- 适用性：读多写少的场景最适合加缓存。
掌握了缓存，你就真正具备了设计亿级流量系统的能力雏形！
👋 我是数据库小学妹，你在项目中踩过缓存不一致的坑吗？聊聊你的解决方案或困惑吧！
本文方案基于常见实践，不同业务场景需权衡取舍。订阅binlog推荐使用Canal或Debezium。
