分布式缓存一致性没有万能解法，核心思路是放弃强一致拥抱最终一致，用Cache Aside模式配合延迟双删或消息队列，把不一致窗口压缩到业务可接受的范围。
分布式缓存一致性 解决方案：先搞清楚你面对的是哪种不一致
在动手解决之前,得先认清一个事实：绝大多数业务系统根本不需要强一致，缓存层存在的意义是挡在数据库前面扛读流量，你要求它和数据库时刻保持一致，等于让一个高速服务等一个慢速服务，本末倒置。
先看几种常见的不一致场景：
- 更新数据库后删除缓存失败，旧数据残留在缓存里，后续读请求全部命中脏数据
- 并发读写竞争，一个线程写库一个线程写缓存，后写的反而先落，缓存里存了旧值
- 主从延迟叠加缓存更新，写主库后删缓存，但从库还没同步完，下一次读把从库的旧值又塞回缓存
这三类场景覆盖了线上绝大多数缓存不一致问题,行业共识认为，处理缓存一致性的第一原则是：先写数据库，再处理缓存，顺序反了会引入更复杂的问题。
缓存一致性 保证方案的经典解法
Cache Aside模式：最常用的基础操作
Cache Aside（旁路缓存）是所有缓存方案的基石，它的操作路径非常明确：
- 读请求优先查缓存,命中直接返回
- 未命中则查数据库,把结果写回缓存，再返回
- 写请求先更新数据库,然后删除缓存中的对应key
第三步删除缓存而不是更新缓存,这个细节很多人踩过坑，更新缓存意味着每次写操作都要多一次写缓存的动作，而且并发写的情况下，后写缓存的不一定是数据库的最新值，删除则不存在这个问题，下次读请求会自然触发缓存重建。
延迟双删：对付并发读写的实用招数
Cache Aside模式有个明显漏洞：写库后立即删缓存，但这期间如果正好有一个读请求把旧数据写回了缓存，删除操作就白做了。
延迟双删的处理方式是：
- 第一次删除：写库成功后立刻删缓存
- 第二次删除：等待几百毫秒后再删一次，确保覆盖掉并发读请求写回的旧值
这个等待时间怎么定？业内专家指出，延迟时间要大于一次读请求的完成时长，经验值在500毫秒到1秒之间，如果业务读链路特别慢，需要适当调大。
延迟双删解决的是短时间窗口内的并发问题,但第二个删除动作本身也可能失败，所以它仍然不是绝对可靠，只是把不一致窗口压缩到了毫秒级。
redis缓存与数据库一致性：消息队列方案的取舍
延迟双删有一个天然缺陷：它依赖sleep等待，对高并发场景不友好，第二个删除如果失败，旧数据会一直留在缓存里，而且没有补偿机制。
消息队列方案解决的就是这个问题,操作步骤是：
- 写请求更新数据库
- 把删除缓存的操作封装成消息,发送到消息队列
- 消费者收到消息后执行缓存删除
- 删除失败则重试,直到成功或人工介入
这个方案的好处显而易见：删除操作从同步变成异步，解耦了主流程和缓存操作，消息队列自带的重试机制天然给删除操作兜底，失败几次都能补上。
在Redis中的数据一致性问题中,消息队列方案是生产环境应用最广的，它有一个前提条件：消息队列本身的可靠性要过关，如果消息丢失，那缓存删除永远不会执行，一致性照样破功。
订阅binlog：最彻底的兜底方案
消息队列方案里,如果写库成功但发送消息失败，还是会留下隐患，订阅binlog（数据库变更日志）的方案把这一步也解掉了。
具体路径是：
- 使用Canal等中间件监听MySQL的binlog
- 每次数据库变更都会产生一条binlog记录
- Canal把变更信息推送给消费者
- 消费者根据变更内容删除对应的缓存key
这个方案的精髓在于：只要数据库变了，缓存删除一定会被触发，不存在”写库成功但消息没发出去”的中间态，它把缓存一致性从”业务代码保证”提升到了”基础设施保证”的层面。
代价是引入Canal这个中间件,运维复杂度上升一个等级，小规模项目用这个方案有点杀鸡用牛刀，但一旦业务进入快速增长期，这套方案的收益会非常明显。
redis缓存一致性 如何保证：线上实操的几个关键细节
方案选完了,真正落地的时候还有一堆细节，以下这些坑是实际项目中反复踩过的：
- 缓存删除要带重试，不管是同步删除还是异步删除，都要考虑失败场景，Redis连接超时、网络抖动都会导致删除失败
- 缓存过期时间必须设置，即使有删除机制，也要给缓存加一个合理的过期时间，作为最后一道防线
- 删除key要精确匹配，批量删除用通配符会误伤其他业务数据，线上事故最常见的原因之一
- 监控删除失败率，在缓存删除操作的日志中加上结果标记，失败率异常升高时要能第一时间发现
缓存穿透、缓存雪崩和一致性的关系
缓存穿透（查询不存在的数据）和缓存雪崩（大量key同时过期）虽然不是一致性问题，但都会放大不一致的后果，穿透会让大量请求直接打到数据库，雪崩会让缓存瞬间失效拖垮数据库，处理这两个问题，常用的手段是：
- 对空值也做缓存,但过期时间设置短一些
- 缓存过期时间加随机偏移,避免集体失效
- 热点数据用互斥锁或分布式锁控制并发重建
这些问题和缓存一致性经常同时出现,处理时需要考虑整体方案。
不同场景怎么选：最终一致与强一致的分界线
不同的业务对一致性的容忍度完全不一样,选方案之前先明确自己的需求。
| 业务场景 | 一致性要求 | 推荐方案 |
|---|---|---|
| 电商商品库存 | 高，误差会造成超卖 | 数据库扣减+缓存异步同步 |
| 用户基本信息 | 中，短暂不一致可接受 | Cache Aside+延迟双删 |
| 文章浏览量 | 低，最终一致即可 | 先更新缓存，批量落库 |
|
支付状态 | 高，不能有偏差 | 数据库为准，缓存只读 |
对于真正需要强一致的场景,比如库存扣减、支付状态查询，缓存根本不参与写入路径，写操作直接走数据库，读操作再走缓存，这种情况下缓存只是数据库的只读副本，一致性由数据库自身的事务机制保证。
缓存一致性 面试中的高频考点
面试官问缓存一致性,通常不是要你背方案，而是考察你对不一致产生原因的理解深度，常见的追问路径是：
- 先问Cache Aside模式中为什么是删缓存而不是更新缓存
- 再问并发场景下的覆盖问题怎么解决
- 最后问延迟双删的缺陷和替代方案
把前面几个方案吃透,顺着这条线往下讲，基本能覆盖面试官的大部分考点。
常见问题解答
分布式缓存一致性 解决方案里，延迟双删的消息延迟设多长合适？
延迟双删的第二次删除等待时间,核心考量是覆盖一次完整的读请求周期，经验值在500毫秒到1秒之间，具体要根据业务读链路的耗时调整，读链路短可以缩短到300毫秒，读链路长则要放大到1秒以上，等待时间过长会影响写性能，过短则可能漏掉并发读请求写回的旧值。
Redis缓存与数据库一致性要求高时，用事务能解决吗？
事务只能保证数据库自身的原子性,缓存操作不在事务范围内，如果让缓存操作参与事务，比如用Seata等分布式事务方案，会大幅增加复杂度和性能开销，多数业务场景不值当，更务实的做法是接受最终一致，用消息队列加重试机制把不一致窗口压缩到极小。
缓存删除失败且重试也失败，最终一致怎么兜底？
设置合理的缓存过期时间是最后一道防线,即使删除操作彻底失败，缓存key也会在过期时间到达后自动失效，下一次读请求会重新从数据库拉取最新数据，关键在于过期时间不能设得太长，否则脏数据存留时间会超出业务容忍范围，一般建议不超过30分钟，敏感业务可以压缩到5分钟以内。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/556794.html
